search_repo_docs tells agents to call a tool that is not registered

[victorgulchenko]

I ran five coding-agent sessions through natural documentation tasks on GitMCP,
then rechecked the main finding directly over JSON-RPC on July 16, 2026.

Every search_repo_docs response in the agent runs and today's direct recheck told
the client it could fetch a source with fetch_url_content. The server's
tools/list response registers fetch_generic_url_content instead. The agents in
these runs bridged the mismatch, but a literal client would try to call a tool that
does not exist.

Reproduction:

1. Initialize https://gitmcp.io/modelcontextprotocol/modelcontextprotocol.
2. Call tools/list and note fetch_generic_url_content.
3. Call search_repo_docs for any documentation query.
4. Read the instruction above the returned sources. It names fetch_url_content.

Fresh result from July 16: two direct searches returned 20 source URLs, 19 unique.
The versioned spec paths were only 2024-11-05 and 2025-03-26, plus draft.
The upstream repository also contains the newer 2025-06-18 and 2025-11-25
specification directories.

Full report with session counts, transcript-backed agent feedback, limitations,
and provenance labels: https://emic.sh/research/gitmcp

I am happy to rerun the same tasks after a fix.

[dawNotPoi]

I reproduced this on current main: search results reference fetch_url_content, while tools/list exposes fetch_generic_url_content. I will align the runtime hint and add a regression test.