MCP Fetch fixes robots.txt checks across redirects

Review the web-reading tool behind the assistant

The Model Context Protocol project published GHSA-3jqg-r5pp-rmp2 on October 25, 2026, describing a robots.txt enforcement gap in mcp-server-fetch redirects. The advisory rates it Low, lists versions 0.6.1 through 2026.10.19 as affected, and identifies 2026.10.24 as patched.

Organizations using this tool for autonomous web research should inventory the running package, update and test their actual invocation path. The reviewed advisory does not establish account compromise, internal-data disclosure or an active exploitation campaign.

A redirect changes the page the assistant actually reads

MCP connects AI applications with external tools. The Fetch reference server retrieves web addresses and can supply extracted text to a model. In autonomous fetching, robots.txt communicates which parts of a site a crawler should avoid.

Checking only the starting address leaves a gap when the response redirects to a disallowed path on the same site or another origin. The final content can therefore violate the destination’s crawler policy even though the initial address passed its check.

RFC 9309 distinguishes crawler policy from access authorization. A site containing private records still needs authentication and access controls; robots.txt is not a security boundary for confidential content.

Understand what the patch changes

The patched tool checks robots policy at each redirect hop. The current Fetch README distinguishes model-initiated tool calls from user-initiated prompts, which intentionally bypass robots.txt. The ignore-robots-txt option also disables enforcement. Updating does not override an operator’s explicit bypass configuration.

Private-address restrictions are a separate mechanism. The advisory states that the default private-destination guard already ran at each hop before this fix. Do not present this event as a newly fixed route into an internal network.

Friday Works recommends recording the package version, invocation type and startup flags independently. An identically named tool in two assistants need not have the same implementation. Inspect the process actually serving requests, rather than relying only on a repository configuration file.

A controlled local trial, with clear limits

Friday Works ran package 2026.10.24 against two locally owned sample paths: an allowed page and a redirect to a path disallowed by robots.txt. A direct MCP client returned the allowed sample and rejected the redirected destination with a policy error. No customer data or third-party target was used.

The photographs show actual MCP Inspector 2.12.0, the client observing the running Fetch server. Inspector’s version is distinct from the server package version. Private addresses were enabled only for the localhost fixture; disabling that guard is not a production recommendation.

These checks establish the tested cases, not every proxy, DNS behavior, long redirect chain or assistant integration. Operators need acceptance tests matching their own sources and policies.

An operational response for business assistants

Inventory assistants and jobs using mcp-server-fetch and record their running versions. Back up configuration, install a patched version and restart the correct process. Verify the executable afterward so that an upgraded environment is not mistaken for the one still serving the assistant.

Review tool versus prompt invocation and flags that bypass robots policy or allow private addresses. Retain authorization and network restrictions appropriate to the workload. Ensure a tool failure becomes a clear source-access failure to the user, rather than an answer implying successful retrieval.

Finally, test an allowed page and a disallowed redirect using resources the organization controls. Save the evidence before resuming unattended jobs. These are Friday Works operational recommendations, not evidence that every organization is affected or has lost data.

Next steps

Friday Works recommends testing against a copy and keeping evidence before changing a customer-facing system.