modelcontextprotocol / modelcontextprotocol/servers

Docs: `fetch` installs npm packages during a tool call, which is worth stating for deployments

Open Beginner friendly
#4,830 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
90.5k
Forks
11.7k
Avg merge
2d 2h
Merged PRs (30d)
5

Description

Hello, and thanks for the server. This is a documentation and deployment note rather than a bug
report, and the behaviour originates in a dependency rather than in this code.

While measuring where MCP tool calls cause outbound traffic to go, I drove mcp-server-fetch
(pinned at 2026.8.18, launched with uvx, inside a container behind a recording proxy) against
a corpus of URLs on a single reserved domain. On the first call that converts HTML, the server
opened a burst of connections to registry.npmjs.org: 82 requests on each of two runs, against 4
to the host the call actually named. The package caches were warmed before the proxy started, so
these are not the launcher's.

The cause is readabilipy, which runs npm install from inside the extraction path to fetch
@mozilla/readability and jsdom. I have raised the lockfile and stdout points with ReadabiliPy
separately.

The part that seems worth surfacing here is what it means for anyone deploying this server:

  • A tool call reaches a second package registry that the tool's documentation does not mention.
    In a deployment where egress is allowlisted, the first fetch of HTML fails in a way that is
    hard to attribute, because the failure appears inside an unrelated-looking conversion step.
  • The JavaScript executed is resolved at call time from unpinned ranges, so pinning
    mcp-server-fetch does not pin everything that runs. Two runs a day apart resolved different
    trees here.
  • npm's output reaches stdout, which is this server's JSON-RPC channel.

Possible responses, in increasing order of effort, and entirely your call:

  • A line in the README noting that HTML conversion may install npm packages on first use, and that
    registry.npmjs.org therefore belongs in an egress allowlist.
  • Pre-creating readabilipy's node_modules at image or install time, so nothing is fetched
    during a call.
  • Passing through whatever opt-out ReadabiliPy adds, so operators who want the pure-Python
    extractor can ask for it.

I am writing up the measurement and would rather you saw this before it is published than after.
Nothing in the write-up frames either project as vulnerable; the finding is about tool calls that
install code while they run, of which this is the clearest example I found.

I expect to publish in about 30 days, around 2026-10-19. That is my own timing rather than a
deadline for you, and there is nothing to embargo. If a correction or a fix should be reflected,
say so and I will wait.

Filed here rather than against the package alone because src/fetch lives in this repository. The upstream point about the lockfile is raised separately with ReadabiliPy at https://github.com/alan-turing-institute/ReadabiliPy/issues/122.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the README and the src/fetch area named in the report; review existing deployment and network-behavior documentation. Confirm the documented scope against the readabilipy and npm install details, then add a concise note about first-use HTML conversion traffic and egress implications. Done when operators can find this caveat without changing runtime behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, python, typescript
Domain
devops, documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.