web-debug-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WEB_DEBUG_CHROME_EXECUTABLE_PATH | No | Path to a Chrome/Chromium executable used for live browser sessions. Provide an explicit executable path when launching Chromium, e.g. /Applications/Google Chrome.app/Contents/MacOS/Google Chrome. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| web_project_detectA | Inspect the exact root, distinguish confirmed application markers from weak dependency candidates, and report bounded workspace candidates without starting a process or selecting a child. |
| web_session_startA | Start or attach to an explicitly selected local Chromium or Safari page using an explicit URL and CDP, native Safari MCP, or executable settings. Chromium can opt into one guarded HTTPS loopback origin and a project-contained disposable auth fixture; attached Chromium can supply targetId to pin the exact page. Safari remains strict and CSS-only. |
| web_session_statusA | List active sessions or read one summary with separate project eligibility and negotiated live runtime capabilities. |
| web_browser_actionB | Perform an exact-locator browser action or one authorized direct WebMCP page tool; direct WebMCP calls remain opaque, non-replayable and never retried. Optional Chromium diagnostics collect request initiators and explicitly selected precise coverage; coverage changes JIT/timing and is excluded from fix verification. |
| web_issue_captureA | Capture redacted browser evidence with a compact summary by default, or explicitly request full, selected, or cursor-based changed surfaces. WebMCP metadata is discover-only and untrusted; screenshots are opt-in through full/include and remain suppressed for private input, auth-seeded sessions, or any session after a direct WebMCP attempt. |
| web_next_inspectA | Compile one Next.js route or resolve one Server Action through the selected local Next development server. |
| web_replay_seekA | Return one retained, redacted replay frame; set restore=true to replay its safely restorable actions into the browser and mutate live state. |
| web_breakpoint_setA | Set a breakpoint using one-based source coordinates. Select coordinateSpace=original and an exact source URL/scriptId from the sources capture to translate a source map; ambiguous or unavailable mappings fail explicitly. |
| web_debug_controlC | Resume or step a paused local JavaScript target. |
| web_debug_evaluateA | Evaluate an expression in the local page runtime. Side effects are rejected unless explicitly enabled. |
| web_repro_recordC | Execute and store a bounded pre-fix reproduction with exact locator checks, named ordered checkpoints, optional desktop/mobile viewport contracts and failure scope, and adaptive-risk signals. |
| web_fix_verifyC | Verify a stored pre-fix reproduction with adaptive bounded attempts and return verified, failed, or inconclusive evidence. |
| web_session_closeC | Close the selected session and release any browser resources owned by it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools target clearly distinct phases (session lifecycle, action, evidence capture, replay, repro record, fix verify). However, web_debug_control, web_breakpoint_set, and web_replay_seek all touch pause/step/replay state, and web_issue_capture vs web_replay_seek both deal with retained evidence, creating mild boundary ambiguity.
Every tool follows a strict `web_` prefix plus a noun_verb or noun_action snake_case pattern (web_session_start, web_breakpoint_set, web_fix_verify), with no camelCase or style mixing. The convention is highly predictable across all 13 tools.
13 tools is well within the ideal 3-15 range and each tool maps to a distinct step of a debugging/reproduction workflow. No tool appears redundant or filler.
The surface covers session lifecycle, browser actions, breakpoints, evaluation, evidence capture, replay, reproduction recording, fix verification, and framework-specific inspection. A notable gap is the absence of any breakpoint removal/listing or session cleanup beyond close, but core workflows are otherwise well covered.