MCP Limits and Errors

The MIND MCP server is public and needs no sign-in, so its limits are per IP address. This page lists each limit, each error the server returns and what to change when you meet one. The input ranges of each tool are on the Tools Reference.

Limits

Limit	Value	When it is exceeded
Requests	600 per minute per IP address. An IPv6 client counts per /64; each message in a batch counts.	HTTP `429`, error `-31429`, `Retry-After: 60`
Bursts	A couple of hundred requests within a second or two from one IP address	HTTP `429` from the network edge, before the server sees the request: the body is not JSON-RPC, and `Retry-After` is shorter
Searches matched by meaning	30 per minute per IP address	`search` matches by keyword alone (`mode: "lexical"`); no error (see `search`)
Request body	64 KiB	HTTP `413`, error `-31413`
JSON-RPC batch	16 messages	HTTP `400`, error `-32600`
Tool result	64,000 characters	An error result asking for a smaller `limit`, `max_tokens` or `max_chars`; `fetch` returns a shorter page instead
Tool inputs	Per tool, see the Tools Reference	An error result that starts with `Input validation error:`

Note

Limits can change. A client that honours Retry-After keeps working whatever the numbers become.

If you are rate-limited

A 429 Too Many Requests comes in one of two shapes:

A burst, a couple of hundred requests within a second or two, is refused at the network edge before the server sees it. The body is an error from the edge, not a JSON-RPC message, and Retry-After is shorter than a minute.
Sustained traffic over 600 requests a minute from one IP address is refused by the server, with Retry-After: 60 and this body:

{
  "jsonrpc": "2.0",
  "error": { "code": -31429, "message": "Rate limit exceeded; retry after 60 seconds." }
}

Whatever the body, wait for the number of seconds in Retry-After, then send the request again. Check the HTTP status before you parse the body as JSON-RPC: a burst refusal has no jsonrpc field and no request id. To stay under the limits, spread requests out rather than sending them all at once, send fewer messages per batch and reuse list results: tools/list, prompts/list and the resource lists change only when the server is updated, and under protocol 2026-07-28 they carry a one-hour cache hint.

Error codes

Code	Meaning	What to do
`-31403` (HTTP 403)	The `Origin` is not allowed	See Origin and host
`-31413` (HTTP 413)	The body is over 64 KiB	Send less per request
`-31429` (HTTP 429)	Over 600 requests a minute from this IP address. A burst refused at the network edge is also HTTP 429, with no JSON-RPC body (see If you are rate-limited)	Wait for `Retry-After`
`-32000` (HTTP 403)	The `Host` is not `mcp.mindlang.dev`	Keep that `Host`, also through a proxy
`-32000` (HTTP 406)	Protocol 2025-11-25 or earlier, and `Accept` lacks `application/json, text/event-stream`	Send both in `Accept`
`-32020` (HTTP 400)	Protocol 2026-07-28: `MCP-Protocol-Version`, `Mcp-Method` or `Mcp-Name` disagrees with the body, or is not visible ASCII	Match the body; send a non-ASCII `Mcp-Name` as `=?base64?…?=`
`-32600` (HTTP 400)	A batch of more than 16 messages	Split it
`-32700` (HTTP 400)	The body is not valid JSON	Fix the JSON
`-32601` (HTTP 200)	No such method, including `server/discover` without the 2026-07-28 `_meta` envelope	Use a method the server supports
`-32602` (HTTP 200 or 400)	Invalid parameters: an unknown tool, a resource URI that names no document (`Resource not found: <uri>`), prompt arguments that do not fit, or an invalid 2026-07-28 `_meta` envelope (HTTP 400)	Use names from the list methods; the message names the problem
`isError: true` (HTTP 200)	A tool result, not a protocol error: invalid arguments, an unknown `fetch` id, an offset past the end, a result over 64,000 characters	Read the text: it says what to send instead

Common symptoms

Symptom	Likely cause	Fix
The client reports `405` when it connects	It opened a GET event stream, as clients of the retired HTTP+SSE transport do	Choose Streamable HTTP (often `"type": "http"`) in the client's settings
`404` on a URL ending in `/sse`	The HTTP+SSE transport is retired	Use `https://mcp.mindlang.dev/mcp`
`406 Not Acceptable` from a script	The `Accept` header lacks `text/event-stream`	Send `Accept: application/json, text/event-stream`
The client opens a sign-in page or asks for a token	It tries OAuth by default	Choose no authentication; the server has no sign-in
`search` returns `mode: "lexical"`	The client sent more than 30 searches in a minute, or the embedding model was unavailable, so search matched by keyword alone	Nothing to fix: keyword results are cited and correct; send fewer searches a minute to get matching by meaning back
`403` from a web page	The page is served over plain `http://` from a host other than localhost	Serve it over `https://`

For a client that lists the server but shows no tools, see Troubleshooting.

HTTP routes

Request	Answer
`POST /mcp`	The MCP endpoint, Streamable HTTP
`POST /`	The same endpoint, kept for setups made with the bare `https://mcp.mindlang.dev`
`GET` or `HEAD /`	`308` redirect to `https://mindlang.dev/docs/mcp`; not MCP. A `GET` or `HEAD` that asks for `text/event-stream` gets `405` with `Allow: POST, OPTIONS` and the JSON body instead, as on `/mcp`. Other methods on `/` except `POST` and `OPTIONS` answer `405` with `Allow: GET, HEAD, POST, OPTIONS`
`GET /mcp`, or any method other than `POST` and `OPTIONS` on `/mcp`	`405` with `Allow: POST, OPTIONS` and a JSON body that names the setup page. The server never opens an event stream, so a GET that asks for `text/event-stream` also gets `405`, as Streamable HTTP allows
`OPTIONS` on any path	`204` with the CORS headers, for an allowed `Origin` (see Connect from Code)
`GET /.well-known/mcp/server-card.json` or `/mcp/server-card`	The server card
`GET` or `HEAD /health`	`200` with `{"status":"healthy","version":"2.0.0","protocol":"2026-07-28"}` and `Cache-Control: no-store`: the server version and the newest MCP revision it speaks. The body has no timestamp, so it changes only when the server is updated. Other methods except `OPTIONS` answer `405` with `Allow: GET, HEAD, OPTIONS`
`GET` or `HEAD /robots.txt`	`User-agent: *` and `Disallow: /mcp`. Other methods except `OPTIONS` answer `405` with `Allow: GET, HEAD, OPTIONS`
`/sse`, `/mcp/sse`	`404`: "The HTTP+SSE transport is retired. Use Streamable HTTP at https://mcp.mindlang.dev/mcp."
`/.well-known/oauth-protected-resource`, `/.well-known/oauth-authorization-server` and `/.well-known/openid-configuration`, with or without a path after them, and the same under `/mcp/`	`404` by design, so no client starts a sign-in. The server never answers `401`
Any other path	`404`

/health and the server card also come in a MIND-native mic@3 form when the request sends Accept: application/vnd.mind.mic3; JSON stays the default.

Origin and host

Browsers send an Origin header. The server checks it before it handles any MCP request:

No Origin (command-line tools, server-side clients, most desktop apps): allowed.
Any https:// origin: allowed, so a web app on any site can call the server.
http:// on localhost, 127.0.0.1 or [::1]: allowed, for local tools such as the MCP Inspector.
Anything else, including null, other schemes, plain http:// to other hosts, and values with a path: 403, error -31403.

The Host must be mcp.mindlang.dev. A request with any other Host is refused with 403 and error -32000 (Invalid Host: <name>), except on paths that answer 404 or 405 anyway.

Tools Reference: each tool's input ranges
Security and Privacy: what is logged and what is not
Connect from Code: headers, protocol versions and examples
FAQ: short answers to common questions