Scraping vs MCP Wrappers vs Browser Agents: How Your AI Agent Reads the Web

When an agent needs data or actions on a site that publishes no API, the access path you pick now determines which failure you get: legal exposure you did not engineer for, wrapper brittleness you did not budget for, or passive detection you cannot evade at the network layer. That is the useful finding from a cluster of 2025-2026 research, anchored by ScrapeBench, which its authors describe as the first agentic benchmark for evaluating AI-agent compliance with website scraping policies. Its central measurement is uncomfortable: “under neutral prompts, most AI agents in our experiment scrape prohibited websites and only refuse to do so once the ToS and robots.txt are explicitly inserted into prompts.”

In other words, out of the box, agents do not comply. Compliance is a behavior you install, not a behavior you inherit. That reframes the whole build decision. The question is not whether scraping is fast or cheap; it is which of the three access paths, direct scraping, a deterministic site-to-MCP wrapper, or a browser agent, has a dominant failure mode your system can actually absorb.

This piece builds that comparison as a decision matrix. None of it is legal advice, and the limits of the evidence are spelled out where they matter.

Three ways in, three different machines

The three paths look similar from the product requirements doc and behave nothing alike in production:

• Direct scraping: the agent (or its harness) fetches and parses HTML itself, sometimes with headless rendering, and extracts what it needs. Cheap, direct, and, per ScrapeBench, noncompliant by default.
• Site-to-MCP wrappers: a vendor or in-house tool generates a deterministic interface, often an MCP server, that turns a specific site into structured tools your agent calls. The current pitch: “Our deterministic integrations are significantly faster (2-4x), cheaper (10-1000x), and more reliable (+30%) than browser use,” per Pomerado’s Y Combinator listing, plus self-healing APIs that “identify site changes and automatically kick off repairs.” Those figures are launch marketing with no disclosed methodology, so treat them as vendor-reported claims to test, not results.
• Browser agents: the agent drives a real browser, clicking and typing like a user. Maximum generality, maximum surface area, and, per a fingerprinting study, a detection problem that network-layer evasion does not touch.

What ScrapeBench actually measured

The finding that should change default behavior is narrow and well-supported: with a neutral instruction, most agents in the authors’ experiment went ahead and scraped sites whose terms prohibit it. Only when ToS and robots.txt text was inserted directly into the prompt did agents refuse. If your architecture assumes the model will notice and respect a site’s scraping policy on its own, the measured default says it will not.

The practical consequence is that compliance has to be engineered at the architecture level: fetch the policy, inject it, and gate on it, rather than trusting prompt-invisible behavior. That is a real cost of the scraping path that rarely appears in time-to-first-data comparisons.

Two scope limits keep this honest. The authors evaluate “each trial in isolation, where a single AI agent attempts to scrape the landing page of a website,” and “currently do not cover multi-turn, multi-trial, or multi-agent task decomposition due to time and compute costs.” And they state that ToS and robots.txt enforceability “varies across jurisdictions and may depend on factors that we do not evaluate with ScrapeBench.” So ScrapeBench measures default agent behavior under prompts, not settled legality in your jurisdiction. Those are different things, and the matrix rests on the former.

The hidden middleman in your scrape

ScrapeBench also surfaced an operational detail worth more attention than it usually gets. In the GPT-5.2 trials, the agent retrieved website content through a third-party reader and proxy service, per ScrapeBench, for 21.6% (409) of the website data, and 2.6% of the websites blocked the agent at the outset. If a fifth of your scraping traffic silently routes through an intermediary you did not choose, your compliance engineering has a second problem: the policy you injected governs your agent, not necessarily the proxy your agent hired. When you audit a scraping pipeline, audit what it actually calls, not what you think it calls.

The economics of the interface

On cost, the strongest evidence favors structured access over raw HTML. A comparison of web interfaces for agents found that “indexed (RAG) or API-based (MCP and NLWeb) access reduces token consumption by roughly factor three and runtime by factor five compared to HTML.” That is an average across that benchmark’s task mix, not a promise for your workload, but the direction is consistent with the mechanism: feeding an agent a full page of markup, navigation chrome, and script noise is an expensive way to answer “what is the price of this flight.”

This is the legitimate core of the wrapper pitch. Wrapping a site into structured tools attacks exactly that waste, and the roughly 3x tokens and 5x runtime deltas give you a defensible sizing model when the volume of reads is high and the pages are heavy.

Wrappers shift the failure; they do not remove it

Here is where vendor determinism claims meet independent evidence, and the meeting is rough. A wrapper can make the site-to-tool boundary deterministic. It cannot make the agent deterministic, and the agent is most of the system.

• End-to-end success is well under half. Benchmarking top models against real-world MCP servers found “even top-performing models such as GPT-5 (43.72% success rate), Grok-4 (33.33% success rate) and Claude-4.0-Sonnet (29.44% success rate) exhibit significant performance limitations.” If your wrapper is perfectly reliable and the model completes the task 44% of the time, your pipeline is 44% reliable, per that same benchmark.
• Faults hurt, and scale did not buy fault tolerance in the tested pair. Under calibrated MCP faults, researchers report “severe, pervasive quality degradation,” that “scale does not purchase fault tolerance for the two gpt-oss backbones we test,” and that “framework-level error handling plausibly matters more than model scale.” Reliability money is better spent on retries, validation, and graceful degradation in the harness than on model upgrades.
• More wrapped sites means worse tool selection. Prior evaluations “consistently show that LLM tool-selection accuracy degrades as the number of available tools grows, with reported losses of up to 85%,” per a summary in an empirical study of API wrapping. Wrapping fifty sites into fifty tools is not a linear scale-up; the agent’s ability to pick the right tool decays as the surface grows. This is a structural brittleness of the wrapper approach that no wrapper vendor’s code quality can remove.
• The security posture changes class. Injection, traversal, and execution patterns “together account for 66.7% of the dataset” in an MCP vulnerability study built on a validated snapshot of 24 vulnerabilities, so read that share as an early map of the attack surface rather than a large-sample rate. Moving from scraping to wrapped access trades blocking and ToS exposure for injection-class code risk. That trade may be right for you, but it is a trade, not an upgrade.

So when Pomerado’s listing promises determinism, speed, and reliability wins over browser use, read it as a claim about the site-to-tool boundary, not about your agent’s end-to-end behavior. The independent numbers above are the counterweight, and until someone tests a site-as-MCP wrapper product end to end, the 2-4x / 10-1000x / +30% figures from its Y Combinator listing remain unverified marketing.

Browser agents leave fingerprints you cannot rotate

The detection story for browser agents got a concrete number this year: “UI actions from agent traces can fingerprint the underlying model of an LLM-based web agent with up to 96% F1 across 14 frontier models,” per the UI-trace fingerprinting paper. The signal is “typically recoverable from few observed events, does not rely on network-layer visibility, and is passive.” Rotating IPs and user agents addresses network-layer detection; it does nothing about a behavioral fingerprint visible in the click stream itself, readable by any site operator who logs UI events.

One important qualification from the same work: “the fingerprint is conditioned on the harness: classifiers trained on one harness do not transfer to the other, and pooled training is required.” Detection is feasible and passive, but a site operator needs training data from your harness class to do it well. That lowers the odds of casual detection and raises the odds of detection by motivated, well-resourced operators, which is to say, precisely the operators whose prohibitions matter most.

There is a counter-consideration in the other direction too. Because browser agents behave like users, they are sometimes the only path to sites that resist structured access entirely, and a browser session run on infrastructure the site operator has explicitly authorized (a declared-access arrangement, a partner sandbox, your own logged-in account under terms that permit automation) is not the situation the fingerprinting study models, which characterizes a passive, co-located adversary. Whether detection carries any cost under an authorized arrangement depends on what the authorization actually covers, including volume, methods, and scope, and none of the cited evidence settles that.

The decision matrix

Mapping each path to its dominant failure mode, with the evidence class for each row:

What this evidence cannot settle

Be honest about the gaps before acting on the matrix:

• No cited evaluation tests any site-as-MCP wrapper product end to end. The matrix reconciles vendor claims with adjacent independent evidence; it is not a head-to-head trial of Pomerado or any competitor.
• ScrapeBench’s site scope is documented but narrow, and it says nothing about legality. The benchmark covers 1,895 websites drawn from the February 2026 CrUX top-3,000, filtered to high-traffic, English, US-accessible sites, of which 1,626 explicitly prohibit scraping, per ScrapeBench, and its authors limit findings to isolated single-agent, single-turn landing-page trials. Enforceability of ToS and robots.txt varies by jurisdiction, and the benchmark measures compliance with stated policies, not settled law in yours.
• The efficiency deltas (roughly 3x tokens, 5x runtime) come from a different benchmark with its own task mix. Expect the direction to hold and the magnitude to move.
• This is a measurement story, not a news ticker. Nothing here depends on any particular operator’s announcement from a given week, and the cited evidence does not track site-by-site blocking policy. The closest sourced signal about direction comes from the fingerprinting paper, which frames the arrival of “agent-aware” web infrastructure as a world where the operative question is “no longer whether a client is human or automated.” Whether a specific site is restricting agent traffic today is outside what this evidence can settle.

How I would decide

Start from the failure you can absorb, not the demo that impressed you.

If the target site’s terms permit what you need, or you can obtain permission, scraping behind explicit policy injection and egress auditing is the cheapest correct path. If it does not, do not let a neutral prompt make that decision for you; ScrapeBench measured what it will do.

If read volume is high and pages are heavy, the token and runtime evidence argues for wrapped or API-style access, but budget honestly: assume end-to-end success well under half until your own evals say otherwise, keep the tool count small, put error handling in the harness rather than in a bigger model, and threat-model the MCP surface for injection before you connect it to anything that acts. Verify any vendor’s determinism and self-healing numbers on your own sites before they enter a capacity plan; a bounded trial on sites you can afford to re-scrape is the right verification step, and it is a step, not an assurance.

If you reach for a browser agent because nothing else fits, assume the site can learn what you are from how you click, and that better proxies will not change that.

The common thread across all three paths is that site-operator pushback is moving compliance out of the infrastructure layer, where IP blocks and rate limits used to carry it, and into your access architecture itself. The teams that treat ToS injection, tool-surface hygiene, and detection posture as design inputs will spend less time rebuilding than the teams that discover them as incidents.