RFC: GraphQL Support for Chrome DevTools MCP

Is your feature request related to a problem? Please describe.

This is an Request For Comments issue. This is a proposal that we would like to get feedback on, before proceeding with implementation. Please add your thoughts and upvotes.

The current MCP interaction model creates a "chatty" and observation-heavy protocol. While the CLI wrapper (https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/797) successfully addresses Action Batching by allowing agents to execute sequences of commands in a single bash script, agents still face a bottleneck in Data Orchestration.

To diagnose a failure or gather context, an agent currently must perform multiple "Read" calls—such as list_console_messages, list_network_requests, and take_snapshot. This leads to:

Over-fetching: Agents receive massive JSON blobs with irrelevant metadata, consuming excessive context window tokens.

Observation Latency: Multiple round-trips are required to assemble a complete picture of the browser state.

Disjointed Relationships: Agents must manually "join" related data, such as connecting a console error to the specific network request that triggered it.

Describe the solution you'd like

I would like to discuss the introduction of a query_devtools tool that provides a GraphQL interface to the browser state.

This tool would allow agents to act as "frontends," performing high-density, single-turn data fetches where they "cherry-pick" only the exact attributes needed from multiple sources like console and network data.

Example agent-authored query:

{
  currentPage {
    url
    # Only get errors, and only get the message + stack
    consoleLogs(level: "error") {
      message
      stackTrace
    }
    # Link network failures to their specific response codes
    networkRequests(filter: "failed") {
      url
      status
      method
    }
  }
}

Key Benefits:

• Token Efficiency: Agents can request specific fields, preventing "token explosion" from large, unoptimized resource reads.
• Relational Depth: The schema would allow agents to "walk" the graph—for instance, fetching the initiator script source of a failed network request in the same call as the request itself.
• Self-Healing Documentation: Agents can use GraphQL introspection to discover the schema, similar to how they use --help for the CLI, reducing hallucinations regarding available data fields.

Describe alternatives you've considered

MCP Resources: While the standard MCP Resource spec is excellent for fetching specific "file-like" resources, it lacks the ability to filter fields or join multiple data types in a single request, which can lead to the "chatty" behavior we are trying to solve.

Extended CLI Flags: We could add more complex flags to CLI commands (e.g., chrome-devtools list_network_requests --include-console-errors), but this would lead to a bloated interface that is harder for agents to learn and maintain compared to a typed schema.

Status Quo (Single Tool Calls): Continuing to rely on granular tool calls keeps the protocol simple but keeps latency high and limits the "advanced mode" capabilities of the most capable agents.

Additional context

Relationship to the CLI Wrapper

The GraphQL tool is the "Observation" counterpart to the CLI's "Action".

The CLI (): Allows agents to write logic-heavy scripts to perform tasks, such as retrying a form submission if a username is taken.

The GraphQL Tool (query_devtools): Allows agents to gather the specific, multi-domain data needed to write those scripts or to debug them when they fail, all in one trip.

Together, they transform the agent from a "remote controller" clicking one button at a time into a "script writer" capable of high-level browser orchestration.

This is an RFC rather than an implementation task, so start by reviewing the current MCP interaction model and the CLI wrapper issue referenced in the proposal. Clarify the GraphQL schema, its relationship to existing console and network tools, and the scope of a first implementation before identifying code changes; done means the proposal has an agreed design and implementation boundary.