MCP's architecture elegantly handles cooperative data sources. But web environments operate on fundamentally different principles. The distinction matters because it determines whether systems can operate reliably or constantly fight the environment they're built on.
At TinyFish, we build enterprise web agent infrastructure that operates on live web surfaces. That operational experience reveals what happens when architectural assumptions designed for cooperative environments encounter adversarial ones. Not adversarial in intent, but in how they function.
Environments That Resist Automation
The web wasn't designed to be automated. Sites implement bot detection not from hostility but necessity: distinguishing human users from automated access protects infrastructure and user experience. Authentication isn't a single OAuth flow. It's maintaining session state that sites use to verify behavioral legitimacy. Structure changes constantly because sites optimize for human visitors, not programmatic access.
When Microsoft released Playwright-MCP in August 2025, the implementation exposed these tensions. The protocol requires three different session modes: persistent, isolated, and extension. The isolated mode's behavior reveals the friction: storage state is lost when sessions close.
For API connections, that's fine. For web automation, it means authentication state disappears. The extension mode's requirement for connecting to existing browser instances via Chrome DevTools Protocol (to enable "automation of logged-in sessions without credential re-entry") shows that web environments need different architectural thinking than cooperative data sources.
Where Architectural Assumptions Break Down
When we're operating web agents monitoring thousands of sites, we see exactly where MCP's stateless connection model meets environments that track session behavior.
The other side actively resists automation. Sites implement CAPTCHAs, rate limits, and behavioral analysis. Not because they're hostile, but because protecting their systems requires it. The architectural assumption that both sides want the connection to succeed doesn't hold.
State accumulates differently. Sessions aren't just authentication tokens. They're behavioral signals sites use to verify legitimacy: mouse movements, timing patterns, navigation sequences. MCP's stateless design optimizes for environments where state means API keys, not accumulated behavioral proof.
Structure is deliberately unstable. Sites implement A/B tests, adjust layouts based on user patterns, and change structure without notice. There's no stable API contract. The assumption of standardized interfaces doesn't map to environments designed for human adaptability.
The CVE-2025-6514 vulnerability disclosed in July 2025 revealed critical remote code execution flaws in MCP's mcp-remote proxy. Security researchers identified prompt injection through indirect attacks, tool poisoning, lookalike tools. These aren't just bugs. They're signals about what happens when protocols designed for trusted environments meet untrusted ones.
"There SHOULD always be a human in the loop with the ability to deny tool invocations"
MCP's security specification treats security as a usage pattern rather than an architectural requirement. For cooperative data sources, that's reasonable. For adversarial environments, it reveals where protocol assumptions meet different operational realities.
The Architectural Boundary
MCP's adoption validates its value for AI-to-data-source integration. But architectural assumptions designed for cooperative environments meet fundamentally different principles in adversarial ones.
Cooperative environments (databases, APIs, business tools) want to be accessed. MCP's stateless connections, standardized authentication, and stable interfaces work elegantly. Adversarial environments (web surfaces designed to resist automation) operate differently. Session state matters. Structure changes. The other side implements measures to identify and block automated access.
Understanding when architectural assumptions designed for cooperative environments meet ones that actively resist automation matters. For web automation at scale, that distinction determines whether your infrastructure can operate reliably in environments that weren't designed to be automated, or whether you're constantly fighting characteristics the protocol was never built to handle.