MCP server
Security and limits
The guarantees are properties of the code, several of them enforced by tests that fail the build. The limits are the bounds a request runs inside.
Identity cannot be spoofed
No tool accepts a user, subject, tenant, role or on-behalf-of argument. The server walks every registered tool schema against a denylist of identity fields and refuses to start if one appears. The only identity is the one in the verified token, and whoami shows it to you.
Access control is applied on every read
What a search can return is decided by your workspace’s access rules, deterministically, for every read. The rules are enforced twice: as a filter on the search index and again as a check on the database rows before anything is served. No scope, tool argument or prompt can widen it.
Every read is recorded and replayable
A search produces a serving receipt: who asked, under which role audience, the query, the instant, and what was served. The id comes back in the result, and memory_receipt reopens it to show what the same read serves now and what changed. Receipts are per person; you replay your own.
No standing credential in the server
The MCP server holds no API key and no database. On each request it verifies your token and exchanges it for a credential to the memory service that lives only as long as the request. A compromised MCP host yields no reusable secret, and the token your client holds works on this server alone.
Agent writes are reviewed
A headless agent’s memory_write lands as a proposal in the workspace review queue, attributed to the agent, and becomes memory only when a person approves it.
Revocation is honest about its window
Disconnecting ends the refresh chain immediately; the access token already issued keeps working until it expires, at most 15 minutes. There is no sub-token-lifetime kill switch, and we say so rather than imply one.
What is deliberately not offered
- No administrative tools: approving proposals, changing who can see what, or deleting memory never happens through an AI client.
- No tenant-wide reads: a person sees what they can see, an administrator included.
- No token passthrough: your token is never forwarded to any other service.
Limits
| Field | Type | Meaning |
|---|---|---|
| rate | per principal | 60 requests per minute with a burst of 10. Excess answers 429 with a Retry-After header. |
| request body | 256 KiB | Larger requests are refused before any work. |
| query | 2000 chars | memory_search query length. |
| content | 32 KiB | memory_write content length. |
| response | 128 KiB | Whole tool result; trailing fragments are dropped and truncated is set. |
| fragment value | 4 KiB | Per fragment; clipped text sets value_truncated. |
| deadline | 25 s | Total per tool call, with 20 s for the upstream read. A slow search fails rather than hanging the client. |
| access token | ≤ 15 min | People. Agent tokens from client credentials live up to 60 minutes. |
Transport
- Streamable HTTP, POST only. GET and DELETE answer 405; there is no long-lived event stream.
- Stateless: no session id, no server-side connection state. Retry a failed request as a new request.
- Protocol revision 2026-07-28; clients from revision 2025-06-18 up are accepted. Batched JSON-RPC is refused.
- Requests with an Origin header are checked against the allowed origins; headless clients send none and pass.