Chrome DevTools | Third-party tools for AI agents
Chrome DevTools is adding third-party developer tools for Chrome DevTools for agents, giving web apps, frameworks, and libraries a way to expose runtime information directly to AI agents during debugging. Published on June 18, 2026, the experimental feature is designed to help agents understand internal state, component hierarchies, framework signals, and page behavior that cannot be fully understood from source code or the rendered DOM alone.
Chrome DevTools gives AI agents better runtime context
Modern web debugging is no longer only about reading source files or inspecting the final DOM. Many web applications rely on frameworks, CMS platforms, state systems, component trees, backend data, and runtime behavior that may not be obvious from the visible page. Chrome DevTools for agents is now experimenting with a way for third-party tools to expose that deeper context to AI coding agents.
For web designers and frontend teams, this matters because many UI bugs live between the design, the rendered interface, and the application logic. A button may appear correctly, but the component state may be wrong. A layout may render, but a signal, prop, or dependency may be causing unexpected behavior. Better runtime context can help agents debug those issues with more useful information.
How third-party developer tools work
The feature uses an event-based JavaScript API. Chrome DevTools MCP server discovers available tools by dispatching a devtoolstooldiscovery event on the global window object. A web application or library can listen for that event and respond with a ToolGroup that describes the tools it wants to expose.
Each tool can define a name, description, input schema, and execution logic. Once the tools are registered, an AI agent can discover them through list_3p_developer_tools and call them through execute_3p_developer_tool. For more complex debugging flows, agents can also use evaluate_script to run JavaScript in the page context and work with tool output more directly.
Why this matters for framework-heavy web projects
The most useful part of this update is that it lets frameworks and tools expose information that static analysis cannot see. A framework could map a visible DOM element to its component hierarchy, show internal state, inspect signals, or provide runtime data that explains why a UI is behaving a certain way.
This is especially relevant for projects built with tools such as Angular, React, Vue, WordPress, Shopify, animation libraries, CSS systems, or other abstraction-heavy workflows. In those environments, the rendered page is only one layer of the truth. The runtime state behind the page often explains the real bug.
Angular shows the early direction
Chrome is already working with the Angular team on early third-party developer tools. The examples include a Signal Graph tool, which can help agents understand relationships between state and view updates, and a Dependency Injection Graph tool, which can reveal where services are provided or missing.
That direction is important because many difficult frontend problems are runtime problems. Infinite loops, failed updates, missing providers, broken component relationships, and unexpected state changes are hard to solve from code reading alone. Giving agents a structured way to inspect those relationships could make AI-assisted debugging more practical for real web applications.
IMPORTANT: Third-party developer tools for Chrome DevTools for agents are experimental. The feature is available starting with Chrome DevTools for agents version 0.25.0 and requires the --categoryExperimentalThirdParty command-line flag, so APIs and behavior may change.{alertWarning}
What teams should check before testing it
Before adding this type of tool to a project, teams should decide what runtime information is safe and useful to expose. A good tool should have a clear purpose, a precise input schema, and a limited scope. It should help an agent debug a specific area instead of opening broad access to unrelated application data.
Security and context also matter. The technical guide notes that third-party tools run only in the context of the page that defines them and do not persist across origins. Even so, teams should review what the tool returns, avoid exposing sensitive data, and test the behavior carefully before using it in serious development workflows.
Daisuki's Take: What This Means for Web Designers
For web designers who work close to frontend code, this update points to a more useful kind of AI-assisted debugging. The agent is not only looking at files or guessing from the visible page. It can start to understand how the interface behaves at runtime, which is where many layout, interaction, and component issues actually appear.
We think this is especially important for template creators and frontend teams building reusable systems. A template, theme, or web app may look simple on the surface, but the real behavior often depends on components, state, CMS data, and conditional rendering. Better DevTools context can make agents more helpful when checking those layers.
The practical takeaway is to treat this as an early debugging direction, not a plug-and-play standard yet. If the feature matures, the strongest web projects will be the ones that expose useful structure, keep runtime behavior understandable, and still rely on careful human review before shipping changes.
Sources and Recommended Links
- Unlock runtime insights: Introducing third-party developer tools for Chrome DevTools for agents | Chrome for Developers Official Blog
- Chrome DevTools for agents | Chrome for Developers Official Documentation
- Developer Guide: Building third-party developer tools | Chrome DevTools MCP GitHub Documentation
