Are web scraping MCP servers safe? Running a third-party web data server in production

An MCP server from a web data vendor is not a different product from the vendor's REST API. It is the same scraping or search backend behind a discovery convention that lets a model choose the call. That makes the safety question narrower and more answerable than the general "is MCP secure" debate: the risk is not that the server scrapes, it is that the server returns arbitrary third-party page content into your model's context through a channel the model treats as trusted, and that it charges you tokens for the privilege on every single request.

Both of those costs are real and both are measurable before you commit. The schema cost is fixed and recurring. The content cost is variable and, for web data specifically, usually the bigger one, because a page body is orders of magnitude larger than a tool definition. The security cost sits on top of both and does not go away with a better prompt.

There is now a third cost, and it has a date on it. The MCP maintainers published a release candidate for a 2026-07-28 specification revision that removes the initialize handshake and protocol-level sessions outright, replaces server-initiated requests with a multi-round-trip pattern, and formally deprecates three capabilities. As of 27 July 2026 it is still a release candidate and the SDKs shipped for it are betas. That timing matters for procurement: "we have an MCP server" tells you nothing about which revision it targets, and the answer determines whether your integration survives the next twelve months. If you need the background on what MCP is and why models use it at all, our guide to MCP and tool use covers that; this one is about what running someone else's server costs you.

What a hosted web-data MCP server adds beyond a plain HTTP client

Very little, if your URLs are known in advance.

If you are ingesting a fixed list of 4,000 documentation pages into a vector store nightly, an MCP server is strictly worse than a REST client: you pay schema tokens, you inherit a protocol revision cycle, and you give up direct control over concurrency and retries. Write the HTTP client.

The MCP server earns its place when the model decides at runtime which page to fetch, and when the decision depends on what a previous fetch returned. That is a research agent, a support agent chasing a changelog, or a coding agent reading a library's docs. In that shape, the alternative to MCP is a hand-written tool wrapper you maintain yourself against the same API, and the vendor's server is a reasonable thing to not build.

The nine servers most commonly wired into web data pipelines split into three shapes:

Tool counts and surfaces change with releases, so do not take the last column as a spec. Call tools/list against your own key and count. That takes a minute and is the only number that describes what you will actually be billed for. For who ships what, our survey of web data MCP servers covers the vendor list; the columns above are about integration cost, not capability.

Token cost: schemas in every request, page content in every response

Two costs, and most published token-reduction advice addresses only the smaller one.

Schema cost is fixed per request. Every tool definition the server advertises is serialized into the request the model sees, before the user has said anything. An open issue in the modelcontextprotocol repository (#2808) frames the problem directly in its title, estimating roughly 1,000 tokens per tool consumed per session. Independent measurements published on DEV put GitHub's official 94-tool server near 17,600 tokens of schema per request. The web data servers above are mostly narrower than that, but Apify's Actor surface and the browser-control servers can get wide fast, and every tool you enable is rent you pay on every turn.

Response cost is variable and usually larger. This is the part the generic advice misses, because it is specific to web data. A markdown extraction call against a long article returns a page body. A crawl call can return dozens. Against a 128k context, one enthusiastic firecrawl_crawl can do more damage than every schema in your config combined. The mitigations are unglamorous: cap results per call, set a truncation or max-length parameter if the server exposes one, and route bulk work to the REST API where you control what gets summarized before it enters context.

Anthropic's engineering write-up on code execution with MCP argues the structural fix is to stop putting tool results in context at all and let the model write code that calls the tools, keeping intermediate results out of the window. Claude's own tool-search behaviour defers loading full tool definitions once the connected tool surface crosses roughly 10% of the context window. Both help with schemas. Neither helps with a 40,000-token page body that your agent asked for and now has to reason over. Decide what belongs in the context window before you connect anything.

The 2026-07-28 revision and the compatibility question to ask your vendor

The release candidate is not a point upgrade. The changes below are split by whether they break you now or later.

Source: the MCP maintainers' release-candidate post. The RC locked on 21 May 2026 with a validation window before the 2026-07-28 finalization date, which is one day after this guide was written. Treat everything above as the published plan rather than shipped history until you see the final spec and non-beta SDKs.

The question to put to a vendor is not "do you support MCP". It is: which revision does your server target today, and what is your dated plan for the stateless model? A vendor still on the 2025-06-18 or 2025-11-25 revisions is not wrong, but you need to know, because a stateless server and a session-based one have different failure modes behind a load balancer and different requirements on any gateway you put in front. The Register covered the stateless shift in late July 2026 and the framing there matches the RC: this is the largest structural change to the protocol since launch.

Deprecated capabilities and the costs they push back onto you

Three capabilities are deprecated in the RC under a new feature-lifecycle policy, and each pushes work back onto the integrator rather than deleting it.

Roots told a server which parts of a filesystem or URL space it was allowed to operate over. The stated replacements are tool parameters, resource URIs, or server-side configuration. For a web data server this mostly means domain scoping stops being a protocol concept and becomes a per-call argument you must remember to pass, or a vendor dashboard setting you must remember to check.

Sampling let a server ask your client's model to generate text on its behalf. The replacement is direct LLM provider integration. If a vendor's server used sampling to summarize a page before returning it, that summarization now either happens on the vendor's own model spend or lands on you as raw content, which quietly moves the token cost from their column to yours. Worth asking about.

Logging is replaced by stderr for stdio transports and OpenTelemetry for structured observability. This is the deprecation most likely to be discovered late, because it does not break anything at runtime. Your existing observability pipeline just stops receiving data, and a web data tool call that silently returns an empty page looks exactly like a page that was genuinely empty.

All three remain functional for at least twelve months from the deprecating revision, so the practical deadline is roughly mid-2027 and removal requires a separate approval step. That is enough runway to be complacent about, which is why it belongs on a dated migration ticket now rather than in a wiki page.

Provenance: pin to first-party server URLs, not registry names

MCP registries are convenience layers, not trust boundaries. The documented supply-chain pattern is name-squatting: registering a server whose display name closely resembles a trusted one, close enough to survive a glance during configuration. The mitigation is boring and it works. Resolve the server through the vendor's own documentation, record the exact URL or package name in your config as a pinned value, and treat a change to that value in a pull request as a security review rather than a dependency bump.

The reason to be strict is that MCP servers have already been used this way. UpGuard's incident roundup covers the Postmark MCP server case from September 2025, where the maintainer of a widely installed server shipped a version that silently BCC'd every sent email to an attacker-controlled address. Nothing about that attack required a protocol flaw. It required people installing a package by name and trusting the name. Trend Micro separately reported finding 492 MCP servers exposed to the internet with no authentication at all, which is the same failure at the deployment end.

Registry verification helps at the margin. Verified-publisher listings in the official registry are a signal, not a guarantee, and they do not survive a compromised maintainer account. Pinning does.

Remote OAuth servers versus locally installed packages

The trade is control against blast radius, and for web data specifically it usually resolves toward remote.

A remote hosted server (Firecrawl, for instance, publishes a hosted endpoint with a rate-limited keyless tier and a fuller tool set behind an API key or OAuth) gives you one network destination to allowlist, one credential to rotate, and one place to log. You do not control when it updates, which means you inherit changes you did not review, including tool-surface changes that alter your token bill.

A locally installed package gives you version pinning and a runtime you own, at the cost of an npm or PyPI dependency you now have to watch. The August 2025 compromise of official nx packages, which exfiltrated GitHub tokens, npm tokens and cached API keys from developer machines, is the case in point: local installation moved the attack onto the machine holding every credential.

For a production agent, put the remote server behind a gateway, allowlist its host at the egress layer, and pin the URL. For local development, pin exact versions and do not let an editor auto-update MCP packages. The one case that flips this is Playwright's local server and similar browser-automation tooling, where the whole point is driving a browser on a machine you control. There the comparison is with hosted browser infrastructure rather than with a remote MCP endpoint.

Untrusted page content arriving through a trusted channel

This is the risk that makes web data MCP servers different from a database MCP server, and no amount of token optimization touches it.

A tool result is, structurally, content the model treats as authoritative. A web data server's entire job is to fetch content written by people you have never met and put it in that position. Invariant Labs demonstrated the consequence in May 2025: a single malicious issue filed on a public GitHub repository, from a free account, was enough to get an agent using the GitHub MCP server to exfiltrate private repository contents. The server behaved correctly. The page content did the attacking.

That result generalizes badly to scraping. The GitHub attack at least needed a repository the agent had already been pointed at. A web data server fetches pages nobody vetted, chosen at runtime by the model itself, which is a wider opening than most agents have anywhere else. Counts of how many public MCP servers currently carry poisoned tool descriptions circulate widely and go stale within weeks; they are also the wrong number to plan against, because one hostile page is enough.

Three controls carry most of the weight:

Separate the agent that reads the web from the agent that acts. If the loop that fetches pages also has a tool that writes to your database, sends email, or opens pull requests, a prompt injection has a path to consequences. Split them and pass structured data across the boundary.

Constrain the return shape. Ask for structured extraction against a schema rather than raw markdown when the task allows it, so that free text has fewer places to hide instructions. This is one of the genuine arguments for structured extraction over raw page dumps.

Log the full call record. Tool name, parameters, a hash of the response, timestamp, and the calling agent identity. You cannot investigate what you did not record, and "the agent did something odd last Tuesday" is unanswerable without it. Our analysis of indirect prompt injection in agent pipelines goes deeper on the attack shapes.

Surviving enterprise review: shadow MCP, egress and audit trails

If your company has a security team, they have started asking about MCP, and the questions are predictable enough to prepare for.

Shadow MCP. Developers install servers locally because it takes thirty seconds. Nobody records it. The first ask in most enterprise reviews is an inventory of every MCP server running anywhere, including the ones on laptops. Produce it before you are asked for it.

Egress. Allowlist the specific hosts your MCP servers talk to and log denied outbound connections as potential exfiltration. A web data server is unusual here because its legitimate behaviour involves reaching arbitrary internet destinations, so the allowlist covers the server endpoint, not what the server fetches. Make that distinction explicit in the review, or you will spend a week arguing about it.

Identity and audit. OAuth-based identity binding on the server, per-agent tool allowlists so an agent only sees the tools it needs, and an immutable audit record per call. The per-agent allowlist is worth insisting on for a second reason: it is also the cheapest schema-token reduction available, because tools you do not expose are tokens you do not pay for. Security and cost point the same direction here, which is rare enough to use as an argument.

A short questionnaire for any vendor offering a hosted server

Send these before the pilot, not after.

1. Which MCP specification revision does your server target today, and what is your dated plan for the 2026-07-28 stateless model?
2. Does your server currently depend on Roots, Sampling or Logging, and if so what replaces each?
3. What is the exact first-party URL or package name, who has publish rights, and how are releases signed or verified?
4. How many tools does tools/list return on our plan, and can we restrict that surface per key?
5. Is there a maximum response size or truncation parameter, and what happens when a crawl exceeds it?
6. What auth do you support, what fields are in your audit log, and can we export them?
7. Are there rate limits or error semantics that differ between your MCP server and your REST API?

Question 7 catches more problems than the rest combined. Vendors frequently ship the MCP server as a thin wrapper over the same backend but with different defaults, and a default that was fine for a demo agent is not fine for a production one. Ask for the MCP server's rate limits in writing, separately from the REST plan you already signed.

The short version

Wire in a web data MCP server when the model chooses the URL at runtime, and use the REST API for everything else. Measure two token costs, not one, and expect the page body to dominate. Ask which spec revision the vendor targets before you ask about pricing, because the 2026-07-28 revision removes the handshake and the session and deprecates three capabilities you may be depending on without knowing it. Pin the first-party URL, split the reading agent from the acting agent, and log every call. None of that is exotic. It is the same discipline you would apply to any dependency that pipes hostile input into a system with credentials, which is exactly what a web scraping MCP server is.