Cursor's agent stopped using some of your MCP tools — here's the 40-tool ceiling nobody warns you about

You add another MCP server to Cursor — maybe a database client, maybe a second internal tool — and suddenly the agent stops using tools it was reaching for perfectly well yesterday. No crash, no error dialog. It just quietly forgets some of them exist, or a long agent run stops mid-task with no explanation.

If you’re searching “cursor mcp tools not showing up,” “cursor stopped using my mcp server,” or “cursor mcp tools disappeared,” this is almost certainly it: Cursor caps how many MCP tools it will hand to the agent at once, and you’ve gone over.

Why this happens

Cursor enforces a combined limit of 40 active tools across every MCP server you have enabled — not per server, total. Cross it and Cursor shows a banner: “You have 50 tools from enabled servers. The limit is 40 tools – some tools may not be available to the agent.” That’s the visible case. The quieter failure is a single MCP server that exposes more than 40 tools on its own (a Postman-style API-wrapper server easily ships 90+) — Cursor takes the first 40 it sees and drops the rest, and depending on the run, chat generation can just stop without ever telling you why.

The limit exists because every tool definition gets stuffed into the prompt before the agent reads your message. Each one costs real context tokens, and past a few dozen tool descriptions the model’s ability to pick the right one degrades — so Cursor caps the count rather than let a heavy MCP setup quietly eat your context window and your output quality along with it.

Two mcp.json mistakes get mistaken for this same bug and are worth ruling out first, because Cursor is silent about both:

• Missing the mcpServers root key. If your config isn’t nested under {"mcpServers": {...}}, Cursor doesn’t error — it just ignores the entire file. The server you added never appears in the list, with nothing in the UI telling you why.
• A bare npx command without -y. Cursor launches the server non-interactively; without -y, npx sits waiting for a confirmation prompt no one is there to answer, and the server hangs at “loading tools” forever.

How to tell which one you’re hitting

1. Open Cursor Settings → MCP and look for the tool-count banner. If it’s there, you’re over the 40-tool ceiling — that’s the fix below.
2. If a specific server never shows up at all (no error, no tools, nothing), check its mcp.json for the mcpServers root key first — a stray edit that flattens or renames it is the single most common cause.
3. If a server sits stuck on “loading tools” indefinitely, copy the exact command/args from its mcp.json entry and run it directly in a terminal. Cursor swallows the errors a manual run will print straight to your screen — including a hung npx prompt.

The fix

Over the 40-tool ceiling: you don’t need every tool from every server enabled at once. In Cursor Settings → MCP, disable individual tools you aren’t using from each server rather than the whole server — most MCP servers expose far more tools than any one project needs on a given day. If one server alone ships 40+ tools (API-wrapper servers are the usual culprit), look for a slimmer alternative or a config flag that limits which tool groups it registers; a server offering 5-10 focused tools is a better fit for this limit than one trying to expose an entire API surface.

Missing mcpServers key: open the file and confirm the top-level structure is {"mcpServers": {"server-name": {...}}} — not a bare object of server names, not a list. This is the same shape whether the file lives at ~/.cursor/mcp.json (global) or .cursor/mcp.json in the project root.

Hung npx: add -y to the args array so npm doesn’t wait on a confirmation prompt that will never come:

{
  "mcpServers": {
    "my-server": {
      "command": "npx",
      "args": ["-y", "my-mcp-package"]
    }
  }
}

How to confirm it’s actually fixed

Reopen Cursor Settings → MCP. The tool-count banner should be gone, and the server you fixed should show a populated tool list rather than a spinner or a blank row. Then re-run whatever task first tipped you off — if the agent reaches for the specific tool it was missing without you having to prompt it by name, the fix took. If you disabled tools to get under the ceiling and the agent now says it can’t do something it used to handle, you likely disabled a tool it still needed — re-enable it and drop something less-used instead.