AgentFetch vs mcp-server-fetch: which MCP web fetch server should I use?

Use mcp-server-fetch (the reference MCP web fetch server maintained in the modelcontextprotocol/servers repo) when you want something free, local, and minimal; use AgentFetch when the fetch layer has to survive real agent workloads. The reference server exposes a single fetch tool taking url, max_length, start_index, and raw — it pulls the page, converts HTML to markdown, and supports chunked reads by advancing start_index. That is genuinely enough for light use, it installs with uvx mcp-server-fetch or pip install mcp-server-fetch, and it costs nothing. Its limits show up under load: there is no caching, so re-reading the same URL costs full latency every time; no token estimation, so your agent discovers a page is 50K tokens only after it has already spent them; no batching, so ten URLs means ten sequential round-trips; no search, so the agent must already know the URL; and no managed fallback for JS-rendered pages, PDFs, or anti-bot interstitials, which is where naive fetching most often fails. AgentFetch exposes four tools instead of one — fetch_url, estimate_tokens, fetch_multiple (up to 20 URLs in parallel), and search_and_fetch — plus a 6-hour cache and auto-routing across Trafilatura, Jina, FireCrawl, and a PDF path. The honest trade-off: mcp-server-fetch runs entirely on your machine with no API key and no per-call cost, while AgentFetch is a hosted service (500 free fetches, then from $0.001 each) that you call over the network. Pick the reference server for hobby agents and offline work; pick AgentFetch when cache hits, token budgeting, parallel reads, and not-writing-a-fallback-chain are worth a fraction of a cent per call.