MCP Server

MCP limits

The MCP server follows the same limits as the REST routes it wraps. This page lists them and what the MCP server does not do yet.

Copy page

How limits apply

Each MCP tool call goes to a REST route. The same limits and refusals apply.

Ingest quotas apply to ingest_text.
A call over the per-minute limit returns 429 with a Retry-After header. Wait for the number of seconds in that header, then retry.

Tool	Wraps	Limit that applies
`ingest_text`	POST /v1/vault/ingest/text	Ingest quotas, per-minute limit
`assemble_context`	POST /v1/context/assemble	Per-minute limit

ingest_text and assemble_context do not use the /v1/memory routes. For the limits of the Memory API, see the Memory API docs.

HTTP/1.1 429 Too Many Requests
Retry-After: <seconds>

Read Retry-After, wait that long, then send the call again. Do not send repeated calls before the wait ends.

A sign-in token reaches fewer tools than the app key: no provision_app and no owner-only change. Keys work as before: send a key in the Authorization header as Bearer <key>.
With no Authorization header, the server offers only provision_app.
Some tools need a particular key. provision_user, get_claim_link and get_setup_bundle need the app key (fsa_). ingest_text, assemble_context, list_tools, configure_oauth and action_history need a person's key (fsk_). describe and diagnose take any key.
Calls are scoped to the key's user.
No conversation transcript capture. ingest_text is for text notes and durable facts, not streaming transcripts.