Connecting N tools to M models used to require N×M integration layers. MCP decouples the tool side from the model side so each implements the protocol once. This article covers that design trade-off, its abstractions for browser environments and page actions, and what remains unsolved.
For an Agent to actually get work done, it usually ends up in a browser: logging in, posting, collecting data, or filling out forms. The hard technical problem is not whether it can click, but the integration cost of handing a browser to an Agent.
The N×M integration trap
Suppose there are N tools and M models on the market. Tool providers need a separate integration for each model, while the model side needs an adapter for every tool. Both sides maintain their own layers, producing N×M implementations in total.
The problem is the multiplication. Adding one tool does not add one unit of work; that tool has to be connected to every model. Conversely, when a model changes version, already connected tools may need to be validated again. A capability can be excellent, but if it lacks an adapter for a particular model, it cannot be used there—the tool gets stuck at the distribution layer.
Early on, everyone had to build their own integrations. The same tasks—listing environments, starting a browser, reading a page—had to be rewritten for each caller, and the logic was often inconsistent: one implementation put waiting in the client, another in the server.
The protocol decouples both sides
MCP (Model Context Protocol) was made public in late 2024. Its approach is to standardize tool discovery and invocation: what is exposed, how parameters are described, and what structure is returned are all defined by the protocol.
The architecture then becomes an Agent connected to an MCP Client, which connects to multiple MCP Servers according to the protocol; the actual capabilities sit behind those Servers. The implementation count drops from N×M to N+M: the model side implements the client once, and the tool side implements the server once.
There are only three roles. The Host is the application running the model and is responsible for starting the client. The Client is the protocol client implementation, generally one per Server. The Server is written by the tool provider and exposes capabilities as standardized tools.
There are currently two communication modes. Local mode uses standard input and output, with client and server on the same machine; the path is short and configuration is minimal, so it is common for automation. Remote mode uses HTTP or WebSocket and suits distributed deployments, at the cost of having to think more carefully about authentication and network boundaries.
In browser scenarios, three layers are exposed
When a browser environment is connected to the protocol, the exposed capabilities generally fall into three layers.
At the top is the environment layer: list the environments under an account, create one from a configuration, start a specified environment, bind it to a network egress, and shut it down when finished. These operations used to be scattered across vendor APIs; now they become tools that a model can discover and call. Starting an environment usually returns a debugging endpoint, such as a port or WebSocket address, which can then be passed to drivers such as Selenium or Puppeteer.
The middle layer is the page: open a URL, read the DOM or accessibility tree, switch tabs, and take screenshots.
The bottom layer is actions: click, type, scroll, wait for a condition, and handle pop-ups.
The key change is not how many actions exist. It is that an environment changes from code you must write yourself into a resource the Agent can choose and use. You only need to state the goal; it can decide whether to create a new environment or reuse an existing one, and in what order to call tools. This is especially visible when multiple environments run in parallel: scheduling lives in the prompt rather than being hard-coded in a script.
What remains unsolved today
The protocol solves connectivity, not correctness. Several easily overlooked issues remain.
The quality of tool descriptions determines invocation results. If parameters are wrong or the wrong tool is selected, the protocol cannot fix it. As the tool count grows, descriptions also consume context, so there is a trade-off between quantity and granularity. If tools are too coarse, the model cannot tell how many things one tool can do; if they are too fine-grained, the context fills up first.
Permissions and auditing are still at an early stage. Many servers are local, single-machine deployments that start with substantial privileges and lack fine-grained authorization or call records. Remote mode must first answer who may connect and what they may see.
Page instability has not disappeared. Missing element locators, uncertain load timing, expired login sessions, and CAPTCHAs still require waits, retries, and fallbacks. The protocol only standardizes the entry point.
Ecosystem maturity is uneven as well. Different servers do not fully agree on supported resource types, return structures, or error codes. When a task combines several servers, orchestration often still has to be written manually. The protocol itself is evolving, so behavior differences between versions need attention.
Another boundary must stay clear: the protocol governs how a model calls tools, not whether the task itself is compliant. Whether data collection is authorized, whether an account is being used for a legitimate purpose, and whether platform rules are being violated are separate judgments unrelated to how smoothly the connection works.
In multi-environment scenarios, isolation between environments and whether network egress, timezone, and language settings are configured as a coherent set often affect results more than the integration method. At the environment-isolation layer, PurpleMark provides environment creation, startup, and network-configuration interfaces that AI tools can call, allowing one client to schedule them.
This article explains technical principles only. Use the relevant protocols and tools in accordance with applicable laws and rules.
