Building Agent Interfaces: Lessons from Chrome DevTools (MCP) for Agents

A coding agent asked to make a web page faster needs a way to measure what its changes accomplish. Human developers already use Chrome DevTools to inspect errors, audit pages, and profile performance. The opening demonstration puts those capabilities into an agent’s workflow: Gemini CLI, configured with Chrome DevTools MCP, opens Chrome, records a performance trace, examines the returned insights, changes the page, and measures again to validate the result. The recorded demonstration makes the debugging loop concrete: observe the browser, act on the evidence, and check the effect.

MCP—the Model Context Protocol—provides the tool interface between the browser-debugging server and the agent harness. The demonstration uses Gemini CLI, but the talk also names Claude Code, Codex, and OpenClaw as compatible clients. Michael Hablich, Google’s product manager for Chrome Developer Tools, presents the engineering lessons behind building that interface for agents.

The team built the interface because coding agents could generate code but lacked a way to validate its behavior in the browser. Its first assumption was that giving an agent enough browser data would solve the problem. In the early experiment described in the talk, a performance trace contained multiple megabytes of data and roughly 50,000 lines of JSON. Passing that trace to then-common agent harnesses overwhelmed their context windows, according to the speaker. This was a failure of the interface in that historical setup: the relevant evidence was present, but the agent could not usefully reason over the volume it received.

The performance endpoints therefore began returning semantic summaries in Markdown: concise output that surfaces relevant measurements, including Largest Contentful Paint (LCP) and Interaction to Next Paint (INP). Raw traces remained available for post-processing with other tools. The change was analogous to pointing a reader to the relevant sentence instead of requiring them to read an entire book before answering a question.

Humans and agents share the debugging goal—identify an error and fix it—but encounter different bottlenecks. A human can scan the DevTools console using layout and color, then investigate through its read–evaluate–print loop, or REPL. An agent-facing interface instead needs clear schemas and useful textual information density. Treating agents as a distinct user segment changes both what the interface exposes and how it presents the result.

Four engineering concerns follow from that distinction: token burn, error recovery, tool discoverability, and trust boundaries. Token burn comes first because interaction overhead has a direct cost. The talk compares a cumbersome API to a fourteen-step checkout flow: each additional exchange demands more work from its user. For an agent, returned data occupies context, while further reasoning and tool interactions consume additional tokens and time.

Tokens per successful outcome connects that cost to whether the agent accomplishes anything useful. It requires keeping two dimensions visible:

• Effectiveness: Does the agent complete the entire user journey and fulfill the user’s functional intent?
• Efficiency: How many tokens and tool calls does the journey consume, and how long does it take?

The fuel-efficiency analogy has a limit: an economical journey is of little value if it never reaches its destination. Reducing token use cannot substitute for measuring success.

Compare tokens per successful outcome within the same user journey or task class. Extracting information from a website is relatively cheap in the talk’s examples. Diagnosing why a responsive layout is broken requires a more intricate, interactive investigation and can reasonably consume more tokens. A useful decision rule is to compare interface changes on the same kind of task, checking completion alongside cost; a global average across scraping and debugging would obscure the difference in work.

The internal-project chart shown in the talk organizes effectiveness by use case. Longer bars represent more effective behavior; shorter bars identify journeys that deserve investigation and improvement. It serves as a way to decide where to work next, rather than as a single score for the whole interface. Measurement is not straightforward, but even imperfect measurements can make those decisions better informed than intuition alone.

Chrome DevTools approaches token reduction in three ways. The first is tool categorization: specialized capabilities are enabled through command-line parameters instead of appearing in every agent’s default context. Chrome extension debugging is the example. An agent working on an ordinary web page has no reason to carry descriptions of extension-specific tools throughout its session.

The second approach, slim mode, pushes that reduction further. The version described in the talk exposes only select_page, navigate_page, and evaluate_script. A smaller tool surface reduces the context occupied by tool definitions, but it can force additional turns or leave a necessary capability unavailable. The speaker gives network-request inspection as an example of functionality missing from the described slim set. The relevant comparison is therefore total work required to finish the task, not just the size of the initial tool list.

Editor: The current slim-tool reference lists navigate, evaluate, and screenshot. Those names differ from the recording; use the current documentation when configuring today’s interface.

The third approach is a command-line interface offering nearly the same functionality as the MCP server. It lets the agent compose operations and perform intermediate processing locally. The demonstrated pipeline follows this sequence:

1. Obtain the page’s accessibility tree, which represents accessible elements such as controls.
2. Filter the tree with grep to obtain the relevant control’s identifier.
3. Pass that identifier to a click command.

The computer processes the intermediate tree rather than sending all of it through the model. This moves suitable filtering work out of the agent’s context while retaining the browser action the task requires.

An efficient interface still fails its user if the agent gets stuck. Errors create additional work: the agent must understand the failure, decide what to change, and retry. Recovery behavior therefore affects both completion and token cost.

The talk develops recovery as a spectrum of increasingly proactive support:

• Explain the reason. In the back-navigation example, the selected page lacks a suitable history entry. The speaker reports that adding an explanatory sentence to the error enabled the agent to recover without a human fixing the problem. A failure message becomes useful when it gives the agent information it can act on.
• Provide proactive detours. Models arrive with tool preferences shaped by training. For performance profiling, the interface directs the agent toward the performance-trace tool instead of a Lighthouse audit, counteracting a learned route that does not match the intended workflow.
• Supply diagnostic playbooks. A troubleshooting skill helps the agent and human diagnose Chrome DevTools MCP setup problems. This gives recurring installation failures a structured recovery path.

Together, these mechanisms make the interface more resilient to mistakes and reduce the chance that a recoverable problem becomes a terminal failure.

Recovery handles mistakes after they occur; discoverability helps prevent them. The initial design exposed one broad tool, Debug Webpage, to which another agent could send a request such as investigating a broken responsive layout. That was appealing from an engineering perspective, but the speaker reports that it did not work well. The team replaced the monolithic tool with 25 tools, according to the talk. This introduced a different problem: the agent now had to choose which tool to use and when.

The talk cites Model Context Protocol (MCP) Tool Descriptions Are Smelly! for the finding that roughly 97% of analyzed MCP tool descriptions had quality smells. Descriptions matter because the schema is the agent’s interface: it is where the agent learns what a capability does and whether it fits the task.

Editor: The February 16, 2026 version of the paper examined 856 tools across 103 MCP servers. The figure concerns that sample, not a census of the MCP ecosystem.

Adding description text has costs of its own. Longer descriptions occupy more context, and the speaker warns that smaller models can become biased toward invoking tools that are not appropriate for the task. Description quality is therefore not equivalent to description length.

Two elements make a description useful:

• Purpose: State the tool’s core function clearly.
• Activation criteria: Explain when the agent should use it.

The performance-tracing description connects frontend performance investigations with Core Web Vitals, naming LCP, INP, and Cumulative Layout Shift (CLS). That vocabulary helps an agent connect a request to improve page loading with a relevant tool. Finding the minimum useful description remains an ongoing optimization problem because models and harnesses keep changing.

Skills can add guidance for more intricate workflows, but they move the same trade-off to another layer. Too many skills increase context and create more opportunities for irrelevant invocations. Their value depends on whether the agent can discover and activate the right guidance for the current task.

Once cost, recovery, and discovery improve, a more capable interface raises a further question: what is the agent allowed to access? Chrome DevTools’ auto-connect feature lets a coding agent connect to the browser context where a human is encountering a problem. Users asked the team to remember their Allow choice so they would not have to approve repeatedly. The team deliberately retained that friction. Delegating browser work requires an explicit trust boundary, even when removing a click would make the interaction easier.

The talk invokes Simon Willison’s lethal trifecta for AI agents as a framework for reasoning about that boundary.

Editor: Willison’s framework combines private-data access, exposure to untrusted content, and the ability to communicate externally. The current Chrome DevTools MCP documentation says auto-connect can access all open windows in the selected default profile. That scope can extend beyond the page the user wants to debug.

The talk distinguishes three browser-agent deployment environments, each requiring a different access model:

These tiers distinguish access to a human’s working browser from controlled automation and from agents encountering arbitrary internet content.

Returning to local development, the speaker identifies the default browser profile as a place where the trifecta’s risks can come together. That is the reason for requiring human consent for each connection. A local coding assistant and a fleet of browsing or research agents may use the same Chrome DevTools interface, but they require different security models. Sharing the tool does not make their data access or authorization requirements interchangeable.

Agent experience extends user experience to another user segment, with its own requirements for efficiency, discoverability, security, and stability. Those requirements shape the interface throughout a task: the cost of reaching a successful outcome, the path out of an error, the clarity of a tool’s intent, and the authority granted to use it. A useful agent interface must support all of those properties together.