Document MCP Server rate limits
Problem
The MCP Server documentation says nothing about rate limits. There is no published limit, no explanation of what a client receives when throttled, and no entry for a 429 in the troubleshooting page.
Proposal
Document the MCP rate limit and the behaviour a client should expect, so an integrator can plan against it and recognise a throttle when they hit one.
Implementation plan
- A limits section in
doc/user/gitlab_duo/model_context_protocol/mcp_server.md. - A 429 entry in
mcp_server_troubleshooting.md, which currently documents only 404 and protocol-version errors. - Rows in
doc/administration/instance_limits.md. Thedoc/api/settings.mdreference for the three settings lands with the settings themselves in #629883 (closed), so it is not needed here. - The GitLab.com values in
doc/user/gitlab_com/rate_limits.md.
Detail
Two behaviours to describe, both correct
These are easy to conflate and the documentation needs to separate them.
Hitting the MCP Server's own limit refuses the request before any tool runs, and returns HTTP 429 with Retry-After and the RateLimit-* headers.
Hitting a limit on the endpoint a tool calls, such as the search rate limit during a search tool call, is an API failure. The MCP specification classifies those as tool execution errors, reported in the result with isError: true rather than as a transport error, so the client gets HTTP 200 and an error result. That is by design, not a gap.
Effective limits differ by deployment
A tool's real ceiling is whichever is lower: the MCP limit or the limit on the endpoint it calls. Administrators can change endpoint limits, and GitLab.com's configured values differ from self-managed defaults, so the documentation should give the GitLab.com numbers and tell self-managed administrators to check their own settings rather than implying a single universal number.
Worth stating plainly that the throttle ships disabled, so a self-managed instance has no MCP limit until an administrator enables it.