mcpserver/tools/) is the only
authoritative source, and a table copied out of it here is wrong the first time
somebody adds a tool.
What the set is, and what it is not
Two sentences worth getting straight, because the shape of a tool list is easy to misread as the shape of a product.Every operation the REST API exposes is reachable. The full surface is the Runtime API — documents, extractions, reports, runs, conversations, jobs, knowledge, webhooks, logs and the rest, with an OpenAPI document generated from the running code.
The MCP set is the part chosen for a model to pick correctly. It is a curated selection over that same surface, not a subset of what the platform can do.That curation is the point rather than a limitation. One tool per endpoint would mean dozens of near-identical descriptions, and a model’s real difficulty is not reaching an operation — it is telling
list_documents from search_knowledge
from search at the moment it has to choose. Tools are added when a workspace
question cannot be answered without them, and each is written to be picked
correctly rather than to complete a matrix. If something you need is not a tool
yet, it is almost certainly an endpoint; the Runtime API tab has it, and the gap
is worth telling us about.
Getting the authoritative list
Two live documents answer this, and neither can go stale.tools/list — every tool, with its schema
mcp:connect sees the whole
catalogue — so this is the honest answer to “what exists”, and it is the same
list your client discovered when it connected.
The metadata document — every scope the set can ever need
tools/list reports each tool’s name, title, description and input
schema. It does not report the scope, because a scope is checked against the
caller’s credential and is not a property a model needs in order to choose.
The scope surface is the metadata document above; which scope a given call
demanded is named in the 403 if it is missing, in full and in one challenge.The groups
Eleven, and between them they cover configuring the platform, running it, and reading what it produced.
Every scope these draw on is a real member of the same registry
/api/v2/ uses
(adminapi/services/developer.py::SCOPES) — there is no MCP-only permission
vocabulary. See Authentication and scopes for the whole
list.
Some absences are decisions, not gaps. No tool deletes a customer’s data,
and no tool returns a credential — a webhook signing secret is returned by the
REST API on create and rotate, and by no tool at all, ever. The Business group
is read-only for the same kind of reason: writing a lead or booking an
appointment fires a side effect at a real person outside the conversation, and
nothing inside the conversation can undo it.
Rules every tool follows
Each tool checks its own scope, on every call
Each tool checks its own scope, on every call
mcp:connect gets you tools/list and nothing else. The scope a tool needs
is checked inside the dispatcher when it is called, not once per connection.Handlers call the service layer, not our own HTTP API
Handlers call the service layer, not our own HTTP API
And they reuse each app’s existing serializer. That is why an MCP payload and
a REST payload for the same resource cannot drift apart — there is one
function producing both.
Every call is pinned to one workspace
Every call is pinned to one workspace
Resolved from the credential by lookup, never from anything the caller
asserts. A tool asked for a resource belonging to another workspace answers
not found, not forbidden — a 403 would confirm the resource exists.
A tool that cannot answer returns something the model can say
A tool that cannot answer returns something the model can say
Out of credit, not found, bad argument: HTTP 200, a result marked
isError: true, and readable text. Transport and auth failures are HTTP
statuses; everything that happens inside a tool is not.Every listing has a ceiling
Every listing has a ceiling
One page limit for the whole set. A model that asks for a thousand rows wants
the first page and does not know it — and a thousand-row result is also
several thousand tokens of somebody else’s context window.
Two behaviours that surprise people
These are the first two things that will look like bugs and are not. Both are described in the tool descriptions themselves, so a model reading them is told — but you should know them too, because you will be reading the transcript.1. Four operations answer with a job, never a result
Extractions, reports, knowledge ingestions and jobs are queued. Always. The tool returns a job id and says to poll; it does not block waiting for the work, because holding a worker open on a poll loop is how a queue becomes an outage.2. upload_document succeeds before the document is readable
Upload returns success while parsing continues in the background. Reading
the document’s text immediately afterwards returns 409
document_not_processed — and it will keep doing so until parsing finishes.
The same 409 is what /api/v2/documents returns for the same reason, and for
the same document; see Documents.
What a call costs
A tool call costs whatever the operation behind it costs — nothing is priced differently for arriving over MCP. Read tools are free of credit; anything that uploads, ingests, extracts, generates or runs an agent is not.Credits
How spend is metered, and what an empty wallet returns.
Runtime API
The full surface these tools are curated from.