One set of capabilities. Two ways to call them.

One surface, two transports

Everything below is generated from the capability table this server dispatches on, so it cannot describe a capability the endpoint does not serve. The table's fingerprint today is 4e1f93d2 — it changes whenever a capability's name, arguments, scope or routing change, and the generated client carries a copy so a client can tell whether it was built for the server it is talking to.

4 of the 21 reach LinkedIn through a sender account you connected. The rest read this server's own database — your campaigns, leads, inbox, the product catalogue, your library and projects. The split decides everything that follows: whether a call spends the LinkedIn budget, whether it lands in the execution ledger, and whether an unconfigured provider can make it fail.

Authenticate

One credential for both transports: a workspace API key, minted on the Developer page in the app. Send it as Authorization: Bearer tcz_live_…. The header X-Api-Key works too, and ?key= exists for clients that accept only a URL — it ends up in access logs, so prefer a header.

Scopes belong to the key, not to the workspace: two keys are how you give a third-party client read access to LinkedIn without also handing it the ability to install products. The scopes in use are credits:read, linkedin:read, products:install, products:read, projects:read, usage:read, workspace:read, workspace:write. A key minted before scopes existed carries none and is allowed everywhere; that is deliberate, so nobody's integration broke the day scopes shipped.

Call it over HTTP

GET /api/v1/capabilities lists the surface and needs no credential — it describes the server, not a workspace.

curl -s https://topclozer.com/api/v1/capabilities

POST /api/v1/capabilities/{name} runs one. The body is the arguments object — the same arguments the MCP tool takes — or no body at all.

curl -s -X POST https://topclozer.com/api/v1/capabilities/search_linkedin_people \
  -H "Authorization: Bearer tcz_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"keywords":"VP Engineering","industry":"Financial Services","limit":25}'

A success is the capability name and its payload, so a log line says what produced the result:

{
  "capability": "search_linkedin_people",
  "result": {
    "searchedAs": "Marcus Feld",
    "count": 25,
    "people": [ … ]
  }
}

Call it from an AI client

The same capabilities, spoken as JSON-RPC at https://topclozer.com/api/mcp. This is the transport Claude, Cursor, VS Code, ChatGPT, n8n and Make understand.

claude mcp add --transport http topclozer https://topclozer.com/api/mcp \
  --header "Authorization: Bearer tcz_live_YOUR_KEY"

Per-client setup, the tool reference and the response envelopes are in the MCP documentation; the endpoint itself is described at /hosted-mcp.

The CLI

Zero dependencies and no build step. It asks the server what exists rather than carrying its own copy, so it describes the server you point it at — a capability shipped this morning is callable from a CLI installed last year.

export TOPCLOZER_API_KEY=tcz_live_YOUR_KEY

topclozer capabilities            # what this server can do
topclozer describe get_linkedin_profile
topclozer call get_stats
topclozer call search_linkedin_people --keywords "VP Engineering" --limit 25
topclozer usage                   # LinkedIn calls this month, and the limit

Exit codes are 0 success, 1 usage error, 2 the server refused or failed — so a shell script can branch without parsing output.

The TypeScript client

Capability names and argument names are typed, generated from the server's own registry. Results are typed unknown: each payload is documented in prose and an example on its reference page, and inventing interfaces from an illustrative example would produce types that look authoritative and are not.

import { createClient, TopclozerError } from "@topclozer/sdk";

const topclozer = createClient({ apiKey: process.env.TOPCLOZER_API_KEY });

try {
  const people = await topclozer.call("search_linkedin_people", {
    keywords: "VP Engineering",
    limit: 25,
  });
} catch (e) {
  if (e instanceof TopclozerError && e.errorClass === "rate_limited") {
    // e.retryAfter is in seconds. Backing off is your decision, not the library's.
  }
}

Neither of them retries. A retry loop against the LinkedIn budget is the exact request pattern that gets a LinkedIn account restricted, and a library that hid a 429 behind three silent attempts would be doing that to your account on your behalf.

Budgets

Two limits, and conflating them is how a job gets planned against the wrong number.

Both are per workspace, not per key: a second key does not buy a second allowance, and splitting traffic between the two transports does not either. The LinkedIn number is published because it is enforced.

Errors

Every failure carries a stable class, so a client can branch without parsing English: { "error": { "class": "rate_limited", "message": "…", "retry_after": 42 } }. On MCP the same classes become JSON-RPC codes, and the ones a model can act on come back as a readable tool result rather than a protocol fault.

Every capability

All 21, with the scope each one needs and what it costs. The name is both the MCP tool name and the HTTP path segment.

What this API does not do

Stated here because finding out from a 404 wastes a developer's afternoon, and because an API that only advertises its strengths is how integrations get built on assumptions.

• No sending. Nothing here invites, messages or posts on LinkedIn, and there is no plan for a capability that does. Outbound actions are released by the product under the workspace sending policy, which by default waits for a person.
• No webhooks. There is no way to be told that a reply arrived; you poll get_inbox.
• No paging on the workspace reads. list_leads and get_inbox return everything in one payload. On a large workspace that response is big; filter on your side.
• No creating campaigns, importing leads or approving drafts. Those are in the app. An agent can read the approval queue and summarise it; it cannot press send.
• No idempotency keys. The two write capabilities are effectively idempotent — pausing a paused campaign changes nothing, and an install records a row — but there is no header that makes a retry safe in general, so do not build one that assumes it.

FAQ