Minimal MCP HTTP client that retrieves web pages and converts responses into model-friendly text without a full browser runtime.
Looking for more MCP servers? Browse the full MCP tools directory or explore more tools in HTTP Client.
Fetch MCP is the correct first hop for web access because it keeps retrieval cheap, observable, and narrow. Its weakness is also its contract: it returns HTTP responses, not human-visible pages. Enforce SSRF protections and semantic response checks, then escalate deliberately to Firecrawl or Playwright. A 200 status is never a content-quality signal.
Fetch MCP is the deliberately boring HTTP layer every agent stack needs before it reaches for a browser. It performs direct requests and converts HTML into model-friendly text, which makes it faster, cheaper, and easier to reason about than launching Chromium for pages that do not require JavaScript execution. The architectural boundary is exact: Fetch sees the response returned by the server, not the page a human sees after client-side hydration, authentication, cookie negotiation, or interaction. That boundary is a feature when you need documentation, robots-aware retrieval, and low-overhead content ingestion; it is a failure when the target is a JavaScript application or a session-gated page. The most dangerous Fetch failure is not a timeout — it is a successful 200 response containing a login wall, bot challenge, truncated HTML, or stale cache. The agent receives text, finds plausible headings, and writes an answer based on the wrong document. Production use needs URL allowlists, content-type checks, maximum response sizes, redirect policy, and provenance metadata. Use Fetch for retrieval, Firecrawl for semantic extraction, and Playwright when the task is interaction.
The teams and workflows that benefit most from this tool.
Static documentation retrieval
Lightweight API and web-page fetching
Feeding model-friendly text into research workflows
Low-cost first-pass web access before browser escalation
Choose Fetch MCP Server when you want an MCP server focused on HTTP Client and need tighter integration with your existing tools.
Good fit
Things to watch before choosing this tool.
No general JavaScript rendering
No browser sessions or interactive authentication
Successful responses can be challenges or login pages
Requires network-level SSRF and egress controls
Use the following configuration as a starting point for Claude Desktop or any compatible MCP client, then replace placeholder credentials with your own values.
{
"mcpServers": {
"fetch": {
"command": "uvx",
"args": ["mcp-server-fetch"]
}
}
}These setup steps cover the typical installation flow for this MCP server.
Install with uvx mcp-server-fetch or the package method supported by your client, then expose it as a read-only retrieval server.
Add URL policy outside the model where possible: allowlist trusted domains, block internal IP ranges and localhost, and cap response size and redirect depth.
Pro-Tip: The fatal flaw 90% of developers commit is treating HTTP 200 as proof that useful content was retrieved. A bot challenge, login page, empty SPA shell, and real article can all return 200. Require content-type, final URL, response length, title, and a challenge/login detector before accepting the page as evidence; status code validates transport, not meaning.
Use Fetch for static documentation and APIs; switch to Firecrawl or Playwright when the page needs rendering, actions, authentication, or structured extraction.
Preserve the final URL and retrieval timestamp with every extracted passage so later answers do not lose provenance.
Verify with a static page, a redirect, and a JavaScript-heavy page. The differing outputs should be explained rather than silently treated as equivalent.
Supported environments for Fetch MCP Server.
Claude Desktop
Yes
Cursor
Yes
VS Code
Yes
Lightweight reference server. Use URL allowlists, SSRF egress controls, response-size limits, and semantic content validation.
Common questions for Fetch MCP Server.
This is the silent failure of static retrieval. The server received a valid HTTP response, but the content was an SPA shell, login page, bot challenge, or truncated document. The engineering fix is to inspect final URL, content type, title, response size, and known challenge markers before passing text to the agent. Use a rendering-capable server when content is created after JavaScript execution.
Fetch is lightweight direct HTTP retrieval for static pages and APIs. Firecrawl adds rendering, crawling, extraction, and structured output at higher operational and credit cost. Start with Fetch and escalate to Firecrawl when static retrieval fails or the workflow needs semantic extraction.
Not as a general browser-session mechanism. Authentication headers may work for controlled APIs, but cookies, multi-factor flows, client-side login, and interactive sessions require a browser automation server.
Enforce network-layer egress restrictions, block private and link-local address ranges after DNS resolution, limit redirects, and allowlist destinations. Prompt instructions alone are not an SSRF control.
| Feature | Fetch MCP Server | Competitor |
|---|---|---|
| Runtime cost | ✅ Direct HTTP request with lightweight text conversion | ❌ Full browser process with rendering overhead |
| Static page retrieval | ✅ Fast and predictable for server-rendered content | ❌ More machinery than necessary |
| JavaScript execution | ❌ Cannot render client-generated content | ✅ Browser automation executes page JavaScript |
| Interaction and sessions | ❌ No general login, clicks, or form workflow | ✅ Playwright maintains browser state and interactions |