Coding agent documentation index Fetch the complete documentation index at: https://docs.worklittle.com/docs-agent-manifest.json Use this file to discover all available pages before exploring further.

REST, SDK, CLI, or MCP

Same account, same key, same billing, four ways in. Pick the transport by where your code runs and who is calling it, not by which one feels more modern.

One sk-wl-api01 key works for api.worklittle.com and mcp.worklittle.com. Choosing a transport is an ergonomics decision, not an access decision.

The short answer

| Situation | Use |
| --- | --- |
| Server-side code with a fixed contract | **REST** |
| TypeScript or Python app that wants types and helpers | **SDK** |
| Shell scripts, cron jobs, one-off exploration | **CLI** |
| Claude, Cursor, ChatGPT, or another MCP client | **MCP** |
| Your own agent framework with your own tool loop | **REST or SDK**, wrapped in your own tool definitions |

That last row surprises people. If you already have an agent framework with its own tool registry, you usually do not want MCP in the middle. Call REST directly and define tools that match your product, with your own guards baked in.

What MCP gives you

MCP at https://mcp.worklittle.com exposes the Worklittle surface as tools an MCP client can discover and call without you writing an integration. Tools span job search, documents, ATS, webhooks, alerts, and Apply with AI.

Its real advantages:

Zero integration for supported clients. Point Claude or Cursor at the endpoint with your Bearer key and the tools appear. Descriptions that carry usage guidance. Tool descriptions encode things like using get_job_keywords rather than a full description for tailoring, so a capable model often does the right thing without a long system prompt. * One auth story. The same key and scopes as REST, so nothing new to provision.

Its costs: you inherit the tool surface as designed rather than one shaped to your product, and a chatty client can call metered tools more eagerly than you would like. Setup: Worklittle MCP.

What REST and the SDK give you

REST gives you the contract in full: every filter, every field, every error code, and the routes MCP does not expose. Unauthenticated board apply is a clear example of REST-only surface area.

The SDK wraps the same routes with types and helpers:

import { createWorklittle } from "worklittle";

const wl = createWorklittle({ apiKey: process.env.WORKLITTLE_API_KEY });
const list = await wl.surveys.list();

The CLI covers the same ground for shell workflows and is the fastest way to sanity check a filter before you write code. Both are documented at Libraries, with the machine-readable contract at OpenAPI.

Mixing transports

Mixing is normal and often correct. A common production shape:

MCP for the internal team's exploratory work in an editor or chat client. REST or SDK in the product itself, where you control retries, caching, and confirmation gates. * CLI in cron jobs and CI.

Because they share one key and one billing account, usage from all three lands together on Usage. If you want to attribute spend by surface, create separate keys per surface rather than trying to disentangle them after the fact.

Pitfalls

| Pitfall | What to do instead |
| --- | --- |
| Provisioning separate keys for MCP and REST | One key covers both |
| Assuming every REST route has an MCP tool | Some routes are REST only (for example unauthenticated board apply) |
| Layering MCP inside a framework that already has tools | Call REST and define your own tools |
| Expecting MCP errors to look like HTTP | Upstream 429s and 5xx surface as JSON-RPC errors, often -32603 |
| Letting an MCP client search on every turn | Budget metered tools. See [Retries and spend](/use-cases/retries-and-spend) |

Related docs

Worklittle MCP, Libraries, SDK, CLI, OpenAPI, Errors.