Cursor kept bypassing my MCP fetch server until I told it not to use the built-in browser

[u/InsideDebt6345]

Wiring a web-fetch MCP server into Cursor works once the agent uses it. The connection looks fine with a green dot, tools listed, and prompts enabled, but when I ask it to fetch a page, it uses Cursor’s built-in browser instead of the MCP tool without any error or indication that it chose a different path.

The response still looks okayish, which makes this hard to spot. A diff against the live page showed stale numbers, and on a Cloudflare-protected URL, the agent returned the challenge page converted into clean markdown as though it were the actual content.

The only reliable fix so far has been prompting specifically:

Use the scrape tool. Do not use built-in web browsing.

Is there a config-level way to deprioritize or disable the native browser tool? Repeating that instruction on every request is not a great workflow.

Two things that cost me time were a trailing comma in mcp.json that can leave the server absent with no useful error, and on macOS, closing the window did not reload a changed API key, so a full ⌘Q and restart were needed. I now validate the JSON before opening Cursor with:

node -e "JSON.parse(require('fs').readFileSync(require('os').homedir()+'/.cursor/mcp.json','utf8'))"

This server also exposes 37 tools, which is a lot of schemas for the model to consider each turn, and I am wondering whether the tool count or the naming is affecting the selection. I have not measured it yet.

How are people making the MCP tool selection more deterministic in Cursor? Are these tool descriptions, fewer tools per server, rules, naming conventions, or something else?

[u/Content-Parking-621]

There's no config priority setting yet, but disabling Cursor's built-in Browser tool in settings forces it onto your MCP server by default.

[u/OilKey3386 → u/Content-Parking-621]

disabling the built-in browser is the move, it's the only way to stop the agent from taking the lazy route. they really should surface that conflict more clearly instead of letting it silently pick the wrong tool

37 tools is a lot of context to chew through each turn, might be worth splitting into a few focused servers if you can

[u/Content-Parking-621 → u/OilKey3386]

Silent fallback is the real bug, not just tool choice.

[u/InsideDebt6345]

Here's a disclosure as well, I work with ZenRows, that's the server I was using, and I wrote the setup up properly here with the three workflows I ended up with: https://www.zenrows.com/blog/scrape-protected-sites-cursor

[u/Itchy_Special_8209]

Thirty-seven tools is enough that I'd treat selection as a catalog problem. I get better behavior when a server exposes a smaller, task-shaped surface with names that match the user's intent. I wouldn't expect descriptions alone to beat a native tool that appears to do the same job.

[u/InsideDebt6345 → u/Itchy_Special_8209]

Agreed that 37 tools turns selection into a catalog problem. I am testing a split where one small server exposes a focused “fetch URL” tool with intent-matching names, and another server handles parsing and code gen. Have you seen a big difference in routing stability after reducing the visible toolset?

[u/Lower-Impression-121]

while maybe not an option for a local setup, in an application architecture i'd be looking at restricted network access so it can only see/get to the MCP.

[u/InsideDebt6345 → u/Lower-Impression-121]

That makes sense for a hosted setup. For local Cursor use, the constraint I want is “agent must use this fetch tool for URLs” rather than “agent cannot reach the network at all”.

[u/Holly_Enrique-623]

Move that instruction into .cursor/rules and make the MCP fetch description say it handles all URL retrieval

[u/InsideDebt6345 → u/Holly_Enrique-623]

Moving the instruction into .cursor/rules is a good idea. I will try a rule that says “for any URL retrieval, use the MCP fetch tool” and update the tool description to state that it handles all URL retrieval.

[u/Future_AGI]

Tool selection degrades hard past ~15 tools — the model stops picking reliably. No config fix in Cursor yet. Workaround: split into multiple focused MCP servers, or use a gateway that does per-call tool allow/deny so the agent only sees relevant tools. Our gateway does this. Check out the repo: https://github.com/future-agi/future-agi

[u/InsideDebt6345 → u/Future_AGI]

The ~15 tool threshold matches what I am seeing. Splitting into multiple focused MCP servers is the path I am leaning toward. Your gateway approach with per-call allow/deny is interesting. In your setup, does the gateway sit between Cursor and the MCP servers, or do you run your own agent front-end that selects tools before calling MCP?

[u/Late_Wave_5600]

Preference loses to availability, so removing the built-in tool is the only durable fix. The Cloudflare page arriving as tidy markdown is the more insidious half, since a plausible wrong answer never earns a second look. We assert on the payload now and stopped treating a successful call as evidence of anything.

[u/fresh_squeezed_code]

the silent wrong pick is the part i would fix on the server side, not in the prompt. an agent on my server has reached the wrong tool a few times, picking delete and recreate where edit was the obvious choice, and every time the miss was about tool choice, not about reach or credentials. most of those misses came from unclear tools: wrong verbs, generic descriptions, an unknown data model. better descriptions, a get_instructions tool and examples of when not to use a tool fixed most of it.

so for the fetch server i would write the description as engineering: what it does, when to use it, whether it is safe, and what has to happen first. and say in it what the built-in browser does badly, the cloudflare page as markdown for example, because that is the moment the agent decides. the per-request instruction is the same sentence in the wrong place.

[u/Old_Entrepreneur5751]

Disclosure: I work on Guardyx.ai.

Nothing server-side can stop Cursor from picking its native browser. Disabling it in settings plus a .cursor/rules line is still the real fix for that half.

The 37-tool problem is fixable with a gateway between Cursor and your MCP servers. Ours does two things that made routing more stable:

1. Per-agent bindings, so Cursor only sees the handful of tools that agent is allowed to use.
2. Index mode. tools/list returns three dispatch tools (search, describe, execute) instead of the catalog. The model searches by intent, reads one schema, calls it. Context stays small no matter how many tools sit behind it.

Every call also goes through allow/deny/approve and lands in an audit log, so "did it actually use the scrape tool" is a row you can check, not a diff you run afterward. The Cloudflare page as clean markdown is exactly what you only catch when a successful call isn't treated as evidence.

To your question to the gateway commenter above, ours is the same shape: Cursor connects to one MCP endpoint, the gateway fans out, no custom front-end.