MCP Fetch server mcp-fetch 2026.10.24: our test log
The MCP Fetch server 2026.10.24 refused to fetch a local test page by default (a deliberate loopback block); with --allow-private-ips it fetched it in 698.3 ms median.
Tested by us on 2026-10-25. Local open-weight model, not the vendor's hosted models. A smoke test on a CPU-only box, not a benchmark.
Result at a glance
| Field | Value |
|---|---|
| Result | Passed |
| Version tested | mcp-fetch 2026.10.24 |
| Date and time | 2026-10-25, 22:37 to 22:38 CDT (America/Chicago) |
| Task | A small Python client written with the official MCP Python SDK (2.3.0) spawns the server as a child process over stdio, times the initialize handshake (cold start: spawn to initialize result), times one tools/list, then times 30 sequential tools/call requests and reports the median and 95th percentile. Numbers are milliseconds on the rig described on the methodology page. |
| Model used | none (no language model involved) |
| Hardware | Linux x86_64 virtual machine (Debian 13), 8 vCPU (Intel Xeon, 1 thread per core), 15 GiB RAM, no GPU |
| Default (loopback blocked) | cold start 533 ms; tools/list 1.9 ms (1 tools); 30 x fetch: median 6.2 ms, p95 6.8 ms [tool returned an error] |
| --allow-private-ips | cold start 538 ms; tools/list 2.5 ms (1 tools); 30 x fetch: median 698.3 ms, p95 796.3 ms |
What we found
- Out of the box the server refuses loopback, private and link-local addresses and says so: 'Refused to fetch http://127.0.0.1:8099/robots.txt: 127.0.0.1 resolves to 127.0.0.1, which is not a public address. Start the server with --allow-private-ips to allow private, loopback and link-local addresses.' We count that as the correct, safe behaviour and recorded it as an error in the latency row.
- Fetching from a local server with --allow-private-ips took 698.3 ms at the median (p95 796.3 ms), far slower than the other servers where the likely cause is the extra robots.txt request it makes before the page (we did not isolate it).
- The test used a local page, not the public internet; real-site latency depends on the site.
What we ran, step by step
| Step | Wall time | Exit code | Notes |
|---|---|---|---|
| Install with uv (cold, no cache) | 1.85 s | 0 | mcp-server-fetch 2026.10.24; 51 MB on disk; load 4.16. |
| Latency run: Default (loopback blocked) | n/a | 0 | mcp-fetch 2026.10.24 (protocol 2025-11-25). cold start 533 ms; tools/list 1.9 ms (1 tools); 30 x fetch: median 6.2 ms, p95 6.8 ms [tool returned an error]. Load 2.38. |
| Latency run: --allow-private-ips | n/a | 0 | mcp-fetch 2026.10.24 (protocol 2025-11-25). cold start 538 ms; tools/list 2.5 ms (1 tools); 30 x fetch: median 698.3 ms, p95 796.3 ms. Load 1.70. |
# Install with uv (cold, no cache)
uv venv -q -p 3.13 work/pymcp/mcp-server-fetch && VIRTUAL_ENV=work/pymcp/mcp-server-fetch uv pip install --no-cache -q mcp-server-fetch
# Latency run: Default (loopback blocked)
work/pymcp/mcp-server-fetch/bin/mcp-server-fetch
# Latency run: --allow-private-ips
work/pymcp/mcp-server-fetch/bin/mcp-server-fetch --allow-private-ipsRaw output (excerpts)
fetch({"url": "http://127.0.0.1:8099/test.html"})
Error executing tool fetch: Refused to fetch http://127.0.0.1:8099/robots.txt: 127.0.0.1 resolves to 127.0.0.1, which is not a public address. Start the server with --allow-private-ips to allow private, loopback and link-local addresses.Gotchas and things that broke
- If you test a fetch server against localhost you will get an error that looks like a bug. It is a guard against server-side request forgery; the flag turns it off, so only use it on a trusted machine.
- The fetch server requests robots.txt before the page, which is why the error mentions robots.txt even though we asked for test.html.
What we did not test
- Remote (HTTP) transport, authentication and concurrent clients: only local stdio with one client was measured.
- Large payloads: calls used tiny inputs, so these latencies are protocol and process overhead, not throughput.
- Anything about answer quality: no model was involved in the latency numbers.
- These are single smoke-test runs; it is not a benchmark. The machine was shared with other jobs.
Reproduce it
Versions change. These commands install whatever is latest on the day you run them unless a version is pinned, so expect different results later. The version we measured is in the table above.
uv venv .venv && VIRTUAL_ENV=.venv uv pip install mcp-server-fetch
.venv/bin/mcp-server-fetch --allow-private-ips # only for local testingHow to read this test
Every number on this page was measured on this one machine, which also ran other jobs, so timings are indicative and vary run to run. A pass means our small task worked once or as stated, a fail means it did not work as we ran it; neither says how the tool behaves with a vendor's frontier model, on a GPU, or at scale. Where a tool could not run without an account or a GPU, we say so instead of guessing.
See the testing rig for the hardware, the local model and the rules we follow, and the test hub for every other test.
Related tests: mcp servers and tooling
- MCP Filesystem server: MCP Filesystem server answered over stdio in 279 ms cold (v1.0.0, Node 20) and 187 ms (v2.0.1, Node 24); median call 0.8 to 1.0 ms.
- MCP Git server: The MCP Git server 2026.10.19 started in 512 ms, listed 12 tools and answered git_status in 3.2 ms median.
- MCP Inspector (CLI mode): MCP Inspector listed the filesystem server's 14 tools from the command line on both 0.15.0 (Node 20) and 2.12.0 (Node 24) in under a second; the 2.x install is smaller.
- MCP Memory server: MCP Memory server answered over stdio in 284 ms cold (v1.0.0, Node 20) and 147 ms (v2.0.0, Node 24); median call 0.9 to 0.6 ms.
- MCP Sequential Thinking server: MCP Sequential Thinking server answered over stdio in 271 ms cold (v1.0.0, Node 20) and 159 ms (v2.0.0, Node 24); median call 0.8 to 0.4 ms.
- MCP Time server: The MCP Time server 2026.10.19 started in 483 ms and answered get_current_time in 0.8 ms median.
Sources
- MCP reference servers repository (fetched 2026-10-25)
Related
Markdown version for agents: /tests/mcp-server-fetch.md