Fetch MCP Server Guide 2026: Let Claude Read the Web as Markdown

Table of Contents

1. What Is the Fetch MCP Server?
2. Why Agents Need a Fetch Tool
3. The fetch Tool and Its Arguments
4. How to Install the Fetch MCP Server
5. Chunked Reading with start_index
6. robots.txt, Proxies, and Configuration Flags
7. Fetch MCP vs Firecrawl vs Browser Automation
8. What the Fetch MCP Is Great At
9. Security Considerations
10. Limitations
11. Verdict
12. Frequently Asked Questions

What Is the Fetch MCP Server?

The Fetch MCP server is one of the official reference servers maintained alongside the Model Context Protocol itself, in the modelcontextprotocol/servers repository. Reference servers exist to demonstrate core MCP features cleanly, and Fetch is the canonical example of "let the model read the web." It does exactly one thing and does it well: it exposes a fetch tool that takes a URL, makes an HTTP request, and returns the page content converted from raw HTML into Markdown so an LLM can actually use it.

That conversion is the whole point. Raw HTML is full of tags, scripts, and styling noise that waste context and confuse a model. The Fetch server strips that away and hands back readable Markdown — headings, paragraphs, lists, and links — which is dramatically more useful inside a model's context window. The server ships as the Python package mcp-server-fetch, runs locally as a subprocess, and needs no account, key, or external service.

Because it is a reference server, it is also a great teaching tool: if you want to understand how an MCP server is structured, Fetch is small enough to read end to end.

Why Agents Need a Fetch Tool

A language model's training data has a cutoff. The moment you ask it about something newer than that — a release note, a changelog, a docs page that changed last week — it is guessing. A fetch tool closes that gap by letting the agent pull the current contents of a page into its context on demand.

There are heavier ways to do this (full browser automation, managed crawling APIs), but most of the time you do not need them. A huge fraction of the web you actually want to read — documentation, blog posts, README files, API references, news articles — is static or server-rendered HTML. For those, a single HTTP request plus HTML-to-Markdown is all you need, and it is fast. No browser to spin up, no rendering engine, no extra cost.

That is the niche the Fetch MCP owns: the lightweight, zero-config, "just read this URL" tool that should usually be the first web capability you add to an agent. You escalate to browser-automation servers or Firecrawl only when a site genuinely needs them.

The fetch Tool and Its Arguments

The server exposes a single tool, fetch, with a small, well-chosen set of parameters:

• url (required) — the address to retrieve.
• max_length — the maximum number of characters to return. The server truncates beyond this to protect the context window.
• start_index — the character offset at which to begin extraction, which is how you page through a long document (covered in detail below).
• raw — when set, returns the raw HTML instead of the Markdown conversion, for the rare cases where you need the original markup.

In addition to the tool, the server provides a prompt that lets a user explicitly ask to fetch a URL. This distinction matters for robots.txt behavior, which we cover later: a model-initiated tool call and a user-initiated prompt are treated differently.

The design is deliberately minimal. There is no crawl depth, no link-following, no JavaScript execution — just "get this one URL and give me its readable content." That focus is exactly why it is so reliable.

How to Install the Fetch MCP Server

The Fetch server is a Python package, and the cleanest way to run it is with uvx, which executes it without a persistent install. In Claude Code:

claude mcp add fetch -- uvx mcp-server-fetch

For a JSON-config client such as Claude Desktop or Cursor, add a server entry:

{   "mcpServers": {     "fetch": {       "command": "uvx",       "args": ["mcp-server-fetch"]     }   } }

If you prefer a traditional install, use pip:

pip install mcp-server-fetch python -m mcp_server_fetch

After adding the server, restart your client and confirm the fetch tool appears in the MCP tool list. Smoke-test it with something like: "Use fetch to summarize https://modelcontextprotocol.io." You should get a clean, current summary within a couple of seconds. The Skiln Config Generator can bundle Fetch alongside your other MCP servers into a single paste-ready config.

Chunked Reading with start_index

Long pages are the classic failure mode for naive fetching: a 40,000-word documentation page will blow past any sane context limit. The Fetch server handles this elegantly with truncation plus the start_index argument.

When the agent fetches a long page, the server returns the first max_length characters and stops. If the model has not found what it needs, it simply calls fetch again with start_index set to where the previous chunk ended, reading the page in slices until the relevant section appears. It is paging, driven by the model.

This is smarter than it sounds. Instead of stuffing an entire page into context and hoping the answer is in there, the agent reads progressively and stops as soon as it has what it needs — saving tokens and staying focused. For long API references and sprawling guides, this chunked pattern is the difference between a tool that works and one that overflows.

robots.txt, Proxies, and Configuration Flags

The Fetch server ships with sensible, polite defaults and a couple of flags to override them.

By default, when a request originates from the model via a tool call, the server respects the target site's robots.txt. When a request is user-initiated via the prompt, it does not enforce robots.txt, on the reasoning that a human explicitly asking for a page is different from an autonomous agent crawling one. If you need the model's tool calls to ignore robots.txt as well — for example, against your own infrastructure — start the server with:

uvx mcp-server-fetch --ignore-robots-txt

To route requests through a proxy (useful for corporate networks or region-specific access), use:

uvx mcp-server-fetch --proxy-url http://your-proxy:8080

These two flags cover the vast majority of real-world configuration needs. Everything else is handled per-call through the tool arguments.

Fetch MCP vs Firecrawl vs Browser Automation

The three common ways to give an agent web access, side by side:

• Reach for the Fetch MCP first. It is the lightest tool and handles most documentation and article reads instantly.
• Step up to Firecrawl when you need to crawl many pages, extract structured data, or render JavaScript-heavy sites through a managed API.
• Use a browser-automation MCP when the task requires interaction — logging in, clicking, filling forms — or scraping a single-page app that builds its DOM client-side.

Many agents keep all three and let the model pick the cheapest tool that works. The Fetch server is almost always the right default.

What the Fetch MCP Is Great At

• Reading documentation on demand. Pull the current docs for a library before the agent writes integration code, so it uses the real API instead of a hallucinated one.
• Summarizing articles and posts. Hand the agent a URL and get a grounded summary from the live page, not a stale memory.
• Checking release notes and changelogs. Verify what actually shipped in a version by reading the page rather than guessing.
• Pulling reference data. Grab a spec, a standards page, or a pricing table into context for a question that depends on current facts.
• Lightweight research loops. Combined with a search tool, the agent searches, then fetches the most promising results to read them in full.

For deeper research workflows, pair Fetch with the best research and academic MCP servers and a documentation server from our documentation MCP roundup.

Security Considerations

There is one important caveat the maintainers call out explicitly: because the Fetch server makes HTTP requests on your behalf, it can reach local and internal IP addresses. On a machine that sits inside a private network, a malicious or careless prompt could ask the server to fetch an internal admin endpoint or metadata service, which is a classic server-side request forgery (SSRF) risk.

Treat the Fetch server like any tool that can make outbound requests:

• Run it in an environment where internal services are not reachable, or where they require authentication the server does not have.
• Be cautious about fully autonomous agents that fetch arbitrary, model-chosen URLs without review.
• Prefer the polite defaults (robots.txt on for tool calls) unless you have a specific reason to override them.

For a static-content reader this risk is modest, but it is real, and worth a moment of thought before you wire Fetch into an unattended pipeline.

Limitations

• No JavaScript rendering. Single-page apps that build their content client-side may return little usable text. Use a browser MCP or Firecrawl for those.
• One URL at a time. There is no crawling or link-following. For multi-page extraction you orchestrate the loop yourself or use a crawler.
• Truncation needs management. Very long pages require the start_index paging pattern; an agent that ignores it may miss content past the first chunk.
• Static output only. The server reads; it does not interact. No clicking, scrolling, or form submission.

None of these are flaws so much as the boundaries of a deliberately small tool. Know them and you will reach for the right server every time.

Verdict

The Fetch MCP server is the quiet workhorse of the MCP ecosystem. It is free, official, installs in one command, needs no key, and instantly gives your agent the ability to read the live web as clean Markdown. For the enormous category of "just read this page" tasks, nothing is faster or simpler. Its only real limits — no JavaScript, one URL at a time — are exactly the cases where you would reach for a heavier tool anyway.

If you are assembling an agent's toolset in 2026, the Fetch server should almost certainly be in it, as the default web-read capability you escalate beyond only when a site forces you to. Add it first, then layer Firecrawl and a browser-automation server on top for the harder cases.

Frequently Asked Questions

What is the Fetch MCP server?

The Fetch MCP server is an official reference Model Context Protocol server from the maintainers of MCP. It gives an AI client a single fetch tool that retrieves a URL from the internet and returns its contents converted from HTML to clean Markdown, so the model can read and reason over web pages without a browser. It ships as the Python package mcp-server-fetch and lives in the modelcontextprotocol/servers repository.

Is the Fetch MCP server free?

Yes. The Fetch MCP server is open source under the official modelcontextprotocol/servers repository and free to use. There is no API key, no signup, and no usage fee. You only pay for the underlying AI client. It runs locally as a subprocess, so the only cost is your own machine and bandwidth.

How do I install the Fetch MCP server in Claude?

The fastest path uses uvx with no separate install step. In Claude Code run: claude mcp add fetch -- uvx mcp-server-fetch. In a JSON-config client like Claude Desktop, add a server entry with command uvx and args ["mcp-server-fetch"]. You can also install it with pip install mcp-server-fetch and run python -m mcp_server_fetch. Restart the client and the fetch tool appears in the MCP list.

What does the start_index argument do?

The fetch tool truncates long pages to keep responses manageable. The start_index argument tells the server where to begin extracting content, so the model can read a long webpage in chunks. The agent fetches the first slice, and if it needs more it calls fetch again with a higher start_index, paging through the document until it finds what it needs.

Does the Fetch MCP server obey robots.txt?

By default, yes, when the request comes from the model via a tool call. It does not enforce robots.txt for user-initiated prompts. You can disable robots.txt checking entirely by adding the --ignore-robots-txt argument when you start the server. The server can also route through a proxy with the --proxy-url argument.

How is the Fetch MCP different from Firecrawl or a browser MCP?

The Fetch MCP is the lightweight option: one HTTP request, HTML to Markdown, no JavaScript rendering. Firecrawl and browser-automation servers like Playwright render full pages, execute JavaScript, crawl multiple URLs, and handle dynamic content, at the cost of more setup and heavier dependencies. Use Fetch for fast reads of static or server-rendered pages, and reach for Firecrawl or a browser MCP when a site needs a real rendering engine.

Can the Fetch MCP server render JavaScript-heavy pages?

No. The Fetch MCP performs a plain HTTP request and converts the returned HTML to Markdown. It does not run a headless browser, so single-page apps that build their content with client-side JavaScript may return little usable text. For those sites, use a browser-automation MCP or Firecrawl, which execute JavaScript before extracting content.

Where can I find other web and scraping MCP servers?

Skiln indexes web-fetch, scraping, and browser-automation MCP servers across every major registry. Read our roundup of the best browser automation MCP servers and our Firecrawl review for the closest alternatives, or browse the category directly at /mcps to compare stars and maintenance.

Last updated: June 28, 2026 · Skiln tracks new MCP servers daily across 13 source registries including PulseMCP, Smithery, Glama, and LobeHub.