MiniApp CDP MCP

by zhizhuodemao

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.4
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as break_on_xhr for XHR breakpoints versus set_breakpoint_on_text for code breakpoints. However, some overlap exists between list_breakpoints and remove_breakpoint/remove_xhr_breakpoint, as they all manage breakpoints but with different granularities, which could cause minor confusion in selection.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun or verb_noun_noun pattern throughout, such as list_network_requests, get_paused_info, and remove_xhr_breakpoint. There are no deviations in style or convention, making the set predictable and easy to navigate.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for a comprehensive debugging and monitoring server for miniapps. It covers various aspects like breakpoints, network requests, and script analysis without feeling excessively bloated, though it might be borderline for some use cases.
Completeness5/5
The toolset provides complete coverage for debugging miniapps, including breakpoint management, network monitoring, script inspection, and execution control. There are no obvious gaps; tools like step, pause_or_resume, and switch_target ensure full lifecycle support for debugging workflows.
Average 3.4/5 across 19 of 19 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the paused execution context, which is useful, but doesn't cover critical aspects like whether this is a read-only or mutating operation, potential side effects, authentication needs, rate limits, or error handling. For a tool that evaluates JavaScript, this lack of safety and behavioral details is a significant gap.
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 highly concise and front-loaded, with two clear sentences that directly state the tool's function and a key behavioral nuance. Every word earns its place, with no wasted text or redundancy, making it easy for an AI agent to parse quickly.
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 the complexity of evaluating JavaScript (which can involve side effects, security risks, and debugging contexts), no annotations, 0% schema description coverage, and 5 parameters, the description is incomplete. While an output schema exists (which might cover return values), the description lacks crucial context about behavioral traits, parameter meanings, and usage boundaries, making it inadequate for safe and effective tool invocation.
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%, meaning none of the 5 parameters are documented in the schema. The description provides no information about parameters beyond the required 'expression' implied in the purpose. It doesn't explain what 'return_by_value', 'await_promise', 'context_id', or 'frame_index' mean or how they affect evaluation, failing to compensate 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.
Purpose4/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: 'Evaluates a JavaScript expression in the current context.' It specifies the verb ('evaluates') and resource ('JavaScript expression'), and adds important context about paused execution. However, it doesn't explicitly differentiate from sibling tools like 'search_in_sources' or 'get_script_source', which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context with 'If execution is paused, it automatically evaluates in the paused call frame context,' which hints at when this behavior applies. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., for debugging vs. general evaluation), and doesn't mention prerequisites or exclusions, leaving gaps for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like what happens after removal (e.g., does execution resume?), whether this requires specific debugging state, error conditions, or side effects. For a mutation tool with zero annotation coverage, this is insufficient.
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, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core action, making it easy to parse quickly.
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?
Given the tool has an output schema (which handles return values) and simple parameters (1 required, no enums/nesting), the description is minimally complete but lacks crucial context. For a mutation tool with no annotations, it should explain more about behavior, prerequisites, and parameter meaning to be fully helpful.
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 provides no parameter information. It doesn't explain what the 'url' parameter represents (e.g., pattern matching, exact URL, or breakpoint identifier), format expectations, or examples. This leaves the single required parameter undocumented.
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 the action ('Removes') and target resource ('an XHR/Fetch breakpoint'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools like 'remove_breakpoint' or 'break_on_xhr', which would require explicit comparison for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'remove_breakpoint' or 'list_breakpoints'. The description only states what it does without context about prerequisites, timing, or relationship to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool saves to a local file, implying a write operation, but lacks details on permissions, file overwriting behavior, error handling, or rate limits. This is a significant gap for a tool that modifies the local filesystem.
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, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded with the main purpose, making it easy to parse and understand quickly.
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?
Given the tool's complexity (3 parameters, write operation, no annotations) and the presence of an output schema (which may cover return values), the description is minimally adequate but incomplete. It states what the tool does but lacks critical details on usage, parameters, and behavioral traits needed for safe and effective 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 for undocumented parameters. It mentions 'JavaScript script' but doesn't explain how to specify the script (via 'script_id' or 'url') or the 'file_path' format. The description adds minimal meaning beyond the schema, failing to clarify parameter roles or constraints.
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 the action ('Saves') and the resource ('full source code of a JavaScript script to a local file'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_script_source' (which likely retrieves but doesn't save) or 'search_in_sources', leaving room for ambiguity in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a script ID or URL from other tools), exclusions, or comparisons to siblings like 'get_script_source', leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the action parameter values but doesn't explain what 'over', 'into', and 'out' mean in terms of execution behavior. It doesn't describe whether this changes program state, what happens after stepping, or any side effects. The description provides minimal behavioral context beyond the parameter constraints.
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 extremely concise - just one sentence that states the purpose and enumerates the parameter values. There's zero wasted language, and the most critical information (the valid action values) is included. It's appropriately sized for a simple single-parameter control tool.
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?
Given the tool has an output schema (which handles return values), no annotations, and a simple single parameter, the description is minimally complete. It covers the basic purpose and parameter constraints. However, for a debugging/execution control tool, it should ideally explain what the different step actions do and when each is appropriate, which would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only 1 parameter, the description provides the essential semantic information about the 'action' parameter - it lists the three valid values ('over', 'into', 'out'). While it doesn't explain what these values mean, it does provide the enumeration that's missing from the schema. For a single parameter tool, this gives adequate semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Controls execution when paused' which gives a vague purpose - it indicates a control function during paused execution but doesn't specify what resource or system is being controlled. It doesn't distinguish from siblings like 'pause_or_resume' or 'get_paused_info' which also relate to execution control. The purpose is understandable but lacks specificity about what execution context is being stepped through.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when stepping is appropriate versus using 'pause_or_resume' for different control needs, or when to use 'get_paused_info' for status checking instead. There's no context about prerequisites (must be paused first) or exclusions for when stepping isn't applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, error handling, or output format. For a tool with no annotations, this is a significant gap in transparency about its operational 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 description is appropriately sized and front-loaded, consisting of two concise sentences that directly state the tool's purpose and utility. Every sentence earns its place without redundancy or unnecessary details.
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?
Given the tool has an output schema, the description does not need to explain return values. However, with no annotations, 0% schema coverage, and one parameter, the description is minimal. It covers the basic purpose but lacks details on usage context or behavioral traits, making it adequate but with clear gaps for a debugging tool.
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. It implies the need for a 'request_id' by mentioning 'initiated a network request,' but does not explicitly describe the parameter or its format. The description adds minimal value beyond the schema, resulting in a baseline score due to incomplete parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Gets') and resource ('JavaScript call stack that initiated a network request'), and explains its utility ('helps trace which code triggered an API call'). However, it does not explicitly differentiate from sibling tools like 'list_network_requests' or 'get_response_body', which are related but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the tool's purpose but does not specify prerequisites (e.g., needing a request ID from 'list_network_requests'), exclusions, or direct comparisons to siblings like 'get_response_body' for response data or 'list_network_requests' for listing requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It explains the toggle action but doesn't mention important behavioral aspects like whether this affects all scripts globally, requires specific permissions, has side effects on debugging state, or what happens to breakpoints. The description is minimal and lacks needed context.
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 extremely concise with just two sentences that directly explain the toggle behavior. Every word earns its place with no wasted text, and the information is front-loaded with the core functionality stated immediately.
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 this is a debugging control tool with no annotations but an output schema exists, the description is insufficient. It doesn't explain what the toggle returns, what state changes occur, or how this interacts with other debugging tools. For a tool that controls JavaScript execution, more context about scope and effects is needed.
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?
The tool has zero parameters, and schema description coverage is 100% (though empty). The description appropriately doesn't discuss parameters since none exist, which is correct for a parameterless tool. No additional parameter information is needed or provided.
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 the tool's purpose: toggling JavaScript execution with specific states (paused/resumed). It uses a specific verb ('toggles') and identifies the resource ('JavaScript execution'), but doesn't distinguish from siblings like 'step' or 'break_on_xhr' that also control execution flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'step' for stepping through code or 'break_on_xhr' for pausing on network events. The description only explains what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool removes a breakpoint, implying a destructive mutation, but doesn't mention permissions needed, whether the removal is permanent/reversible, error conditions, or what happens after removal. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information immediately.
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?
Given this is a destructive mutation tool with no annotations, 0% schema description coverage, but with an output schema (which handles return values), the description is minimally adequate. It states the core action but lacks important context about permissions, side effects, and relationship to sibling 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 must compensate. It mentions 'by its ID' which clarifies the purpose of the single parameter, adding meaning beyond the schema's bare 'breakpoint_id' field. However, it doesn't explain ID format, source, or constraints, leaving some ambiguity.
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 the action ('Removes') and target ('a breakpoint by its ID'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'remove_xhr_breakpoint' or explain what distinguishes this general breakpoint removal from specialized variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'remove_xhr_breakpoint' or 'list_breakpoints' (which might be needed first to identify breakpoint IDs). The description only states what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action and purpose without disclosing behavioral traits. It doesn't mention side effects (e.g., if this interrupts ongoing debugging, requires re-authentication, or affects other tools), error conditions, or what the switch entails operationally beyond the high-level goal.
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, efficient sentence that front-loads the core action and purpose with zero wasted words. It uses parentheses for concise examples without disrupting flow, making it appropriately sized for the tool's complexity.
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?
Given the tool's moderate complexity (1 parameter, no annotations, but has output schema), the description covers the basic purpose and context adequately. However, it lacks details on parameter usage, behavioral implications, and integration with siblings like list_targets, leaving gaps for effective agent invocation despite the output schema handling return values.
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 adds no parameter information. It doesn't explain what 'target_id' represents (e.g., how to obtain valid IDs from list_targets), format expectations, or examples. The description's mention of 'target thread' hints at the parameter's role but lacks actionable details.
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 the action ('switches the CDP connection') and resource ('to a different target thread'), with examples of thread types (WebView, AppService) and purpose ('to debug different parts of the miniapp'). It distinguishes from siblings by focusing on connection switching rather than debugging actions like breakpoints or script evaluation, though it doesn't explicitly name alternatives.
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 context ('to debug different parts of the miniapp') and suggests when to use it based on debugging needs, but lacks explicit guidance on when not to use it or named alternatives. It doesn't specify prerequisites like needing an active connection or list_targets first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't cover aspects like whether it's read-only, if it requires specific permissions, how results are formatted, or any limitations (e.g., pagination). This leaves significant gaps in understanding the tool's 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 description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations and multiple sibling tools, it lacks context on usage scenarios and behavioral traits, leaving room for improvement in guiding the agent effectively.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required by not mentioning any. This meets the baseline for zero-parameter tools.
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 the verb 'lists' and specifies the resources 'all active XHR and code breakpoints', making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'remove_breakpoint' or 'remove_xhr_breakpoint', but the listing nature is clear from the verb choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_network_requests' or 'list_scripts', nor does it mention prerequisites or context for usage. It's a standalone statement without any comparative or contextual framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action 'Lists' but does not describe key traits like whether this is a read-only operation, if it requires specific debugger states, potential rate limits, or the format of the output. For a tool in a debugger context with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that front-loads the key action ('Lists all available targets') and adds clarifying details without waste. Every word earns its place by specifying the resource and context, making it easy to grasp quickly.
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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is adequate for a simple listing operation. However, it lacks details on behavioral aspects like debugger state requirements or output format, which could be important in a debugging context. With no annotations, the description does not fully compensate for missing behavioral context, making it minimally 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?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds value by specifying what is listed ('targets') and providing examples ('WebView threads, AppService threads, etc.'), which clarifies the resource semantics beyond the empty schema. Since there are no parameters, the baseline is 4, and the description enhances understanding appropriately.
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 the verb ('Lists') and resource ('all available targets'), specifying what the tool does. It distinguishes the resource by mentioning examples like 'WebView threads, AppService threads, etc.' and the context 'in the connected debugger'. However, it does not explicitly differentiate from sibling tools like 'switch_target', which might involve target selection rather than listing, so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or comparisons to sibling tools such as 'switch_target' (for changing targets) or 'list_scripts' (for listing scripts). Without such context, users may struggle to choose the right tool in the debugger environment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the dual behavior based on 'wsid' parameter, which is helpful, but fails to disclose critical traits like whether this is a read-only operation, if it requires specific permissions, rate limits, or what the output looks like. For a tool with 5 parameters and no annotation coverage, this leaves significant behavioral gaps.
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 highly concise and front-loaded, using just two sentences that efficiently convey the core functionality and usage rules. Every sentence earns its place with no wasted words, making it easy to parse quickly.
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?
Given 5 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers the primary use cases but lacks details on parameter meanings, behavioral traits, and output interpretation. The output schema mitigates some gaps, but overall it's insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the 'wsid' parameter's effect on tool behavior, ignoring 'direction', 'show_content', 'page_size', and 'page_idx'. This adds minimal value beyond the schema, failing to address the majority of parameters or their purposes, which is inadequate given the low coverage.
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 the tool's dual functionality: 'Lists WebSocket connections or gets messages for a specific connection.' It specifies the verb ('lists', 'gets') and resource ('WebSocket connections', 'messages'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_network_requests' or 'list_targets', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use each mode: 'Without wsid, lists all connections. With wsid, gets messages.' This gives explicit guidance on parameter-driven behavior. However, it doesn't mention when to use this tool over alternatives like 'list_network_requests' or provide exclusions, which limits the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'gets a snippet' and supports different extraction methods, but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what happens with invalid inputs. The description is insufficient for a mutation-sensitive agent.
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 efficiently structured in a single sentence that packs essential information: purpose, primary parameters, and usage guidance for different file types. Every word earns its place with zero redundancy or unnecessary elaboration.
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?
Given the tool's moderate complexity (6 parameters, no annotations, but with output schema), the description provides adequate but incomplete context. It covers parameter purposes and some usage guidance but lacks behavioral transparency details. The presence of an output schema reduces the need to describe return values, but more operational context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by explaining parameter semantics. It clarifies that 'script_id' and 'url' are alternative identifiers (with URL recommended), explains that 'start_line' and 'end_line' are for normal files while 'offset' is for minified single-line files, and implies 'length' controls snippet size. This compensates well 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.
Purpose4/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: 'Gets a snippet of a JavaScript script source' with two identification methods (URL or script ID). It specifies the resource (JavaScript script source) and verb (gets a snippet), but doesn't explicitly differentiate from sibling tools like 'search_in_sources' or 'list_scripts' beyond the snippet extraction aspect.
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 provides some usage context by recommending URL over script ID and explaining when to use line range vs. character offset. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_in_sources' or 'list_scripts', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what gets returned (matching lines with metadata) but doesn't cover important behavioral aspects like whether this is a read-only operation, potential performance impact of searching 'all loaded JavaScript sources', whether results are paginated or limited, or any rate limits. The description provides basic output format but lacks operational context.
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 perfectly concise with two sentences that each earn their place: the first states the action and scope, the second specifies the return format. No wasted words, well-structured, and front-loaded with the core functionality.
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?
Given the tool has an output schema (which presumably documents the return structure), the description doesn't need to detail return values. However, for a search tool with 7 parameters and no annotations, the description is incomplete - it doesn't address parameter usage, behavioral constraints, or provide sufficient context for effective tool selection versus siblings. It covers the basic purpose well but leaves significant gaps.
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?
With 0% schema description coverage and 7 parameters, the description provides no information about any parameters beyond what's implied by the tool name ('search' suggests a query parameter). It doesn't explain what 'max_results', 'exclude_minified', 'url_filter', or other parameters do, leaving significant gaps in understanding how to effectively use the 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?
The description clearly states the specific action ('Searches for a string or regex pattern'), target resource ('in all loaded JavaScript sources'), and output format ('Returns matching lines with script ID, URL, and line number'). It distinguishes from siblings like 'list_scripts' (which lists without searching) and 'get_script_source' (which retrieves specific source content).
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 for searching within JavaScript sources, but provides no explicit guidance on when to use this tool versus alternatives like 'list_scripts' for browsing or 'get_script_source' for retrieving specific content. It mentions 'all loaded JavaScript sources' which gives some context scope, but lacks when-not-to-use scenarios or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool sets a breakpoint that triggers on URL matches, but it does not describe what happens when triggered (e.g., pauses execution, logs details), potential side effects, permission requirements, or error handling. This leaves significant gaps for a mutation tool with no annotation coverage.
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, well-structured sentence that efficiently conveys the tool's purpose and parameter usage without any redundant information. It is front-loaded and appropriately sized, with every word earning 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?
Given the tool's complexity (a mutation tool for debugging), no annotations, 1 parameter with low schema coverage, and an output schema (which reduces need to describe return values), the description is somewhat complete but lacks details on behavioral outcomes, error cases, and integration with sibling tools. It provides a basic understanding but leaves gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description adds meaning by specifying that the 'url' parameter is a string used to match against XHR/Fetch request URLs. However, it does not provide details on format (e.g., substring matching, case sensitivity) or examples, so it partially compensates but does not fully cover the parameter semantics beyond the basic 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 the tool's purpose with a specific verb ('Sets a breakpoint') and resource ('XHR/Fetch request URL'), and it distinguishes from siblings like 'remove_xhr_breakpoint' (which removes breakpoints) and 'set_breakpoint_on_text' (which sets breakpoints on text in scripts). It precisely defines the trigger condition ('when an XHR/Fetch request URL contains the specified string').
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 for debugging XHR/Fetch requests by setting breakpoints based on URL patterns, but it does not explicitly state when to use this tool versus alternatives like 'list_breakpoints' (to view breakpoints) or 'remove_xhr_breakpoint' (to remove such breakpoints). It provides context but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It mentions session_id inference from 'monitored request cache' which adds some context, but doesn't disclose permissions needed, rate limits, error conditions, or what happens if the request_id is invalid. For a tool that likely interacts with network debugging data, this is insufficient transparency.
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 extremely concise (two sentences) with zero wasted words. The first sentence states the core purpose, and the second provides important usage detail about parameter inference. Every sentence earns its place and information is front-loaded appropriately.
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?
Given that an output schema exists (so return values are documented elsewhere), the description's main job is to explain when and how to use this tool. It does this adequately but incompletely - it references list_network_requests appropriately but doesn't cover error cases, permissions, or the nature of the 'monitored request cache'. For a network debugging tool with no annotations, this leaves significant gaps.
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 schema provides no parameter documentation. The description adds meaningful context for session_id (can be omitted, inferred from cache) but doesn't explain request_id's purpose or format. Since there are 2 parameters and the description only partially addresses one, it provides some but incomplete semantic value beyond the bare schema.
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 the verb 'Get' and the resource 'response body for a request returned by list_network_requests', making the purpose specific and understandable. It distinguishes from siblings by referencing a specific sibling tool (list_network_requests) as the source of requests, though it doesn't explicitly differentiate from all other tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool after list_network_requests to retrieve response bodies, and mentions that session_id can be omitted if inferred from cache. However, it doesn't specify when NOT to use this tool or name explicit alternatives among siblings, which prevents a perfect score.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return format (script ID, URL, source map info) and implies a read-only operation by using 'Lists', but lacks details on permissions, rate limits, or error handling. It adds some context but is not comprehensive for a tool with no 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 front-loaded with the core purpose in the first sentence, followed by usage guidance. Every sentence earns its place by providing essential information without redundancy, making it appropriately sized and efficient.
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 tool's complexity (simple list operation), no annotations, and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose and usage but lacks parameter details and some behavioral aspects like error cases, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It does not mention the 'url_filter' parameter at all, failing to add meaning beyond the schema. Since schema coverage is low, the baseline is lower, but the description does not address the parameter, resulting in a minimal score.
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 specific action ('Lists all JavaScript scripts loaded in the current page') and resource ('JavaScript scripts'), distinguishing it from siblings like list_breakpoints or list_network_requests. It explicitly mentions what information is returned (script ID, URL, source map), making the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Use this to find scripts before setting breakpoints or searching'), linking it to specific workflows. However, it does not explicitly state when not to use it or name alternative tools for similar purposes, such as get_script_source for detailed script content.
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?
With no annotations provided, the description carries full burden. It describes what information is returned but doesn't mention behavioral aspects like whether this requires debugger access, if it works only in specific debug modes, or potential performance implications. It provides basic context but lacks operational details.
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, zero waste. First sentence states purpose and what's returned. Second sentence provides clear usage guidance. Every word earns its place with no redundancy or unnecessary elaboration.
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 tool has an output schema (which covers return values), the description focuses appropriately on purpose and usage context. It provides enough information for an agent to understand when and why to use this tool, though parameter guidance is missing. For a debug inspection tool with output schema, this is reasonably complete.
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. However, the description mentions no parameters at all, while there are 3 parameters in the schema. The description doesn't explain what 'include_scopes', 'max_scope_depth', or 'frame_index' mean or how they affect the returned information.
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 verb ('Gets information') and the specific resource ('current paused state'), listing the exact data returned (call stack, current location, scope variables). It distinguishes from siblings by focusing on debug state inspection rather than breakpoint management or execution control.
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 this tool: 'Use this after a breakpoint is hit to understand the execution context.' This provides clear situational guidance and distinguishes it from other debugging tools that might be used at different times or for different purposes.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: automatic connection and setup on first call ('automatically connects to the endpoint, infers the target, attaches only that target, enables Network on that target session, and starts collecting XHR/Fetch requests'), sorting order ('newest-first'), default pagination ('20 most recent requests'), and pagination controls. It doesn't mention rate limits, authentication needs, or error conditions, but covers essential operational behavior well.
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 appropriately sized and front-loaded, starting with the core purpose. Each sentence adds value: the first defines the tool, the second covers sorting and pagination, the third explains the 'reqid' parameter, and the fourth details the automatic setup on first call. There's no wasted text, though it could be slightly more structured (e.g., bullet points for behaviors), but it remains efficient and clear.
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 tool's complexity (9 parameters, no annotations, but with an output schema), the description is mostly complete. It covers the tool's purpose, key behaviors, and some parameter semantics. The presence of an output schema means return values don't need explanation, but the description could better address all parameters and potential side effects (e.g., what 'clear_existing' does). It's sufficient for basic use but has minor gaps for advanced scenarios.
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 must compensate. It adds meaningful context for several parameters: it explains 'page_size/page_idx' for pagination, 'reqid' for retrieving a single request's details, and implies filtering through 'resource_types' and 'url_filter' by mentioning 'XHR/Fetch requests' and general listing. However, it doesn't cover all 9 parameters (e.g., 'endpoint', 'include_preserved_requests', 'wait_ms', 'clear_existing' are not addressed), leaving some gaps in 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?
The description clearly states the tool's purpose: 'List network requests for the currently selected miniapp target/session since MCP started monitoring it.' It specifies the verb ('List'), resource ('network requests'), scope ('currently selected miniapp target/session'), and temporal boundary ('since MCP started monitoring it'). It distinguishes itself from sibling tools like 'get_request_initiator' or 'get_response_body' by focusing on listing requests rather than retrieving specific details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to list network requests for a monitored miniapp target/session. It mentions using 'reqid to get a single request's full details,' which implies an alternative use case within the same tool rather than pointing to a different sibling tool. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings (e.g., 'get_request_initiator' for initiator details), leaving some guidance implicit.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds critical behavioral context beyond the input schema: the warning about minified code behavior ('this will break on the one-time assignment rather than the execution'), specific usage constraints, and workflow dependencies. This provides essential transparency for safe and effective use.
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 efficiently structured with two sentences: the first states the purpose, the second provides critical workflow guidance. Every sentence earns its place by delivering essential information without redundancy. The warning is appropriately front-loaded with 'CRITICAL AI WORKFLOW WARNING' to emphasize importance.
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 (debugging operation with potential pitfalls), no annotations, and 0% schema coverage, the description provides excellent contextual completeness. It explains the core behavior, critical constraints, and proper workflow integration. The presence of an output schema means the description doesn't need to explain return values, allowing it to focus on usage guidance.
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 undocumented parameters. The description mentions 'text string' which aligns with the 'text' parameter, but doesn't explain the 'case_sensitive' or 'condition' parameters. While it adds some semantic context for the primary parameter, it doesn't fully compensate for the coverage gap across all three 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's purpose: 'Finds a text string in all loaded scripts and sets a breakpoint at that location.' This specifies both the verb ('finds' and 'sets') and the resource ('text string in all loaded scripts'), distinguishing it from siblings like 'remove_breakpoint' or 'list_breakpoints'.
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 versus alternatives: 'Do NOT set breakpoints on function names or assignment statements... Instead, ALWAYS use get_script_source to read the function body first, then set the breakpoint on a specific statement INSIDE the function body.' It names a specific sibling tool ('get_script_source') as a prerequisite for proper usage.
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:

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

Score Badge

Copy to your README.md:

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

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