Feature request: page-level WebSocket frame debugging tools

Problem

chrome-devtools-mcp can connect to Chrome over a WebSocket endpoint today, and the existing network tools can expose request/response data for regular HTTP traffic. But for applications that rely on WebSockets, the current tooling appears to stop at the handshake request. It does not expose the actual message/frame stream after the connection is established.

That leaves a gap for debugging apps and extensions whose state, auth, or synchronization logic depends on live WebSocket traffic.

Use cases

• Inspecting application state synchronization that happens over WebSocket messages
• Debugging authentication/session flows that upgrade to WebSocket after page load
• Understanding extension-to-backend communication when the extension relies on WebSockets
• Investigating whether the browser sent or received a specific message payload during a workflow

Current behavior

From local inspection, the existing network model appears request-centric:

• list_network_requests and get_network_request operate on a request/response abstraction
• the WebSocket handshake can be represented as a request
• the subsequent WebSocket frames/messages are not exposed as part of the MCP interface

Proposed direction

I think this is better modeled as dedicated tools rather than extending get_network_request with a large set of WebSocket-only options.

Possible v1 tool shape:

• list_websocket_connections
• get_websocket_messages

Possible connection summary fields:

• stable MCP id
• URL
• open/closed state
• created time
• last activity time
• sent message count
• received message count
• handshake request headers
• handshake response headers

Possible message fields:

• sequence number
• timestamp
• direction (sent or received)
• opcode
• payload preview
• payload length

Why dedicated tools seem cleaner

WebSocket frames are not just another request body. They are a time-ordered event stream with different UX and token constraints:

• high-volume streams need pagination and truncation
• messages need sent/received filtering
• payload previews should be bounded
• connection lifecycle matters independently of a single HTTP request

CDP support

The Chrome DevTools Protocol Network domain already appears to expose the raw events needed for this, including events such as:

• WebSocket creation
• handshake request/response
• frame sent
• frame received
• frame error
• close

So this looks like a collection and API-design gap rather than a protocol limitation.

Open questions

• Would maintainers prefer dedicated WebSocket tools, or extending the existing network tools?
• What pagination/truncation limits would be acceptable for a v1?
• Should binary frames be omitted in v1, or exposed only as metadata + bounded preview?
• Should the feature be page-scoped only, or also include extension/service-worker traffic when extension support is enabled?

If this direction sounds reasonable, I can follow up with a scoped PR after feedback on the tool shape.

Start by reading the existing list_network_requests and get_network_request implementations, then review the Chrome DevTools Protocol Network events listed in the issue. Clarify the v1 tool shape, pagination and truncation limits, binary-frame handling, and page versus extension scope with maintainers. Done means an agreed design and implementation plan for exposing WebSocket connections and messages.