web-debug-mcp

by MarlonJD

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.7.0
Disambiguation4/5
Tools are largely distinct: session lifecycle, browser actions, reproduction recording/verification, and debugger control each occupy clear roles. The closest pairs are web_repro_record/web_fix_verify and web_browser_action/web_replay_seek, but their descriptions frame them as complementary rather than interchangeable.
Naming Consistency4/5
All tools share the web_ prefix and snake_case, giving the set a recognizable identity. The pattern is mostly <area>_<action> (session_start, breakpoint_set, fix_verify), with a couple of noun-like entries such as web_browser_action and web_session_status that are still predictable in context.
Tool Count5/5
13 tools is within the ideal range for a debugging server with multiple workflows (session management, reproduction, browser interaction, source inspection, live debugging). Every tool appears to add a distinct capability rather than duplicating another.
Completeness4/5
The surface covers the core debugging loop: start a session, act in the browser, record/verify reproductions, capture evidence, inspect Next.js, and control a paused debugger. Minor gaps exist, such as no explicit breakpoint removal or network/console inspection, but agents can work around them.
Average 3.7/5 across 13 of 13 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 92 commits in the last 12 weeks
- Last stable release on August 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=true, so the description's 'execute and store' is consistent with those. The description adds some context such as exact locator checks, named ordered checkpoints, viewport contracts, and adaptive-risk signals. However, it does not disclose specifics about side effects, what gets destroyed, or operational boundaries beyond what annotations state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler words, which is concise in length. However, it crams many concepts together—'bounded pre-fix reproduction', 'exact locator checks', 'viewport contracts', 'failure scope', 'adaptive-risk signals'—making it hard to parse at a glance. It could be split into clearer, more digestible sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 14 parameters, 6 required, heavy nesting, and no parameter descriptions in the schema. The description only gives a high-level gloss and does not explain what constitutes a valid reproduction, how checkpoints relate to actions, what failureSignature means, or what the output will look like. Even with an output schema present, the input complexity demands more guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it barely does. It references checkpoints, viewports, failure scope, and risk signals, which map to some parameters, but it does not explain required parameters like sessionId, name, url, actions, acceptanceChecks, or failureSignature. Given the massive nested schema, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: execute and store a reproduction of a web flow, with checkpoints, viewports, and failure scope. 'Pre-fix reproduction' and 'adaptive-risk signals' add distinguishing scope. However, it does not explicitly differentiate from sibling tools like web_replay_seek or web_fix_verify, and 'bounded pre-fix reproduction' is jargon-heavy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus siblings such as web_browser_action, web_replay_seek, or web_fix_verify. It does not mention prerequisites like needing an active session, nor does it explain when recording is appropriate versus replaying or verifying. The only hint is the word 'record' in the title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the description does not need to restate the safety profile. It adds that the tool compiles routes or resolves Server Actions through a local dev server, which implies execution/behavioral effects. However, it does not explain what destructive side effects may occur, such as running server code with external impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler. It front-loads the two concrete operations and scopes them to the selected local Next.js dev server. Every word contributes useful meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and annotations supply some context, but the description is thin for a tool with two distinct operation modes and a destructive/open-world profile. It does not mention the need for an active session or that resolving a Server Action can execute arbitrary server-side code, leaving the agent to infer important preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only partially compensates. It explains the two inspection modes—compiling a route or resolving a Server Action—but never clarifies that sessionId identifies the selected dev server/session or how path/actionId map to the mode. The schema provides const values and required fields, but the description adds little beyond a high-level paraphrase.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Compile one Next.js route or resolve one Server Action through the selected local Next development server.' This clearly identifies what the tool does and distinguishes it from sibling browser/debug tools by focusing on Next.js runtime operations. It does not explicitly name sibling alternatives, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of siblings like web_debug_evaluate or web_breakpoint_set. The phrase 'through the selected local Next development server' implies a session/context is required, but it does not state prerequisites, exclusions, or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotent=false, so the mutation risk is known. The description adds no extra behavioral context, such as what happens to the debugger session after resume, whether breakpoints persist, or side effects of stepping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence where every word adds meaning, front-loading the operation and the required target state. There is no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters and an output schema present, the tool is relatively simple and the description is adequate. However, it omits parameter roles and any guardrails about the session having to be active or currently paused, so an agent gets the gist but not full operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain sessionId or the action parameter beyond the enum values already present in the schema. The enum values are readable, but the description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific debugger verbs ('Resume', 'step') and identifies the resource ('paused local JavaScript target'), which makes its purpose clear and distinguishable from siblings like web_debug_evaluate or web_breakpoint_set. The title reinforces the same operation without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'paused local JavaScript target' implies the tool should be used only when a debugger session is paused, so the usage context is present. However, it does not explicitly state when not to use the tool or mention alternatives for related tasks such as expression evaluation during a pause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond the annotations: side effects are rejected by default and only allowed when explicitly enabled. This is valuable for a tool with destructiveHint=true and readOnlyHint=false, as it clarifies the default safety posture. It does not detail all consequences of enabling side effects, but the annotations already flag destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core action and target, and the second sentence provides a critical safety constraint. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for understanding the basic operation and the default side-effect policy, and an output schema exists to document return values. However, it omits details such as session prerequisites, how to handle rejected side effects, and any limitations of evaluated expressions. Given the complexity and potential destructiveness of JavaScript evaluation, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds meaning to the expression parameter by specifying that it runs in the local page runtime, and it explains the allowSideEffects behavior by stating side effects are rejected unless explicitly enabled. However, the sessionId parameter is not described at all, and the description does not clarify how an active session is used or required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool evaluates an expression in the local page runtime, and the title adds that it is a JavaScript expression. This is a specific verb and resource, though it does not explicitly distinguish itself from sibling tools beyond the unique action of evaluating an expression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as web_debug_control, web_next_inspect, or web_browser_action. The only usage-related hint is that side effects are rejected unless explicitly enabled, but there is no mention of appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the risk profile (readOnly=false, destructiveHint=true, idempotentHint=false), so the description is not required to restate safety. It adds useful behavioral detail—'adaptive bounded attempts' and the outcome classification—but does not disclose what may be destroyed or how attempts are bounded, which matters for a destructive-flagged tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, about 18 words, front-loads the action and outcome; no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters including a nested object and an enum, 0% parameter documentation in the schema, and a destructiveHint=true annotation, the description is too thin. The output schema likely covers return values, but parameter semantics, side effects, and when to choose this tool are all left to guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter description coverage is 0%, and the description compensates almost none of that gap. It never maps 'stored pre-fix reproduction' to sessionId/scenarioId, nor explains buildReference or requestedLevel (quick/standard/strict), leaving agents to infer semantics from names and enums alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Verify') with a specific resource ('stored pre-fix reproduction') and defines the outcome tri-state ('verified, failed, or inconclusive evidence'). This makes it distinct from sibling tools like web_repro_record or web_replay_seek, which are about capturing or replaying rather than confirming a fix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage has to be inferred: it is for verifying a previously recorded pre-fix reproduction, presumably after a fix has been applied. No explicit when-to-use/when-not-to-use guidance or named alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds useful behavioral context by stating that browser resources owned by the session are released, which goes beyond what annotations alone convey. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. 'Close the selected session' carries the main purpose, and 'release any browser resources owned by it' adds meaningful consequence without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter destructive tool with output schema and strong annotations, the description is mostly adequate. The main gap is that artifactPolicy is not described, so an agent cannot confidently know what 'delete' will destroy. Otherwise, safety and idempotency are covered by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain either parameter. sessionId is inferable from the tool name, but artifactPolicy's retain/delete values are ambiguous: it is not stated what is retained or deleted, when the default applies, or how it interacts with closing the session.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Close the selected session') and a resource ('session'), and adds a meaningful consequence: releasing browser resources. This distinguishes it from siblings like web_session_start and web_session_status, though 'selected' is slightly vague without referencing the sessionId parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb and title: call this when a session should be ended. However, the description provides no explicit when/when-not guidance, no mention of cleanup flow, and does not differentiate from related lifecycle tools such as web_debug_control or web_session_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: evidence is redacted, screenshots are opt-in and suppressed in specific security-sensitive cases, and WebMCP metadata is discover-only and untrusted. It does not mention all possible side effects, but the provided caveats are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, front-loaded with the primary action and default behavior, followed by important caveats. Every sentence provides valued information and there is no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema, and annotations, the description covers the key behavioral constraints an agent needs: default mode, mode options, redaction, screenshot opt-in, and security-sensitive suppression. The main missing element is explicit guidance on when to choose this tool over siblings, which is reflected in the usage dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate. It explains the conceptual view modes (summary default, full, selected, cursor-based changed surfaces) and connects screenshots to full/include, but it does not explicitly mention sessionId or the exact delta/include profile values. Some parameter meaning is added, but not enough to fully replace schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Capture redacted browser evidence') and distinguishes the default compact summary from full, selected, and cursor-based modes. It is clear about the tool's core purpose, but does not explicitly differentiate it from sibling tools like web_repro_record or web_debug_control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description explains internal profile options but does not state when web_issue_capture should be preferred over sibling tools or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds useful behavioral detail by stating it inspects 'the exact root' and does not start a process or select a child, giving the agent confidence about non-side-effecting behavior. It does not contradict the annotations and adds meaningful behavioral nuance beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and begins with the key action, 'Inspect'. It packs multiple clauses – root inspection, marker distinction, candidate reporting, and non-actions – efficiently. It could be clearer if split, but it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is present and annotations cover side-effecting safety, the description provides enough context for a low-complexity read-only tool: it reports candidates without side effects. It lacks explicit when-to-use guidance, but the title, siblings, and non-action phrasing fill most gaps. The description is close to complete for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for projectRoot, so the description must compensate. The phrase 'Inspect the exact root' connects loosely to projectRoot but does not explain path format, whether it is absolute or relative, or the significance of the default '/app'. For a single self-named parameter this is minimally adequate but lacks real semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names specific actions – 'inspect', 'distinguish', 'report' – and a clear resource, the project root. It also distinguishes itself from sibling tools by stating it works 'without starting a process or selecting a child', which separates it from session-start and child-inspection tools. The language is somewhat technical ('bounded workspace candidates'), but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a pre-flight or eligibility-inspection step and explicitly says it does not start a process or select a child. However, it never directly states when to use this tool versus siblings such as web_session_start or web_next_inspect, so the agent must infer the intended usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description need not repeat those. It adds the useful context of operating 'through the local Chromium debugger.' Yet it does not mention that setting a breakpoint affects subsequent execution or that a session must already be running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence of 14 words carries the core purpose, key parameters, and mechanism with zero filler. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small mutation tool with only 4 parameters and a provided output schema, the description is nearly sufficient. It lacks an explicit requirement for an active debug session, but the sessionId parameter and sibling tool set make that inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden of explaining parameters. It clarifies sourceUrl and that line is one-based (matching the schema min=1), but gives no guidance on sessionId or the optional column meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Set'), a concrete resource ('breakpoint by source URL and one-based line number'), and the mechanism ('local Chromium debugger'). This clearly distinguishes it from sibling tools like web_debug_evaluate or web_debug_control, which perform different debug actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: an agent can infer this is for pausing exection at a specific line in a supported debug session. However, it does not explicitly state when to choose this tool over alternatives, nor any preconditions like requiring an active web session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior (destructiveHint=true). The description adds the key conditional context: default is returning a frame, while restore=true mutates live state. It also discloses that frames are redacted and actions are 'safely restorable', giving useful behavioral nuance beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with the primary behavior front-loaded and the optional restore behavior attached to the relevant parameter. There is no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return value does not need extensive explanation. The description covers the main risk (live mutation on restore) and the redacted nature of frames. It does not explain session/frame index validity explicitly, but the schema already encodes constraints, so the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the restore parameter clearly, but sessionId and frameIndex are left entirely to their names and schema constraints. This is only partial parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Return one retained, redacted replay frame' and explains the optional restore behavior that replays actions and mutates live state. This clearly distinguishes it from siblings like web_repro_record or web_browser_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to seek/return a replay frame, and set restore=true when replaying actions into the browser. However, it does not explicitly list alternative tools or state when not to use it, so some inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive/open-world behavior; the description adds critical non-obvious policy: WebMCP calls are bounded, opaque, non-replayable, and never retried. It also warns that WebMCP execution requires explicit authorization. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver a full action inventory plus WebMCP safety constraints. The information is front-loaded and every clause adds value; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large schema, the presence of an output schema, and annotations, the description covers the most important non-obvious behaviors. It could additionally mention that sessionId must come from an active web_session_start flow, but the schema URI/format and sibling tool names largely fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has rich oneOf/const structure but 0% textual description coverage. The description adds useful hints like 'exact locators' and 'explicitly authorized' WebMCP, but it does not explain sessionId, locator-kind selection, or wait/timeout semantics. It partially compensates for the schema gap without covering all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete verb set ('Navigate, click, fill, press, select, check, hover, scroll, wait, or reload') and identifies the resource as a browser session/page. It also distinguishes this tool from sibling debug/session-management tools by scoping it to DOM actions and the special WebMCP page-tool case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear: this is the tool for bounded browser interactions, and the description adds the important constraint that WebMCP/page-tool calls must be explicitly authorized. It does not explicitly name sibling alternatives or say when to prefer web_debug_* tools, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safe-read behavior is covered. The description adds the two-mode behavior (list all vs read one) and the distinct content of the summary, which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and front-loads the core behavior. The specialized phrasing 'separate project eligibility and negotiated live runtime capabilities' is dense but not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and an output schema, the description is complete: it states the two calling modes and what the summary contains. The output schema handles return-value details, and annotations handle safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by tying the optional sessionId to the two modes: omission lists active sessions, providing one reads a single summary. It doesn't spell out 'optional' but the grammatical structure conveys this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('List active sessions or read one summary') and distinguishes two invocation modes, making it easy to tell apart from sibling tools like web_session_start, web_session_close, and web_debug_control. The phrase about project eligibility and negotiated runtime capabilities further specifies what kind of summary is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that omitting sessionId lists active sessions and providing it reads one summary, but it never explicitly says when to prefer this tool over siblings or states exclusions. An agent can infer the read-only inspection use case from annotations, but the description itself gives no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as non-read-only, non-idempotent, and destructive, and the description adds useful behavioral nuance: optional guarded loopback TLS, a disposable auth fixture, targetId pinning for attached Chromium, and the stricter Safari/CSS-only path. These details shape agent expectations without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no filler and starts with the action. Every clause adds a distinct constraint or mode, so it remains tightly packed despite the technical jargon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no schema-level descriptions, the description covers the core choices, browser differences, and attach behavior, while the output schema covers return details. It leaves some parameters (e.g., allowRemote, viewport) mostly to inference, but the remaining information is largely recoverable from names, defaults, and enums. This is adequate but not exhaustively complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the prose carries the semantic load. It meaningfully explains key parameters: CDP/WebDriver/executable settings, targetId for precise attachment, tls via guarded loopback, and authFixture/projectRoot through the disposable fixture. A few parameters like headless, viewport, and allowRemote rely on name/type inference, but the most decision-critical ones are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action ('Start or attach'), a specific resource ('local Chromium or Safari page'), and the invocation route ('explicit URL and CDP, WebDriver, or executable settings'). This goes beyond the title and clearly distinguishes the tool from session-status, capture, and close siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening phrase makes the intended context clear: use this when a browser debugging session needs to be started or attached to a specific page. It does not explicitly name sibling tools or provide when-not-to-use guidance, but the transport-mode options and targetId attach behavior give enough contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![web-debug-mcp MCP server](https://glama.ai/mcp/servers/MarlonJD/web-debug-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MarlonJD/web-debug-mcp)

Score Badge

Copy to your README.md:

[![web-debug-mcp MCP server](https://glama.ai/mcp/servers/MarlonJD/web-debug-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MarlonJD/web-debug-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MarlonJD/web-debug-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server