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.5.0-next.0
Disambiguation5/5
Each tool targets a distinct phase of web debugging: session lifecycle, browser interaction, evidence capture, debugging control, and repro verification. Even the closest pairs, like issue_capture and repro_record, are clearly separated by purpose: one bundles evidence, the other records and verifies a reproduction.
Naming Consistency4/5
All tools share the web_ prefix and snake_case convention, using a web_<area>_<operation> pattern that is easy to predict. A few names use noun-like suffixes (status, action, capture, control, record) rather than explicit verbs, which is a minor inconsistency but not confusing.
Tool Count5/5
Thirteen tools is well within the ideal range for a specialized debugging server. Each tool contributes a meaningful capability, and the count feels balanced between session management, browser automation, debugging, and reproduction workflows.
Completeness4/5
The tool surface covers the main debugging workflow well: detect, start, act, capture, inspect, debug, replay, and verify. Minor gaps exist such as no explicit breakpoint listing/removal or standalone console/network inspection, but the bundled issue capture mitigates these gaps.
Average 3.5/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
- 80 commits in the last 12 weeks
- Last stable release on August 29, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true. The description adds the operational context of compiling or resolving through a dev server, but it does not disclose what side effects or destructive behavior may occur, such as triggering builds, mutating server state, or overwriting build artifacts. It neither contradicts nor substantively enriches 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 a single sentence with no filler. Every phrase earns its place: the verb, the resource, the two operation modes, and the server context are all present. It is efficiently front-loaded and easy to scan.
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?
Despite an output schema being present, the tool has 0% schema description coverage and destructive annotations. The description is too thin to give an agent enough context about side effects, parameter meaning, or mode selection. Additional detail about what 'routeSpecifier' is, what 'compile' and 'resolve' do operationally, and what destructive effects to expect would be needed.
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 for the lack of parameter documentation. It names the two inspection modes (compileRoute and resolveServerAction) but does not explain sessionId, path, routeSpecifier, actionId, or the relationship between the 'selected dev server' and sessionId. This leaves significant semantic gaps for an agent trying to invoke the tool correctly.
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 specific verbs ('Compile', 'resolve') and names the resource ('Next.js route', 'Server Action', 'local Next development server'), making the tool's function clear. It does not explicitly contrast with siblings like web_debug_evaluate or web_breakpoint_set, but the described operations are distinctive enough to identify what the tool does.
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 implies the tool acts on a selected local Next development server, hinting at a session context, but provides no explicit guidance on when to use it versus alternatives like web_debug_evaluate, web_repro_record, or web_fix_verify. It also does not explain when to choose compileRoute versus resolveServerAction beyond their names.
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?
The description adds context beyond the annotations: 'execute' and 'store' indicate the tool performs real browser actions and persists a recording, which is consistent with destructiveHint=true and readOnlyHint=false; there is no annotation contradiction. However, it fails to disclose what makes the operation destructive (real side effects on the target application), that it depends on a live session, or what 'bounded' means operationally in terms of execution limits.
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 compact sentence with no filler, earning conciseness credit. But its structure is flawed: the list 'exact locator checks, named ordered checkpoints, optional desktop/mobile viewport contracts and failure scope' has ambiguous grouping - it is unclear whether 'optional' scopes only viewport contracts or also failure scope - making the sentence harder to parse than necessary.
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?
For a tool with deeply nested schemas, 10 action kinds, 5 locator kinds, and 0% parameter documentation, a 28-word sentence is not nearly complete. It omits prerequisites (live sessionId), the action vocabulary, the relationship between checkpoints.offset and the actions array, and the required minimums on failureSignature and acceptanceChecks. The output schema covers return values, but input construction guidance is under-specified.
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 carries the full burden but only telegraphs concepts: 'viewport contracts' maps loosely to viewports/failureViewports, 'failure scope' to failureSignature, 'adaptive-risk signals' to risks, and 'named ordered checkpoints' to checkpoints. It does not explain the critical distinctions among acceptanceChecks, failureSignature, regressionChecks, and checkpoints, nor how sessionId, requestedLevel, buildReference, or serverStateReset should be populated. For 14 parameters with 6 required, this is materially insufficient.
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+resource ('Execute and store a bounded pre-fix reproduction') and enumerates distinguishing features (exact locator checks, named ordered checkpoints, viewport contracts, failure scope, adaptive-risk signals) that separate it from siblings like web_replay_seek or web_browser_action. However, the dense jargon ('pre-fix reproduction', 'adaptive-risk signals', 'viewport contracts') requires significant inference, and no sibling is named explicitly, so it stops short of full clarity.
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 when-to-use guidance is provided. The description never mentions alternatives, prerequisites (e.g., that an active session from web_session_start is required, given the required sessionId parameter), or exclusions. Only the phrase 'pre-fix reproduction' hints at a lifecycle context, but it is not explicit enough to help an agent choose between this tool and web_browser_action, web_issue_capture, or web_replay_seek.
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 safety and side-effect hints (destructive=true, readOnly=false). The description adds useful context about the bounded same-origin scope, exact locators, and live probe waits. However, it does not disclose side effects or failure modes beyond what the annotations imply, so it earns a middle score rather than lower.
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?
A single dense sentence enumerates the full action set without wasted words. The core action list is front-loaded, though the phrasing 'fresh live probe waits' is slightly opaque and could have been clearer.
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?
This is a highly complex tool with ten action variants, five locator types, and a wait mechanism, yet the description only lists actions and mentions same-origin scope. It omits guidance on how action kinds interact with locators, when waits are needed, timeout defaults, or what outputs are produced. An output schema exists, but the description still under-specifies for an agent deciding correct invocation.
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. While it lists the action kinds, it adds no meaning about the sessionId parameter, locator variants, value semantics, wait properties, or timeout behavior. The schema is self-explanatory for structure, but the description contributes almost nothing to parameter understanding.
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 enumerates a specific list of actions (navigate, click, fill, press, etc.) and names the resource scope ('selected same-origin target'), making the tool's function clear. It doesn't explicitly distinguish itself from sibling tools, but the action list and bounded-scope phrasing set it apart from session lifecycle and inspection siblings.
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 about when to use this tool versus the sibling tools such as web_next_inspect, web_issue_capture, or web_session_start. It does not state any exclusions, prerequisites, or alternative conditions.
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?
The description adds behavioral context beyond the annotations by mentioning 'adaptive bounded attempts' and the classification of evidence into verified/failed/inconclusive. However, despite destructiveHint=true, it does not disclose what state changes or potential destruction might occur during verification.
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 concise sentence with no filler or redundancy. It front-loads the core action and resource, then adds useful behavioral and outcome details, though the phrase 'stored pre-fix reproduction' is somewhat dense.
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?
Given 4 parameters, a nested object, an enum, destructive annotations, and 12 siblings, the description is too thin to fully guide correct invocation. The output schema covers return structure, but parameter semantics and usage context are critically missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description compensates by naming no parameters or their meanings. Required parameters like sessionId and scenarioId, plus optional ones like buildReference and requestedLevel, remain unexplained; even 'adaptive bounded attempts' is not tied to requestedLevel.
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 ('Verify'), a clear resource ('a stored pre-fix reproduction'), and names the three possible outcomes: verified, failed, or inconclusive evidence. This clearly communicates the core purpose, though it does not explicitly contrast it with sibling tools.
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 the tool is meant to be used when a pre-fix reproduction is stored and a fix needs verification, but it provides no explicit when-to-use guidance or exclusions. It does not mention alternatives or conditions that would route the agent to a sibling tool like web_replay_seek or web_debug_control.
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 declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the mutation nature is covered. The description adds useful context by specifying 'local' and 'paused', but it doesn't explain the resulting debugger state change (e.g., execution continues, stepping advances one statement). There is no contradiction with 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 a single, front-loaded sentence with no filler, repetition, or unnecessary detail. Every word contributes to the tool's core purpose.
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 cover return values and safety profile, so the description doesn't need to repeat those. However, it omits important invocation context such as the requirement that sessionId refer to an existing paused local session and what happens to that session after each action. It is minimally viable but relies heavily on parameter names and sibling tool 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?
Schema coverage is 0%, so the description carries the burden for parameter meaning. It only weakly compensates: 'resume or step' mirrors the action enum, but it never explains that sessionId identifies the paused target session, nor does it clarify the difference between stepOver, stepInto, and stepOut. The agent is left to infer semantic distinctions from enum names alone.
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: 'Resume or step a paused local JavaScript target.' It clearly communicates what the tool does and its scope. It doesn't explicitly name sibling tools for differentiation, but the wording distinguishes it from evaluation, breakpoint-setting, and browser action tools.
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 the usage context: the target must already be paused, and the operation resumes or steps it. However, it provides no explicit when-not-to-use guidance or alternatives, such as using web_debug_evaluate to inspect state or web_breakpoint_set to set breakpoints first.
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 convey that the tool is non-read-only, non-idempotent, and non-destructive, lowering the burden on the description. The description adds that the breakpoint is set 'through the local Chromium debugger,' suggesting session-scoped behavior, but does not disclose side effects such as whether breakpoints persist, whether setting the same breakpoint twice replaces or duplicates it, or what happens when a breakpoint is hit. This is adequate for a simple tool but adds little 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 a single, front-loaded sentence that opens with the action and adds only necessary modifiers: source URL, one-based line number, and local Chromium debugger. There is no filler, and every word earns its place.
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 straightforward breakpoint-setting action, the core operation is covered, and the presence of an output schema means return-value details need not be in the description. However, the description leaves the required sessionId unexplained and offers no routing guidance among the debugging-related sibling tools. The tool is callable but assumes the agent already understands session management and sibling distinctions.
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 carry the semantic burden for the four parameters. It explains 'sourceUrl' and 'line' by mentioning 'source URL and one-based line number,' but it entirely omits the required 'sessionId' and the optional 'column.' With a required parameter unexplained and only half the parameters semantically covered, the description only partially compensates for the schema's lack of descriptions.
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 specific verb ('Set') and resource ('a breakpoint'), and further specifies the addressing mechanism ('source URL and one-based line number') and environment ('local Chromium debugger'). This makes the tool's purpose unmistakable and clearly distinct from sibling tools like web_debug_evaluate, web_debug_control, and web_replay_seek, none of which set breakpoints.
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 usage guidance by defining the action, but it does not explicitly state when to use this tool versus alternatives like web_debug_control, web_next_inspect, or web_debug_evaluate. There is no when-not-to-use guidance, naming of alternatives, or prerequisite conditions beyond the implicit 'local Chromium debugger' context.
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 annotation set already flags this as non-read-only and potentially destructive. The description adds a valuable behavioral guardrail: side effects are rejected unless explicitly enabled. This clarifies the actual execution policy beyond what the raw hints communicate.
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 focused sentence that front-loads the core purpose and immediately states the key 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the annotations already convey the safety profile, the description covers the essential tool behavior well. It omits the need for an active session or the relationship to sessionId, which could be clearer, but the local page runtime wording sufficiently implies the session 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?
Schema description coverage is 0%, so the description carries the burden of explaining parameter meaning. It only indirectly addresses allowSideEffects and mentions 'expression' in the title, but it does not explain sessionId, the expression evaluation context, or how parameters interact. The schema field names are self-explanatory, but the description adds little parameter-level value.
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 identifies the operation: evaluating an expression in the local page runtime. This distinguishes it from broader browser-action or inspection tools, though it does not explicitly name any sibling tool it differs from.
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 the tool is for running JavaScript directly in a page session, but it does not state when to prefer it over alternatives such as web_browser_action, web_next_inspect, or web_issue_capture. No explicit exclusions or conditional routing guidance 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?
The description adds meaningful behavioral detail beyond the annotations: evidence is redacted, the bundle aggregates many sources, screenshots are optional, and auth-seeded sessions suppress screenshots. This helps the agent understand side effects and constraints that annotations alone do not convey.
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 dense, efficient sentences with no filler. The list of captured evidence is front-loaded, and the second sentence adds the most important caveat 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?
The description covers the bundle contents and a key behavioral constraint, and there is an output schema to describe the return value. However, for a complex multi-source capture tool, it lacks usage context, session provenance guidance, and any mention of when this tool is the right choice among siblings.
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 does not explain the required 'sessionId' at all. It only implies screenshot behavior through 'optional screenshot' and 'auth-seeded sessions suppress screenshots,' leaving the core parameter semantically underdetermined.
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 ('Combine') and resource ('one redacted evidence bundle') and enumerates the exact evidence categories included. It clearly distinguishes this tool as a comprehensive evidence-capture action from siblings like web_debug_evaluate or web_browser_action by scope and output.
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 explains what the tool does but gives no explicit guidance on when to use it versus alternatives such as web_repro_record or web_next_inspect. There is no mention of prerequisites, such as needing an active session, nor any excluded scenarios.
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 establish destructive, non-read-only, idempotent, and closed-world behavior. The description adds a useful behavioral trait by stating that browser resources owned by the session will be released. It does not explain the artifactPolicy delete/retain consequence, but the destructive hint already signals the risk.
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 sentence with the action front-loaded and no wasted words. The resource-release consequence is folded in economically.
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 close action, the core behavior is clear, and the output schema plus annotations cover returns and safety. However, the description does not clarify artifactPolicy or what 'selected session' means relative to sessionId, so it is only adequate, not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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, and it does not. It never names sessionId or artifactPolicy, and 'selected session' only loosely maps to the required sessionId. The meaning of artifactPolicy's retain/delete values is left entirely to the agent.
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 action ('Close'), resource ('session'), and consequence ('release any browser resources owned by it'), making the purpose unmistakable. It is clearly distinct from sibling tools like web_session_start and web_session_status.
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 this is the tool to use when a debug session should be closed, but it offers no explicit when/when-not guidance, alternatives, prerequisites, or advice about artifactPolicy. Usage context is left to inference.
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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context that it inspects known markers and does not start a process, but does not elaborate on edge cases or return behavior beyond what the output schema provides.
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 sentence that front-loads the core action and immediately adds the key constraint 'without starting a process'. There is no filler and every phrase earns its place.
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 simple static inspection tool with one optional parameter, read-only annotations, and an output schema, the description is largely complete. The only notable omission is parameter documentation, which is mitigated by the self-explanatory name and default value.
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 mention projectRoot at all. The parameter name and default /app give some self-evident meaning, but the tool description fails to clarify valid values or how the root relates to 'known project markers', making this a real gap.
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 action and resource: inspects known project markers and reports supported browser/framework capabilities. The 'without starting a process' qualifier clearly differentiates it from process-launching siblings.
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 the tool is for static capability detection and explicitly rules out starting a process. However, it does not name alternative tools or specify when to prefer this over web_session_start or web_next_inspect, so usage guidance remains somewhat implicit.
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 behavioral context beyond the annotations: frames are 'retained' and 'redacted', and setting restore=true 'replays its safely restorable actions into the browser and mutate live state'. This directly aligns with destructiveHint=true and clarifies the safety profile of the optional restore behavior.
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 entire description is one sentence that front-loads the primary behavior and then adds the conditional restore behavior. There is no wasted wording, and the most important safety-relevant conditional is stated clearly.
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 that an output schema exists and annotations already indicate a destructive, non-idempotent operation, the description is largely complete. It covers the main retrieval behavior, the restore option, and its mutation side effect. Minor gaps remain around when not to use the tool and what 'safely restorable actions' entail.
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 must compensate for parameter documentation. It clearly explains the 'restore' parameter's effect, but sessionId and frameIndex are only understood through their names and schema constraints. This is adequate but not complete compensation for the missing schema descriptions.
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 a specific action ('Return one retained, redacted replay frame') on a specific resource (captured web replay frames). It does not explicitly distinguish itself from sibling tools, but 'replay frame' is unique enough among the sibling names to convey the core purpose.
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 explains the conditional behavior of 'restore=true' and implies that the tool is for retrieving replay frames. However, it gives no explicit guidance on when to choose this tool over alternatives like web_next_inspect or web_breakpoint_set, nor does it state any exclusions.
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/non-read-only behavior, and the description adds useful behavioral context: one guarded HTTPS loopback origin, a project-contained disposable auth fixture, targetId pinning, and Safari's stricter CSS-only constraint. It does not contradict annotations, though it does not spell out side effects of starting a session.
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?
Three dense sentences front-load the core operation and then layer constraints and optional modes without filler. Every clause adds information about transport, safety, or browser behavior.
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 complex 12-parameter tool, the description conveys the main start/attach paths and key constraints, and an output schema exists so return values need not be described. It still leaves gaps around selecting among transport modes, headless/viewport/allowRemote, and how this tool relates to sibling web debug tools.
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 carries the burden. It gives real meaning to URL, browser choice, CDP/WebDriver/executable transports, tls loopback, authFixture, and targetId. However, headless, viewport, allowRemote, projectRoot, and the precise endpoint/executable fields are left implicit, which is a notable gap for a 12-parameter tool.
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?
Description uses a specific verb ('Start or attach'), names the resource ('local Chromium or Safari page'), and specifies the connection mechanisms (URL plus CDP, WebDriver, or executable settings). This distinguishes it from sibling tools like web_session_status or web_session_close, whose purpose is monitoring or teardown.
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?
It conveys when to use the tool: to begin or attach to an explicitly selected local page for debugging, with browser-specific caveats ('Safari remains strict and CSS-only'). It does not explicitly name sibling alternatives or state when not to use them, so it stops at clear context without 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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to re-establish safety. It adds useful context about 'active' sessions and 'summary' output, but does not disclose behavior around missing sessions, pagination, or session lifecycle. That is acceptable but not especially rich.
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 sentence covers both modes with no filler or repetition of predictable details. All words add 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 one optional parameter, a read-only annotation profile, and an output schema present, this description is nearly complete for a status/list tool. It covers both invocation modes and the active-session scope; only minor details such as sentinel UUID semantics or behavior for unknown session IDs are left to the schema.
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 description bears the responsibility of explaining the parameter semantics. It does convey the crucial rule: the optional sessionId switches between listing all active sessions and reading a single session summary. The schema itself provides format and pattern validation, so the description adds meaning beyond the field name.
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 the exact resource ('web debug sessions') and the two supported operations: listing active sessions or reading one session summary. This makes it easily distinguishable from sibling tools like web_session_start, web_session_close, and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly telegraphs the two invocation modes: omit sessionId to list active sessions, provide sessionId to read one summary. It does not explicitly name alternatives or when-not conditions, but the usage context is unambiguous for a read-only status tool.
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