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, WebDriver, 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_actionA | Navigate, click, fill, press, select, check, hover, scroll, wait, or reload with exact locators, or execute one explicitly authorized direct WebMCP page tool. WebMCP calls are bounded, opaque, non-replayable, and never retried. |
| 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 by source URL and one-based line number through the local Chromium debugger. |
| web_debug_controlB | 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_recordB | 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_closeA | 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
Each tool targets a distinct step in the web debugging workflow: sessions, browser actions, breakpoints, evaluate, replay, reproduction, and verification. Even related tools like repro_record and fix_verify are clearly separated by their record/verify roles, and debug_control vs browser_action are unambiguous.
All names follow a uniform 'web_<domain>_<action>' snake_case pattern, with the action being a verb (start, close, record, verify). The only mild exception is web_session_status and web_browser_action, but both still fit the scheme as noun-as-verb conventions, so the set feels highly predictable.
At 13 tools, the set is appropriately scoped for a comprehensive web debugging suite. Each tool fills a distinct role and there is no redundant overlap or fluff that would justify trimming or expanding.
The tool surface covers the core debugging lifecycle: record, capture, start/stop sessions, interact, set breakpoints, jump, edit live state, and verify. Minor omissions like remove breakpoint, pause on exceptions, or network inspection leave small gaps, but the main workstreams (reproduce, debug, fix, verify) are all represented.