This page and the endpoint read from the same array in the codebase, so the reference cannot list a tool the server does not implement. If a capability is missing here, it is missing there — see what is not exposed for the things people most often assume are present. Setup is on the Claude page; the LinkedIn accounts these tools drive are covered under accounts for agents.
Two surfaces, and why the difference matters
Every tool falls on one side of a line, and it is the first thing to understand about this server because it governs cost, risk and rate limits alike.
LinkedIn tools (4)
Reach a live LinkedIn session through one of your connected sender accounts. They see what that account sees. They are rate limited, and they need an account to exist first.
Workspace tools (17)
Read this workspace's own records on our server — campaigns, leads, the unified inbox, the approval queue, plus the catalogue, your library, your projects and your credits. No LinkedIn call, no rate limit, and they work on an empty workspace (they just return empty). Two of them write, both to us: pause_campaign and install_product.
LinkedIn tools
These are the reason to connect this server rather than read a dashboard. Each one runs as a named sender account: pass account to choose, or leave it out and the first connected account is used.
| Tool | What it does | Access |
|---|---|---|
| search_linkedin_people | Search LinkedIn for people matching an ICP, through a connected sender account | read-only |
| get_linkedin_profile | Read one LinkedIn profile: identity, current role, followers, job-change signal and latest post | read-only |
| get_linkedin_posts | Recent posts by a LinkedIn member, newest first | read-only |
| list_linkedin_connections | First-degree connections of a connected sender account | read-only |
Workspace tools
Your own outreach data, and the accounts the LinkedIn tools run through.
| Tool | What it does | Access |
|---|---|---|
| list_sender_accounts | The LinkedIn accounts this workspace can act as, with their status, warm-up stage and remaining daily budget | read-only |
| get_usage | How many LinkedIn tool calls this workspace has made this month, and the rate limit in force | read-only |
| list_campaigns | List all campaigns with performance stats | read-only |
| get_stats | Get workspace-wide outreach stats | read-only |
| list_leads | List lead lists and leads | read-only |
| get_inbox | Get unified inbox conversations | read-only |
| list_tasks | List drafts waiting for approval | read-only |
| pause_campaign | Pause a campaign by id | writes |
| search_capabilities | Search what TopClozer products can actually do, and what performs each capability today | read-only |
| search_products | Search the TopClozer catalogue by outcome, kind, tier, price, risk or capability | read-only |
| get_product | One product in full: capabilities, risk, price, and whether this workspace has bought or installed it | read-only |
| install_product | Record an installation of a product into an AI client or the hosted runner. Writes a row; runs nothing. | writes |
| list_installations | What this workspace has installed, where, and what it paid for | read-only |
| list_projects | The projects in this workspace, with how complete each one's context is | read-only |
| get_project_context | The reusable company / ICP / offer / voice record an agent should read before it writes anything | read-only |
| check_credits | The workspace credit balance and the ledger entries behind it | read-only |
| get_platform_usage | What this workspace owns and has run: installs, purchases, the hosted seat, credits and the execution ledger | read-only |
How to call a tool
Every call is the same envelope; only params changes.
POST https://topclozer.com/api/mcp
Authorization: Bearer tcz_live_YOUR_KEY
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": { "name": "<tool>", "arguments": { } }
}Results come back as MCP content blocks — one text block whose body is the tool's JSON, pretty-printed. Parse the string; there is no structured-content field.
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [ { "type": "text", "text": "<the tool's JSON, pretty-printed>" } ]
}
}Errors
Failures split by who can do something about them. A problem the calling agent can act on — no connected account, an unresolvable profile URL, a sender that is paused — comes back as a successful response carrying isError: true and a sentence explaining what to do. That is what lets an assistant read the message and try something else instead of reporting a transport failure to the user.
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"isError": true,
"content": [ { "type": "text", "text": "This workspace has no connected LinkedIn account…" } ]
}
}Genuine protocol faults stay JSON-RPC errors:
| Code | HTTP | Cause |
|---|---|---|
| -32001 | 401 | No key, or an unknown or revoked one. The message names the header to send. |
| -32002 | 429 | The workspace has spent its 30 LinkedIn calls for the current 5-minute window. Retry-After says how long to wait. |
| -32601 | 200 | Method outside initialize, notifications/*, ping, tools/list and tools/call. |
| -32000 | 200 | An unexpected failure inside a tool — for example the upstream provider returning a 5xx after its retries. |
Note the asymmetry: only auth and the rate limit carry a non-200 status. Check the body, not just the status code.
Rate limits and pacing
30 LinkedIn tool calls per 5 minutes, counted per workspace. Shared across every LinkedIn tool, and per workspace rather than per key — a second key does not buy a second allowance. A single search_linkedin_people call returns up to 50 profiles, so the budget goes further than it looks.
It is there for your benefit, not ours. An agent retrying in a loop is precisely the request pattern that gets a LinkedIn account restricted, and a 429 you can retry past is a far better outcome than an account you cannot. Workspace tools are unlimited.
The other limits live inside the product and govern sending, which no tool here can trigger: a per-sender weekly invite cap, a warm-up ramp that starts a new account low and steps it up, a working-hours window evaluated in the workspace timezone, and a randomised gap between two actions on the same sender. They apply identically whether a person clicks send or an agent triggers the workflow.
What is not exposed, and why
- Sending anything — no invite, message, reply, follow or like tool. Outbound actions are released by the scheduler under the workspace review mode, which by default queues every invite and message for a person to approve. This is the boundary the whole product is arranged around, not an unfinished feature.
- Approving a draft —
list_tasksshows the queue so an agent can summarise it. Clearing it is a person's job. - Writing leads or campaigns — an agent can search LinkedIn and read the result, but importing those people into a campaign happens in the app.
pause_campaignis the only write, and deliberately one-way. - Company and job search — people search is implemented and proven; company and job entities are not, and we would rather have four LinkedIn tools that work than seven where three are guesses.
- Account management — connecting an account, changing proxies, editing sending limits. Not implemented, and not planned as an agent surface.
- MCP resources and prompts — the server advertises the tools capability only.
- Paging and since-timestamps —
list_leadsandget_inboxreturn the full set. Filter client-side.
The REST sibling
get_inbox is described on the unified inbox page.Changelog
2026-09-18 · server 2.0.0
LinkedIn itself is exposed. Five new tools — search_linkedin_people, get_linkedin_profile, get_linkedin_posts, list_linkedin_connections and list_sender_accounts — so an agent can search, research and read a profile rather than only read this workspace's own records. All read-only; no sending tool was added and none is planned. A workspace-scoped rate limit of 30 LinkedIn calls per 5 minutes ships in the same release, because handing an agent a live LinkedIn session without one is how accounts get restricted. Tool failures an agent can act on now return isError inside a normal result, per the MCP spec, instead of a JSON-RPC error.
2026-09-10 · server 1.1.0
Bearer / X-Api-Key / ?key= authentication added — before this, the endpoint accepted only a browser session cookie and no MCP client could connect. initialize, notifications/* and ping implemented so the handshake completes. GET answers 405 to an Accept: text/event-stream request instead of returning a JSON body a stream-expecting client cannot read.
2026-07 · server 1.0.0
First endpoint: tools/list and tools/call over JSON-RPC with the six workspace tools.