JS Reverse MCP

Server Quality Checklist

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

Latest release: v4.0.1
Disambiguation3/5
Tools are organized around specific debugging actions, but many overlap in purpose (e.g., multiple breakpoint and pause/resume tools, multiple request inspection tools). While descriptions are precise, an agent could easily confuse which tool to use for a given step, especially with 24 tools.
Naming Consistency4/5
Most tools follow a verb_noun pattern in snake_case (e.g., clear_network_requests, click_element). A few deviate slightly (e.g., 'break_on_xhr', 'get_paused_info'), but overall the naming is predictable and readable.
Tool Count3/5
24 tools is on the higher side for a focused reverse engineering server. The set is comprehensive but some tools could be merged (e.g., clear_network_requests and clear_site_data are distinct but very similar). Still, each tool has a clear role, so the count is borderline but acceptable.
Completeness4/5
The tool surface covers all major aspects of JavaScript reverse engineering: network interception, source inspection, breakpoint management, page control, and evaluation. Minor gaps exist (e.g., no direct DOM query tool), but the set is largely complete for its purpose.
Average 4.8/5 across 24 of 24 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 18 of 18 community issues answered or closed in the last 6 months
- 59 commits in the last 12 weeks
- Last stable release on July 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only and non-destructive. Description adds key behavioral details: non-pausing, reads retained evidence, initiator capture is lazy and not retroactive. No contradiction.
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?
Single paragraph that is front-loaded with purpose and then flows into usage and alternatives. Every sentence is informative, though slightly dense; could be restructured but remains efficient.
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?
Given the tool's complexity and the presence of annotations and output schema, the description covers all contextual aspects: limitations, reproduction strategies, and references to sibling tools. 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 covers requestId fully with description. Tool description adds operational context: pass reqid from list_network_requests, notes on staleness and reproducibility. Provides value beyond schema.
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?
Clearly states it retrieves the JavaScript initiator for a retained HTTP request, with a specific verb and resource. Distinguishes from siblings by mentioning alternatives like get_script_source, break_on_xhr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (pass reqid from list_network_requests), when-not-to-use (older request may have no stack), and alternatives (reproduce, set break_on_xhr, use get_paused_info, evaluate_script).
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 tool as read-only and non-destructive. The description adds valuable context: scriptId expires on reload/navigation/target change, and URL is the preferred selector for get/save_script_source. This goes beyond annotations.
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?
Description is informative but not overly verbose. It front-loads the purpose, then usage notes, then parameter clarifications, and ends with result structure. Could be slightly more concise but overall well-organized.
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?
Given 3 parameters, annotations, and an output schema (not shown but present), the description covers necessary context: result items include scoped scriptId and URL, with expiration behavior. No gaps for effective use.
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 covers all parameters with descriptions. Description adds clarity: filter is case-insensitive URL substring and does not search source text, with a reference to search_in_sources for code queries. This extra guidance justifies a 4 instead of baseline 3.
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 clearly states it discovers JavaScript loaded in the selected debugger context, specifying script types (external, inline, eval) and context scope (main frame or selected frame). It distinguishes from sibling tool search_in_sources by indicating when to use that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells users to use select_frame first for iframe-specific work, and to use search_in_sources when they know a function name, endpoint, or code literal. Also clarifies that filter does not search source text, so users know its limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds that the breakpoint is for future requests only, does not inspect past traffic, and requires subsequent steps. Also explains how the URL pattern ties to list_breakpoints and remove_breakpoint.
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?
Description is a single paragraph of about 100 words, front-loaded with purpose, then usage sequence, then relation to other tools. Every sentence contributes. Could be slightly more compact, but efficient overall.
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 existence of an output schema, return values are not needed in description. Covers what, when, how, and parameter details. Could explicitly mention that the breakpoint causes a pause on request, but context is fairly 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 has one parameter 'url' with description. Tool description adds context: case-sensitive, should be a narrow endpoint path from list_network_requests, retain exact string for removal. This goes beyond the schema description. With 100% schema coverage, baseline is 3, but added value justifies 4.
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 clearly states the tool's purpose: setting a URL-substring breakpoint for future XHR/Fetch to inspect runtime arguments, variables, or payloads. It distinguishes from get_request_initiator, which handles already captured requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use when need to inspect request details at runtime, avoid for already captured requests (use get_request_initiator instead). Specifies the workflow: set before reproducing action, then call get_paused_info/evaluate_script, then step/resume. Also notes it does not inspect past traffic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true and destructiveHint=false. Description adds that URL-backed definitions may restore after navigation but IDs may change in rebuilt sessions, and that it returns breakpointIds and XHR patterns. No contradiction.
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?
Description is concise with three sentences, front-loaded with main purpose. No unnecessary words.
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?
Has output schema, so return details are covered. Description provides enough behavioral context for breakpoint inspection and restoration, given tool complexity.
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 coverage is 100%, so baseline 3. Description does not add extra meaning beyond schema for pageIdx and pageSize 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 clearly states the tool inspects code and XHR/Fetch breakpoints managed by the session. It uses specific verbs and resource, distinguishing itself from siblings like get_paused_info and remove_breakpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool: before reproducing an action or cleaning up debugger state. Also directs to use get_paused_info for active call stack, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false), but the description extensively discloses behavioral traits: it waits for DOMContentLoaded, invalidates old script IDs, restores breakpoints when possible, and does not clear cookies/storage/cache/site data. This adds significant value 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 well-structured and front-loaded with the main purpose. Every sentence adds necessary detail (contrast with sibling, behavioral notes, parameter guidance). There is no fluff, and the length is appropriate for the tool's complexity.
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?
Given the tool has 3 parameters, annotations, and an output schema, the description is remarkably complete. It covers when to use, behavioral implications, parameter relationships (e.g., omit type when url provided), and integrates with sibling tools. No gaps are apparent.
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 100%, so baseline is 3. The description does not add new parameter-level information beyond what the schema provides (the schema already explains url, type, and timeout). The description's contextual use cases (e.g., reproduce requests, trigger breakpoints) are helpful but do not enhance parameter semantics specifically. Hence score remains at baseline 3.
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 clearly states the tool navigates, reloads, or moves through history in the currently selected page. It distinguishes itself from the sibling tool 'new_page' by specifying when a separate tab is required. The verb and resource are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides guidance on when to use this tool versus 'new_page' (when a separate tab is needed). It also advises on when to call 'clear_site_data' for a clean replay, and how to handle breakpoints using 'get_paused_info' and 'pause_or_resume'. This gives clear context for appropriate usage.
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?
Discloses state-changing behavior and invalidation side effect. While annotations are limited, description adds useful context beyond them. Could be improved by noting error scenarios.
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?
Concise, front-loaded with main purpose, then alternatives and side effects. No redundant sentences.
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?
Complete for a simple tool: single parameter fully described, usage prerequisites, side effect noted. Given schema coverage and output schema presence, further detail unnecessary.
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 covers enum with descriptions; description adds valuable usage tips (when to use each value, ordering) that go beyond schema.
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?
Clearly states it pauses or resumes execution explicitly, never toggles. Contrasts with break_on_xhr and step, providing clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use alternatives (break_on_xhr, get_paused_info) and warns that resuming invalidates callFrameId, offering clear 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?
The description discloses key behaviors: formatted line numbers may differ from live page, filePath is the resolved local path, and scriptId is scoped to current debugger context and becomes invalid after navigation/refresh. Annotations show readOnlyHint=false and destructiveHint=false, which are consistent. One minor gap: it doesn't mention that the saved file persists or any access restrictions beyond --allowedRoots.
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 detailed but every sentence is informative. It is front-loaded with the main purpose. While slightly long, it avoids redundancy. Could be trimmed slightly, but overall effective.
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?
Given 5 parameters with rich schema, output schema present, the description covers purpose, sibling differentiation, behavioral nuances, and parameter semantics. It mentions the returned filename implicitly. No obvious gaps for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context for each parameter. For url, it explains preferred source and matching strategy. format is described with clear use cases. filePath explains extension implications. scriptId clarifies scoping and invalidation. confirmOverwrite notes authorization. This goes well beyond the schema.
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 clearly states that the tool saves a complete JavaScript or WASM source for local inspection when an inline snippet is insufficient. It differentiates from siblings by mentioning 'Prefer get_script_source for a small known region and search_in_sources to locate text across loaded scripts first.' The specific verb 'saves' and resource 'source' make purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: prefer get_script_source for small regions, use search_in_sources first, and use set_breakpoint_on_text for debugging. It also clarifies when to set format=false and when to use confirmOverwrite. This helps the agent decide when to invoke this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: omitting frameIdx lists without changing context; passing frameIdx changes target; indices shift after navigation or frame changes. No contradiction with readOnlyHint=false (mutates state) and destructiveHint=false.
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?
Single dense paragraph front-loads purpose, then usage, then behavior, then exclusions. Each sentence adds value; no fluff.
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?
Given the complexity (3 params, output schema), the description covers purpose, workflow, side effects, and exclusions. It references sibling tools for related actions.
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 coverage is 100%, so baseline is 3. The description adds workflow context but does not significantly expand parameter meaning beyond what the schema provides.
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 clearly states 'Lists or selects frames, including iframes, within the current page.' It specifies the verb (lists or selects) and resource (frames within current page), and distinguishes from siblings like select_page and navigate_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'when the target element... may live in an iframe' and provides a workflow: first list frames, then pass frameIdx before click_element or evaluate_script. Also tells when not to use: 'It does not switch browser tabs or navigate—use select_page or navigate_page for those actions.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds critical behavioral details: invalidates prior callFrameIds, requires existing pause, and returns next call frame. 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?
Description is efficient and front-loaded with the main action. Three sentences cover behavior, prerequisites, and follow-up without fluff. Every sentence adds value.
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?
Given full parameter schema, annotations, and output schema, the description is complete. It covers prerequisites, invalidation, and next steps, leaving no gaps for an agent.
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 coverage is 100% with descriptions for the direction parameter. The tool description does not add extra meaning beyond the schema, so baseline 3 applies.
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 clearly states it advances JavaScript execution by one debugger operation from a pause, with a specific verb and resource. It distinguishes from siblings like pause_or_resume and get_paused_info by specifying its role in tracing control flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after get_paused_info or evaluate_script when control flow needs tracing, and not from running execution. Also directs to use pause_or_resume to finish, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false); description adds critical behavioral details: default viewport vs. fullPage, oversized capture handling, filePath behavior and confirmOverwrite requirement, fully disclosing tool 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?
Concise 4-sentence description, front-loaded with purpose and usage, no repetition or fluff, efficiently communicates all necessary information.
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?
Given 5 optional parameters, full schema documentation, and presence of output schema, the description covers purpose, usage, behavioral nuances, and key parameter implications, making it fully self-contained.
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 100%, so baseline is 3. Description adds minimal param-specific insight beyond schema (e.g., fullPage behavior, oversized captures), but does not significantly enhance parameter understanding.
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?
Clearly states 'Captures the visual state of the currently selected page.' and distinguishes from sibling tools by specifying it is not a substitute for DOM values, network evidence, or script inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases (verify page layout, UI state, etc.) and explicitly states when not to use it (not for DOM, network, or script), providing clear guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details what is cleared (cookies, persistent storage, sessionStorage) and what is not (page reload, HTTP cache by default), and explains the effect of clearBrowserCache. Annotations indicate destructiveHint=true and readOnlyHint=false, which align with 'irreversibly clear'; no contradiction.
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 slightly verbose but front-loaded with the main purpose. Every sentence adds value, and the structure logically flows from purpose to usage to details.
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?
Given the presence of an output schema (context: 'Has output schema: true'), the description does not need to explain return values. It covers purpose, usage, parameters, and behavioral details comprehensively for a complex tool.
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 coverage is 100%, but the description adds meaning by explaining that confirm=true is required for irreversible action and that clearBrowserCache has a global effect, providing context beyond the schema 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 clearly states the tool irreversibly clears browser state for a clean replay environment, specifying the verb ('clear') and resource ('browser state for selected page'). It distinguishes from sibling tool 'list_network_requests' for cookie inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('before replaying login, session creation...') and when not to use ('do not use it to inspect cookies'), and provides an alternative tool ('list_network_requests') for cookie provenance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, openWorldHint=true, destructiveHint=true. The description adds significant context: arbitrary code can change page state, requires confirm=true, inline results are bounded, paused mode ignores mainWorld, and frameIndex expires. No contradiction with annotations; instead, it elaborates on safety and behavioral edge cases.
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 well-structured, front-loading the core purpose and then providing specific usage notes. It uses clear, separate sentences for distinct points. While slightly verbose, every sentence conveys necessary information without redundancy. It could be marginally tighter but remains highly effective.
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?
Given the tool complexity (7 parameters, 1 required, annotations, output schema, 23 siblings), the description covers all necessary aspects: purpose, usage alternatives, behavioral details (paused vs running, confirm, outputFile), and parameter semantics. It implicitly addresses return values by distinguishing inline vs outputFile results. No gaps are evident.
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 100%, so baseline is 3. However, the description adds meaningful context beyond schema: function parameter explains async functions, localFile argument, JSON serialization limits; mainWorld clarifies its behavior in paused vs running mode; frameIndex mentions expiration; outputFile specifies JSON or raw bytes; localFilePath warns about rejected patterns and host data exposure. This adds value, justifying a 4.
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 clearly states it evaluates JavaScript functions for runtime values like DOM state, web storage, or expressions. It distinguishes itself from siblings by explicitly naming narrower tools (list_network_requests, search_in_sources, get_script_source) and specifying when not to use them. The verb 'evaluate' is specific and the resource ('JavaScript function') is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use (when runtime values are the goal and no narrower tool applies) and when not to use (for cookies, Set-Cookie provenance). It lists alternative tools (list_network_requests, search_in_sources). It also covers paused vs running mode, confirm requirement, and outputFile usage, giving a complete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it doesn't execute or pause the page, and discloses that scriptId is invalid after reload/navigation. This provides critical behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and core guidance. It is slightly verbose but each sentence serves a distinct instructional purpose. Could be tightened, but remains efficient for the complexity.
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?
Despite 6 parameters and many sibling tools, the description covers selection strategies (URL vs scriptId), parameter combinations (line ranges vs offset/length), edge cases (scriptId invalidation, default length), and explicit alternatives (save_script_source, set_breakpoint_on_text). The output schema exists, so return values are not needed in the description.
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 coverage is 100%, so the schema documents all 6 parameters. However, the description adds meaningful usage guidance: 'preferred stable selector' for url, 'ignored unless offset is provided' for length, 'for minified single-line code' for offset, 'inclusive 1-based' for lines, and invalidation conditions for scriptId. This enriches the schema without redundancy.
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 starts with a specific verb ('Reads') and resource ('small source region'), and immediately clarifies scope ('around a search match, paused location, or known statement') and what it does not do ('without executing or pausing the page'). It also distinguishes from sibling tools like save_script_source and set_breakpoint_on_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use URL vs scriptId ('prefer URL for external scripts'), when to use line ranges vs offset/length ('normal source' vs 'minified single-line bundles'), and provides alternatives for whole/minified/WASM source ('use save_script_source') and for runtime values ('call set_breakpoint_on_text'). Also explains when scriptId becomes invalid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are readOnlyHint=false, destructiveHint=false. The description adds rich behavioral context: capture starts on attach, not retroactive, survives navigation with 5000-request FIFO, filter logic, default pagination, cookieName limitations. No contradictions. Provides details beyond annotations.
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 long but well-structured with front-loaded purpose. Every sentence adds value, covering many modes and details. However, it is dense and could be slightly streamlined for a quick read, but given the complexity, it remains efficient.
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?
Given 10 parameters, multiple modes, output schema exists, the description is exceptionally complete. It addresses capture behavior, filter logic, pagination, export options, cookie tracing details, and limitations. No significant gaps.
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 100% so baseline is 3. The description adds extra meaning by explaining parameter interplay (e.g., cookieName + reqid flow, outputFile usage, pageSize default, filter AND/OR). Goes beyond schema by clarifying usage scenarios and combinations, but doesn't introduce entirely new semantics.
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 clearly states it inspects captured HTTP(S) traffic for the currently selected page, listing specific use cases like API calls, headers, auth flows, cookie tracing. It distinguishes from siblings by explicitly mentioning 'Use get_websocket_messages for WebSocket frame payloads; this tool only represents the HTTP upgrade request.' This provides a specific verb and resource, well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive usage guidance is provided: when to use cookieName vs reqid, when to export, default page sizes, AND/OR logic, non-retroactive capture, FIFO queue, and explicit alternative tool mention for WebSockets. Clear context for when and when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite destructiveHint=true annotation, description adds detail on what is irreversibly cleared (request queue, cached response bodies, initiator maps) and what is unchanged (cookies, HTTP cache, storage), exceeding annotation info.
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?
Concise paragraph with front-loaded action, followed by usage guidance, behavioral specifics, and contrast with sibling; every sentence adds value with no redundancy.
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?
Given simple single-parameter tool with output schema, description fully covers purpose, usage, behavioral boundaries, and parameter semantics without missing critical context.
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 coverage is 100% for the single parameter 'confirm', and description reinforces its meaning as required for irreversible capture cleanup, adding nuance beyond schema.
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 specific verb 'discard' and resource 'captured HTTP(S) evidence', clearly distinguishing from sibling clear_site_data by stating what it does not affect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('immediately before reproducing an action when a clean network capture window is needed') and when not to use ('do not use it to reset login, cookies, cache'), with reference to alternative clear_site_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures beyond annotations: confirms destructive side effects, requirement for visibility and exact match, and mentions confirm flag authorizes side effects. 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?
Single paragraph is front-loaded with core purpose, then usage guidelines, then constraints; every sentence adds value without redundancy.
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?
Given 6 parameters, destructive nature, and output schema, the description covers purpose, usage, parameter roles, and behavioral notes comprehensively, leaving no significant gaps.
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 coverage is 100%, but description adds contextual value for each parameter (e.g., selector limited to current frame, index needed for multiple matches, confirm to authorize effects), justifying a score above baseline.
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 explicitly states it performs a verified, auditable click on a known button, link, or control, distinguishing itself from siblings like evaluate_script and select_frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (activating known controls after frame selection) and when not (does not discover elements, type text, or guess matches), and mentions prerequisite of selecting frame and requirement of confirm=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds critical behavioral details: frame indices expire after step/resume, scopes are per pause. No contradiction.
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?
Slightly long but every sentence is informative. Front-loaded with main purpose and key constraints. Could trim some redundancy but still effective.
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?
Given the presence of an output schema and sibling tools, the description covers the lifecycle of pause information, how to combine with evaluate_script, step, and resume, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds valuable context beyond schema: frameIndex expiration, includeScopes usage for efficiency, maxScopeDepth level meanings. Helps agent pick correct values.
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?
Clearly states it inspects current call stack, source locations, and scopes after a pause. Distinguishes from siblings like step and pause_or_resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (after a pause), what not to do (doesn't create/resume pause), and provides alternatives like evaluate_script with frameIndex followed by step or resume.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and destructiveHint annotations, the description discloses key behaviors: lazy capture start, non‑retroactivity, stable frame indices, monotonic but non‑zero starting indices, and eviction of old frames. This adds substantial value over annotations alone.
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 dense paragraph covering all modes and behaviours. While efficient, it could benefit from breaking into bullet points or sections for easier scanning. Still, it earns its place with no redundancy.
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?
Given 10 parameters, multiple modes, and the existence of an output schema, the description is fully complete. It covers initialisation, pagination, filtering, analysis mode, frame indices, and preservation of connections across navigations. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds operational meaning: explaining mode combinations (e.g., without wsid lists connections, with wsid lists frames, with analyze=true groups frames). Clarifies that frameIndex is stable, not page‑relative, and that direction filters but does not apply in connection‑list mode.
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 clearly states the tool inspects captured bidirectional WebSocket connections and frame payloads. It names the resource (WebSocket messages) and accurately contrasts with sibling tool list_network_requests for ordinary HTTP traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (WebSocket, socket, live-update, etc.) and when not (use list_network_requests for HTTP/XHR/fetch). Details initialisation caveat (lazy capture, not retroactive) and mode switching between connection listing and frame inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint), description adds critical non-obvious behavior: capture starts on attachment and is not retroactive. No contradiction.
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?
Concise 4-sentence description with front-loaded purpose and alternatives, then clear parameter and behavior details. No unnecessary words.
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?
Given 5 parameters, output schema, and sibling tools, the description covers all essential aspects: modes, filtering, pagination, capture timing. Complete enough for an agent.
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 coverage is 100%, so description adds value by explaining the dual modes (list vs single message), default page size, and optional filters. Slightly above baseline.
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?
Clearly states the tool inspects console messages and uncaught page errors, with specific verb and resource. Differentiates from siblings by naming alternatives search_in_sources and list_network_requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (diagnose runtime failures, logs, etc.) and when not to (use other tools for source or network). Also describes modes and parameters affecting usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations (readOnlyHint: false, destructiveHint: false) by detailing behavioral traits: it waits for DOMContentLoaded (not every resource), makes the opened page the target for later tools, and preserves cookies/storage/cache. It also mentions using clear_site_data separately for a clean replay. No contradictions 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 four sentences, well-structured: first sentence states the main action, second provides usage guidance, third adds behavioral details, fourth mentions state preservation. No redundant or unnecessary information; every sentence earns its place.
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?
Given the output schema exists and parameters are fully described in the schema, the description provides sufficient context: what the tool does, when to use it, behavioral characteristics, and contrast with sibling. It is complete for the tool's complexity.
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 coverage is 100%, so baseline is 3. The description adds value by explaining the context of the url parameter (absolute URL, reusing about:blank tab), which is not fully captured in the schema's description. However, the timeout parameter is not elaborated beyond the schema, so not a perfect 5.
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 clearly states that the tool opens a separate browser page for a URL, reusing an existing about:blank startup tab. It distinguishes itself from the sibling navigate_page by specifying that navigate_page changes the URL in the existing selected page, making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (when the task needs another tab or should preserve the currently selected page) and when to use the alternative (navigate_page to change the URL in the existing selected page). This provides clear guidelines for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. The description adds behavioral details: searches without executing or pausing the page, returns 1-based lines plus context-scoped scriptIds, and URLs are preferred selectors. No contradictions.
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 well-structured into two paragraphs: first explaining what the tool does and how it works, second providing usage guidance. Every sentence adds value, and there is no redundancy. It is appropriately sized for the complexity.
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?
Given the tool's complexity (7 parameters, output schema exists), the description is complete. It covers behavioral aspects, return elements, and usage context. The output schema exists, so return values need not be elaborated.
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 coverage is 100%, so the baseline is 3. However, the description adds extra meaning for several parameters: urlFilter 'excludes unnamed inline/eval scripts', maxLineLength suggests using get_script_source for surrounding context, excludeMinified explains why keeping default false is best for reverse engineering. This additional context pushes the score to 4.
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 clearly states the tool finds function names, endpoints, string literals, tokens, or code patterns in JavaScript sources. It specifies the scope (selected debugger context, main frame or chosen frame) and distinguishes from siblings by mentioning related tools like select_frame, get_script_source, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives: use select_frame first for iframe-specific work, get_script_source for nearby context, save_script_source for whole bundle, set_breakpoint_on_text when runtime values are needed, and get_request_initiator for a known captured request. It also mentions to prefer get_request_initiator before a broad source search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavioral nuance: listing does not change selection, passing pageIdx makes it the target. This adds value beyond the annotations, which only indicate non-destructive 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?
Three sentences, no fluff, front-loaded with the core purpose. Every sentence adds necessary detail without redundancy.
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?
Given the complexity of selection and pagination, the description is complete. It covers all key behaviors and constraints, and an output schema exists so return values need not be detailed.
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 coverage is 100% with good descriptions, but the tool description adds context about how each parameter affects behavior (e.g., pageIdx changes selection, listPageIdx only paginates). This enhances understanding.
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 clearly states the tool lists or selects open browser pages, with a specific verb and resource. It distinguishes from sibling tools like navigate_page and new_page by stating what it does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use without pageIdx vs with pageIdx, and provides alternatives (navigate_page, new_page). It also clarifies that listPageIdx only paginates and never changes selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: restorable, returns breakpointId, limitation for inline/eval scripts.
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?
Dense single paragraph, front-loads purpose, but could be slightly more structured for readability.
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?
Covers purpose, usage, workflow, return value, and limitations; output schema covers return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds valuable guidance for each parameter (e.g., prefer confirmed snippet, condition restrictions, urlFilter source, occurrence usage).
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?
Clearly states it sets a URL-backed breakpoint on text, distinguishes from siblings like search_in_sources, break_on_xhr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call directly vs. use alternatives (search_in_sources, break_on_xhr) and provides workflow after hit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that removal does not resume a paused page, requires confirmation, and that breakpointId may need to be re-obtained after a debugger rebuild. This adds context beyond annotations (destructiveHint, idempotentHint, readOnlyHint) without contradiction.
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 that are front-loaded with the primary action and then provide usage specifics. No redundant or extraneous information.
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?
Given the tool has 4 parameters, 1 required, and an output schema, the description covers all essential aspects: removal modes, parameter usage, confirmation requirement, post-removal behavior, and edge case handling (breakpointId rebuild). Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds meaning to each parameter: explains url as an exact substring pattern, breakpointId caveat about session rebuild, confirm's authorization role, and action enum values. This enhances understanding beyond the schema's brief 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 specifies the verb 'removes' and the resource 'breakpoint' with three distinct removal modes (code, XHR, all). It references sibling tools (set_breakpoint_on_text, break_on_xhr, list_breakpoints, pause_or_resume) to differentiate when each mode is applicable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use each action: use breakpointId from set_breakpoint_on_text/list_breakpoints for remove_code, use exact URL pattern from break_on_xhr/list_breakpoints for remove_xhr. Also clarifies that removal does not resume a paused page and suggests calling pause_or_resume separately.
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:

[![js-reverse-mcp MCP server](https://glama.ai/mcp/servers/zhizhuodemao/js-reverse-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zhizhuodemao/js-reverse-mcp)

Score Badge

Copy to your README.md:

[![js-reverse-mcp MCP server](https://glama.ai/mcp/servers/zhizhuodemao/js-reverse-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zhizhuodemao/js-reverse-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/zhizhuodemao/js-reverse-mcp'

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