CDP MCP

by RED-BASE

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
The tool set has clear distinctions for core browser automation tasks like navigation, interaction, and reading, but there is notable overlap between cdp_interact, cdp_set_value, and cdp_type_text for input handling, and between cdp_find_elements and cdp_site_scan for element discovery. Descriptions help clarify, but an agent might struggle to choose the optimal tool in some scenarios.
Naming Consistency5/5
All tools follow a consistent 'cdp_' prefix with snake_case naming, using clear verb_noun patterns (e.g., cdp_launch, cdp_navigate, cdp_read). This uniformity makes the tool set predictable and easy to navigate, with no deviations in style.
Tool Count2/5
With 27 tools, the count is excessive for a browser automation server, leading to potential confusion and redundancy. While the domain is broad, many tools (e.g., cdp_click_coordinates vs. cdp_interact for clicking) could be consolidated, making the set feel heavy and over-engineered.
Completeness5/5
The tool set comprehensively covers browser automation and site interaction, including connection, navigation, element discovery, interaction, reading, screenshot, form handling, and memory management. There are no obvious gaps; it supports full workflows from launch to debugging, with specialized tools for edge cases like shadow DOM and Monaco editor.
Average 3.5/5 across 27 of 27 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries full burden. It states the action but lacks critical behavioral details: it doesn't specify if this requires prior setup (e.g., a connected browser via cdp_connect), what the execution context entails (e.g., sandboxing, permissions), potential side effects (e.g., page modifications), or error handling. This leaves significant gaps for a tool that executes arbitrary JavaScript.
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 waste—it directly states the tool's purpose without fluff. It's appropriately sized and front-loaded, making it easy for an 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 executing JavaScript in a browser context, no annotations, and no output schema, the description is incomplete. It misses key details like required setup (e.g., connection via cdp_connect), return values (e.g., script results or errors), and safety considerations, which are crucial for effective tool 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?
Schema description coverage is 100%, so the schema fully documents both parameters (script and frame_id). The description doesn't add any meaning beyond this, such as examples of valid JavaScript or when to use frame_id versus default context. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 ('Execute') and target ('JavaScript in the page context'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like cdp_interact or cdp_frame_interact that might also involve JavaScript execution, so it lacks sibling differentiation 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?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a connected page via cdp_connect), exclusions, or comparisons to siblings like cdp_interact for simpler interactions, leaving the agent without contextual usage cues.
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 the action ('mark as fixed and remove') but doesn't specify whether this is a destructive operation, requires specific permissions, has side effects, or what happens if the bug ID is invalid. 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 that directly states the tool's purpose without any redundant or unnecessary information. It is front-loaded and appropriately sized, making it easy for an 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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances like confirmation prompts or irreversible changes, which are critical for safe and 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 100% description coverage, with the 'id' parameter clearly documented as 'Bug ID to mark as fixed'. The description doesn't add any extra semantic details beyond this, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating further.
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 ('Mark a bug as fixed and remove it from the tracking file') with a specific verb ('mark') and resource ('bug'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'cdp_track_bug' or 'cdp_list_bugs', which would be needed 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?
The description provides no guidance on when to use this tool versus alternatives, such as when to mark a bug as fixed instead of tracking or listing bugs. It lacks any mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the purpose 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it lists action types, it doesn't describe what happens during execution (e.g., whether it waits for elements, handles errors, or has side effects). For a complex interaction tool with 7 parameters, this leaves critical behavioral traits undocumented, though it doesn't contradict any 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 extremely concise—a single sentence listing key actions with 'etc.' to imply broader capabilities. It's front-loaded with the core purpose and wastes no words. Every part of the description earns its place by communicating essential functionality efficiently.
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 tool's complexity (7 parameters, no annotations, no output schema) and the presence of many sibling tools with overlapping functions, the description is inadequate. It doesn't explain return values, error conditions, or how it differs from specialized siblings. For a general-purpose interaction tool in a crowded namespace, more context is needed to guide proper usage.
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 the schema already documents all 7 parameters thoroughly with descriptions and enums. The description adds no parameter-specific information beyond implying the 'action' parameter through its examples. This meets the baseline of 3 when schema coverage is high, but doesn't provide additional semantic context.
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: 'Interact with elements' followed by specific action examples (click, type, upload files, select options, etc.). It uses a verb+resource pattern and lists concrete actions, making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like cdp_click_coordinates or cdp_type_text, which appear to offer overlapping functionality.
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. With multiple sibling tools that seem related (e.g., cdp_click_coordinates, cdp_type_text, cdp_submit_form), there's no indication of when this general-purpose interaction tool is preferred over more specialized ones. The description only lists capabilities without context for selection.
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 lacks critical behavioral details: it doesn't specify if navigation is synchronous/asynchronous, error handling (e.g., for invalid URLs), side effects (e.g., page load events), or dependencies (e.g., requires a connected browser via cdp_connect). For a navigation tool with zero annotation coverage, this 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 extremely concise and front-loaded in a single sentence, with zero wasted words. Every part ('navigate to a URL or perform navigation actions') directly contributes to understanding the tool's purpose, making it efficient and easy to parse.
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 tool's moderate complexity (navigation with multiple parameters), no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., how navigation interacts with browser state), error handling, and dependencies, which are crucial for an AI agent to use this tool correctly in a browser automation context.
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 the schema already documents all three parameters (url, action, tab) with descriptions and enum values. The description adds no additional meaning beyond what the schema provides—it mentions URL and actions but doesn't clarify parameter interactions (e.g., using url vs. action) or usage context. Baseline 3 is appropriate when the schema does the heavy lifting.
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 specific verbs ('navigate to a URL' and 'perform navigation actions') and resources (URL, back/forward/refresh actions). It distinguishes this as a navigation tool among siblings that include interaction, reading, and site management tools, though it doesn't explicitly differentiate from similar navigation-related siblings like cdp_launch.
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 an active browser session), exclusions (e.g., not for initial browser launch), or comparisons to siblings like cdp_launch (which might handle initial navigation) or cdp_interact (which might include navigation-like actions).
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 behavioral details. It doesn't disclose whether this is a read-only operation (implied by 'Read' but not explicit), what permissions or context are needed (e.g., requires an active page connection), potential rate limits, or error handling. It only lists what can be read without 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 extremely concise and front-loaded in a single sentence, with no wasted words. Every phrase ('Read content from the page', 'full page text, element text, attributes') directly contributes to understanding the tool's purpose efficiently.
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 no annotations, no output schema, and a tool that reads content (which could involve complex returns like text or attributes), the description is incomplete. It doesn't explain what the output looks like (e.g., string, object), how errors are handled, or prerequisites like needing a connected page. For a read operation with potential variability, more context is needed.
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 the schema already documents all parameters. The description adds minimal value by implying that 'target' corresponds to 'full page text, element text, attributes', but doesn't clarify how parameters interact (e.g., 'selector' is needed for 'element' target) or provide examples. Baseline 3 is appropriate as the schema does the heavy lifting.
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 'Read' and the resource 'content from the page', specifying what can be read: 'full page text, element text, attributes'. It distinguishes from siblings like cdp_click_coordinates (interaction) or cdp_navigate (navigation), but doesn't explicitly differentiate from cdp_find_elements (which finds but doesn't read content).
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 on when to use this tool versus alternatives is provided. It doesn't mention when to prefer cdp_read over cdp_find_elements for reading element text, or when to use it for page text versus other tools. The description only states what it does, not when to use it.
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 conditions but lacks critical behavioral details: it doesn't specify what happens on timeout (e.g., error or return), whether it blocks execution, if it's idempotent, or any performance implications. This is inadequate for a tool with potential side effects like navigation changes.
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, efficient sentence that front-loads the core action ('Wait for conditions') and lists examples. There's no wasted text, though it could be slightly more structured by grouping conditions or adding a brief context.
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 a conditional waiting tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error handling, or interaction with other tools (e.g., what happens after waiting). This leaves significant gaps for an AI agent to use it correctly in automation scenarios.
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 the schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying the condition types, which are already covered by the enum in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 as waiting for various conditions (element visible, text contains, navigation, etc.), which is a specific verb+action. However, it doesn't explicitly differentiate this from sibling tools like cdp_navigate or cdp_find_elements, which might involve similar timing or condition-checking aspects.
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 lists conditions but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't mention whether this is for synchronous waiting during automation or how it relates to tools like cdp_interact or cdp_execute.
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. While 'Discover' implies a read-only operation, the description doesn't specify whether this requires page interaction, what happens if no elements are found, or any performance considerations (e.g., timeouts, pagination). It mentions 'interactive elements' but doesn't define what makes an element interactive beyond the examples. For a tool with 6 parameters and no annotation coverage, this 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 a single, efficient sentence that front-loads the core purpose. Every word earns its place by specifying the action ('Discover'), target ('interactive elements'), and context ('on the page'), with helpful examples in parentheses. There's no 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 output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format. Without annotations or an output schema, the agent must infer how results are returned (e.g., list of elements, their properties) and any operational constraints.
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 100% description coverage, providing clear documentation for all 6 parameters including their types, defaults, and examples (e.g., exclude_text). The description adds no parameter-specific information beyond the general scope of 'interactive elements.' Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Discover') and target ('interactive elements on the page'), and provides examples of what constitutes interactive elements (inputs, buttons, links, etc.). It distinguishes itself from siblings like cdp_click_coordinates or cdp_navigate by focusing on element discovery rather than interaction or navigation. However, it doesn't explicitly differentiate from cdp_interact which might also involve elements.
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. With many sibling tools available (e.g., cdp_interact, cdp_click_coordinates, cdp_set_value), there's no indication of when element discovery is preferred over direct interaction or other methods. The description lacks any context about prerequisites, typical use cases, 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 the full burden of behavioral disclosure. It states the tool lists bugs but doesn't describe what 'tracked bugs' entails, the return format, pagination, or any operational constraints like rate limits or permissions needed. This leaves significant gaps for a tool with potential complexity.
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 unnecessary words. It is appropriately sized and front-loaded, making it easy for an 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'tracked bugs' means, the structure of the returned list, or how this tool relates to siblings like 'cdp_track_bug'. For a tool in a complex environment (CDP-MCP with many siblings), more context is needed to be fully 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, earning a baseline score of 4 for tools with zero parameters.
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 ('List') and resource ('all tracked bugs in CDP-MCP'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'cdp_track_bug' or 'cdp_fix_bug', which would require explicit contrast to achieve a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, timing, or comparisons to sibling tools like 'cdp_track_bug' or 'cdp_fix_bug', leaving the agent without usage direction.
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 action but doesn't describe what 'List' entails—whether it returns tab titles, URLs, IDs, or a structured array, or if it's a read-only operation. For a tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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 function with zero wasted words. It is front-loaded and appropriately sized for a simple listing tool, making it easy for an 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 lack of annotations and output schema, the description is incomplete. It doesn't explain the return format (e.g., list of tab objects with properties) or any behavioral nuances (e.g., requires an active CDP connection). For a tool in a complex browser automation context, this leaves the agent guessing about critical execution details.
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, and the input schema has 100% description coverage (though empty). The description appropriately doesn't discuss parameters, as none exist. It earns a baseline 4 because no parameter information is needed, and the description doesn't misleadingly suggest any.
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 ('List') and resource ('all open browser tabs'), making the tool's purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like cdp_list_frames or cdp_site_list, but the specificity of 'browser tabs' provides inherent distinction. This is not a tautology since the name 'cdp_list_tabs' doesn't fully convey the scope.
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 cdp_list_frames or cdp_site_list. It doesn't mention prerequisites (e.g., needing an active browser session via cdp_connect) or typical use cases (e.g., inventory before navigation). The agent must infer usage from context 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states what the tool does, it lacks critical behavioral information such as whether this requires specific permissions, if it's synchronous/asynchronous, potential side effects, or what happens with invalid selectors. For a tool with no annotation coverage, this 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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with good schema documentation and is perfectly front-loaded.
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 (5 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It states the core purpose but lacks behavioral context, usage guidance, and output information. The 100% schema coverage helps, but the description should do more for a tool with this level of functionality.
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 the schema already documents all 5 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema (like clarifying interactions between parameters or edge cases). Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Capture a screenshot') and the target ('page or a specific element'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from potential screenshot-related siblings (though none appear in the sibling list), 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 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, prerequisites, or contextual constraints. With many sibling tools available (like cdp_read, cdp_find_elements, etc.), there's no indication of when screenshot capture is preferred over other interaction methods.
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 automatic frame searching, which is useful context, but fails to describe critical behaviors like error handling, performance implications of searching all frames, or what happens if the element isn't found. For a tool with mutation actions like 'click' and 'type', this 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 extremely concise with just two sentences that directly state the tool's purpose and key behavior. Every word earns its place, and it's front-loaded with the core functionality. No wasted verbiage or redundancy.
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 tool's complexity (4 parameters with mutation actions), lack of annotations, and no output schema, the description is insufficient. It doesn't explain return values, error conditions, or the implications of different actions. For a tool that performs operations like 'click' and 'type' in iframes, more behavioral context is needed.
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%, providing clear documentation for all parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining selector specificity in iframes or action nuances. This meets the baseline of 3 when schema coverage is high.
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: 'Interact with elements inside iframes' with the specific action of 'Automatically searches all frames for the element.' It distinguishes itself from siblings like cdp_interact by focusing specifically on iframe elements, 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 (when dealing with iframes) but doesn't provide explicit guidance on when to use this versus alternatives like cdp_interact or cdp_find_elements. It mentions automatic frame searching, which suggests it's for cross-frame interactions, but lacks clear 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?
No annotations are provided, so the description carries the full burden. It states the tool lists sites 'in memory' with 'key info', which implies a read-only operation that returns structured data. However, it doesn't disclose critical behavioral traits: what 'key info' includes (e.g., URLs, titles), whether it's paginated or returns all at once, if it requires an active browser session, or potential errors. For a tool with zero annotation coverage, this leaves significant 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 a single, efficient sentence that front-loads the core action ('List all sites in memory') and adds clarifying detail ('with their key info'). There is no wasted verbiage, repetition, or unnecessary elaboration, making it highly concise and well-structured.
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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks completeness for practical use: no output details (what 'key info' entails), no behavioral context (e.g., dependencies on other tools like cdp_launch), and no error handling. With no output schema, the description should ideally hint at return values, but it doesn't, leaving gaps for an AI 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?
The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. It appropriately avoids discussing inputs.
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 ('List') and resource ('all sites in memory') with the scope of providing 'their key info'. It distinguishes from siblings like cdp_site_info (which likely provides detailed info for a specific site) and cdp_site_clear (which clears sites). However, it doesn't explicitly differentiate from cdp_list_tabs or cdp_list_frames, which are related but different resources.
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., after launching a browser with cdp_launch), exclusions, or comparisons to siblings like cdp_site_info for detailed site data or cdp_list_tabs for tab-level listing. Usage is implied as a general listing operation but lacks explicit context.
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 tool adds to 'site memory,' implying persistence, but doesn't specify if this is permanent, reversible, or requires specific permissions. For a tool that modifies memory without annotation coverage, this is a significant gap in describing behavioral traits like data retention or access controls.
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 concise and front-loaded, consisting of two sentences that directly state the purpose and usage. There's no unnecessary information, and each sentence adds value: the first defines the action, and the second provides context. It could be slightly improved by integrating the two ideas more seamlessly, but it's efficient overall.
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, no output schema, no annotations), the description is moderately complete. It covers the basic purpose and usage but lacks details on behavioral aspects like how notes are stored or retrieved. Without annotations or output schema, more context on the tool's effects and limitations would be beneficial, but it meets a minimum viable level for a simple memory-adding 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?
The input schema has 100% description coverage, with clear parameter descriptions (e.g., 'Note to add' for 'note'). The description adds minimal value beyond the schema, as it only hints at usage ('record what you learned') without detailing parameter interactions or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a note or selector pattern to site memory.' It specifies the verb ('Add') and resource ('note or selector pattern to site memory'), making the action explicit. However, it doesn't differentiate from sibling tools like cdp_site_clear or cdp_site_info, which also interact with site memory but for 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'Use this to record what you learned about interacting with a site.' This implies it's for documenting insights during site interactions, but it doesn't explicitly state when to use this tool versus alternatives like cdp_site_clear (for clearing memory) or cdp_site_info (for retrieving info). The guidance is helpful but lacks explicit exclusions or comparisons.
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 the tool is for 'debugging site memory behavior', which hints at a read-only, diagnostic purpose, but doesn't specify whether it requires specific permissions, has side effects, rate limits, or what the return format looks like. This leaves significant gaps for a tool with potential complexity.
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 the core purpose in the first sentence, followed by a brief usage hint. Both sentences earn their place by providing essential information without redundancy or fluff.
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 no parameters (simplifying input) but no output schema and no annotations, the description is minimally adequate. It states what the tool does and a use case, but for a debugging tool that might return complex epoch data, more details on output format or behavioral constraints would improve completeness.
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, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, as there are none to document. A baseline of 4 is appropriate since no parameters exist, and the description doesn't attempt to explain non-existent inputs.
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 ('Get') and resource ('current epoch info'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'cdp_site_info' or 'cdp_site_scan', which might also provide debugging information about sites.
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 implied usage guidance by stating it's 'Useful for debugging site memory behavior', suggesting it should be used in debugging contexts. However, it lacks explicit when-to-use vs. alternatives, prerequisites, or exclusions compared to other debugging-related tools in the sibling list.
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 effect ('forces fresh scan next time'), which adds some behavioral context, but it doesn't disclose critical traits such as whether this operation is destructive, requires specific permissions, has side effects, or how it handles errors. For a tool that likely mutates state, this 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 a single, efficient sentence that front-loads the core action and includes essential context. Every word earns its place, with no wasted information, making it highly concise and well-structured.
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 likely involves mutation (clearing memory) and has no annotations or output schema, the description is minimal but covers the basic purpose. It lacks details on behavior, error handling, or return values, making it adequate but incomplete for safe and effective use by an AI 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?
The description adds meaning by explaining the purpose of clearing site memory and the consequence ('forces fresh scan next time'), which goes beyond the schema's description of the 'domain' parameter. With 100% schema description coverage and only one parameter, the baseline is high, and the description provides useful context without needing to detail parameters.
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 ('Clear site memory') and the target resource ('for a domain'), specifying the verb and resource. However, it doesn't explicitly differentiate from sibling tools like 'cdp_site_info' or 'cdp_site_scan', which might have related but distinct purposes, so it doesn't reach the highest score.
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 by mentioning 'forces fresh scan next time', suggesting it should be used when a fresh scan is needed, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'cdp_site_scan' or 'cdp_site_info', nor does it specify 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool writes to a file (BUGS.md), implying a mutation operation, but lacks details on permissions needed, file overwrite behavior, error handling, or response format. For a mutation tool with zero annotation coverage, this is insufficient behavioral 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 concise and front-loaded, consisting of two sentences that directly state the purpose and usage without any wasted words. Every sentence earns its place by providing essential information efficiently.
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 operation with no annotations and no output schema), the description is moderately complete. It covers the basic purpose and usage but lacks details on behavioral aspects like error handling or output format. It compensates somewhat with clear usage guidelines, but more context would be beneficial for a mutation 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?
The input schema has 100% description coverage, clearly documenting all parameters (title, description, context). The description does not add any additional meaning beyond what the schema provides, such as examples or formatting tips. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 ('Track a bug') and the resource ('in the CDP-MCP'), specifying it writes to BUGS.md in the cdp-mcp folder. It distinguishes from siblings like cdp_fix_bug or cdp_list_bugs by focusing on logging issues rather than resolving or listing them, though it could be more explicit about this differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use the tool ('when you encounter issues with browser automation'), which is clear and context-specific. However, it does not mention when not to use it or name alternatives like cdp_fix_bug for bug resolution, leaving some room for improvement in sibling differentiation.
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?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: detects Monaco instances, provides reliable get/set operations that preserve formatting, and implies it handles multiple editors (via 'editor_index'). However, it lacks details on error handling, performance, or side effects (e.g., if 'clear' destroys data irreversibly). The description doesn't contradict annotations, but it's moderately informative given the absence of structured data.
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 and key benefits. It uses three sentences efficiently, with no wasted words, though it could be slightly more structured (e.g., bullet points for operations).
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 no annotations and no output schema, the description is moderately complete for a tool with 3 parameters and 100% schema coverage. It covers the tool's domain (Monaco Editor) and key operations but lacks details on return values, error cases, or integration with sibling tools. For a mutation tool (setValue, clear) without annotations, it should ideally include more behavioral context.
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 the schema already documents all parameters (action, value, editor_index) with descriptions and enums. The description adds minimal value beyond the schema, mentioning 'detect' and 'get/set operations' but not elaborating on parameter usage or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
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: 'Interact with Monaco Editor (VS Code web editor) on the page' with specific operations (get/set that preserve formatting). It distinguishes from generic text input tools ('Much better than generic text input tools for Monaco'), though it doesn't explicitly differentiate from sibling tools like 'cdp_set_value' or 'cdp_type_text' which might have overlapping functionality.
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: for Monaco Editor instances on web pages, emphasizing it's better for preserving formatting compared to generic tools. However, it doesn't specify when NOT to use it or explicitly name alternatives among the sibling tools, such as 'cdp_set_value' for non-Monaco scenarios.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves stored memory from previous visits, which implies read-only behavior and historical data access. However, it doesn't mention potential limitations like data freshness, authentication needs, or error conditions. The description adds some behavioral context but lacks depth 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 a single, well-structured sentence that efficiently conveys the tool's purpose, parameter behavior, and return data. It front-loads the core action ('Get stored site memory') and avoids redundancy. Every part of the sentence adds value, making it concise and effective.
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 no annotations and no output schema, the description adequately covers the tool's purpose and parameter usage. However, as a data retrieval tool with potential complexity (e.g., returning iframe locations, shadow DOM elements), it could benefit from more detail on output structure or limitations. It's minimally viable but has gaps in fully contextualizing the tool's behavior.
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 1 parameter with 100% coverage, providing a clear description. The description adds value by explaining that the domain parameter is optional and defaults to the current page if not specified, which clarifies usage semantics beyond the schema's basic description. Since there's only one parameter and schema coverage is high, this extra context justifies a score above baseline.
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 resource 'stored site memory', specifying it retrieves iframe locations, shadow DOM elements, and interaction patterns. It distinguishes from siblings like cdp_site_clear (which clears) and cdp_site_list (which lists), but doesn't explicitly contrast them. The purpose is specific but lacks explicit 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'current page or a specific domain', suggesting it can be used for both contexts. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like cdp_site_list or cdp_site_scan, nor does it state any exclusions or prerequisites. Usage is contextually implied but not detailed.
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 connects to an instance but doesn't describe what happens after connection (e.g., establishes a session, enables control), potential errors (e.g., if CDP isn't enabled), or side effects. This is a significant gap for a 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, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes to understanding the tool's function.
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 (connecting to a browser instance), no annotations, and no output schema, the description is minimally adequate but lacks details on behavioral outcomes, error conditions, and what the connection enables. It should provide more context about the tool's role in the CDP workflow.
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%, with clear documentation of port, host, and tab parameters including defaults. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
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 ('Connect') and target resource ('an already-running Chrome/Chromium instance with CDP enabled'), distinguishing it from sibling tools like cdp_launch (which likely starts a new instance) and other CDP tools that perform different operations on connected instances.
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 implies usage context by specifying 'already-running Chrome/Chromium instance with CDP enabled,' indicating this tool is for connecting to pre-existing instances rather than launching new ones. However, it doesn't explicitly state when not to use it or name specific alternatives among the many 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 mentions creating a dedicated profile directory, which adds some context about isolation, but fails to address critical behavioral aspects like whether this is a long-running process, if it requires specific system permissions, potential resource consumption, or how to manage the launched browser lifecycle. For a tool that launches a browser process, this 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 extremely concise with just two sentences that are front-loaded with the core purpose. Every word earns its place, and there's no redundant information 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 complexity of launching a browser with CDP enabled (a potentially resource-intensive operation with system dependencies), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks important contextual information about what the tool returns, error conditions, or operational constraints that would be needed for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 7 parameters well-documented in the input schema. The description doesn't add any additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain relationships between parameters or provide usage examples). Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Launch a Chrome/Chromium browser with CDP enabled') and the resource ('Creates a dedicated profile directory'). It distinguishes itself from sibling tools like cdp_connect (which connects to an existing browser) by explicitly mentioning it creates a new browser instance with CDP enabled.
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 implies usage context by stating it 'creates a dedicated profile directory,' suggesting this is for launching a fresh browser instance rather than connecting to an existing one. However, it doesn't explicitly mention when NOT to use it or name specific alternatives like cdp_connect for connecting to already-running browsers.
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 prerequisite step with cdp_execute, which is useful context, but lacks details on permissions, error handling, or what happens after upload (e.g., does it trigger form submission?). For a mutation tool with zero annotation coverage, this is insufficient, though it's not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a precise usage step. Every sentence earns its place by providing essential information without redundancy, making it highly efficient and well-structured.
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 (involving shadow DOM and prerequisites), lack of annotations, and no output schema, the description is partially complete. It covers the purpose and usage steps but misses behavioral details like error cases or return values. This is adequate for basic use but leaves gaps for an AI agent to handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'file_path' fully documented in the schema as 'Absolute path to the file to upload.' The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Upload a file to a file input in shadow DOM.' It specifies the verb ('upload'), resource ('file'), and target context ('file input in shadow DOM'). However, it doesn't explicitly differentiate from sibling tools like cdp_set_value or cdp_interact, which might also handle file inputs in different contexts, so it falls short of a perfect 5.
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 usage instructions: 'First use cdp_execute to find the file input and store it in window.__fileInput, then call this tool.' This clearly states when to use it (after cdp_execute) and implies an alternative approach (using other tools for non-shadow DOM contexts), offering complete guidance.
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 full burden. It mentions listing frames but does not disclose behavioral traits such as whether this is a read-only operation, potential performance impacts, or what the output format looks like (e.g., list structure, identifiers). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 two sentences, front-loaded with the core purpose and followed by usage examples. Every sentence adds value without waste, making it highly efficient and easy to parse for an AI agent.
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 no annotations, no output schema, and low complexity (0 parameters), the description is adequate but incomplete. It explains what the tool does and when to use it, but lacks details on behavioral aspects like output format or side effects. This is minimal viable for a simple tool but could be more comprehensive.
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, and schema description coverage is 100%, so there are no parameters to document. The description does not need to add parameter semantics, but it effectively explains the tool's purpose without redundancy. Baseline for 0 parameters is 4, as it avoids unnecessary parameter details.
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 ('List all frames on the page') and resource ('main frame + iframes'), distinguishing it from siblings like cdp_list_tabs (tabs) or cdp_find_elements (elements). It provides concrete examples of use cases ('LinkedIn Easy Apply, Gmail compose'), making the purpose highly specific and actionable.
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 explicitly states 'Use this to find iframes for LinkedIn Easy Apply, Gmail compose, etc.', providing clear context for when to use the tool. However, it does not specify when not to use it or name alternatives among siblings (e.g., cdp_frame_interact might be a follow-up), missing full explicit guidance.
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?
No annotations are provided, so the description carries the full burden. It discloses the tool's purpose and context (clicking at coordinates for hard-to-select elements), but lacks details on behavioral traits such as error handling, whether it requires a specific browser state, or if it has side effects like page navigation. The description doesn't contradict annotations, but it's incomplete 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 appropriately sized and front-loaded, with the first sentence stating the core purpose. Every sentence earns its place: the second explains the use case, and the third provides practical guidance on obtaining coordinates. There is zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete. It covers purpose, usage guidelines, and parameter context well, but as a mutation tool (clicking implies action), it lacks details on behavioral aspects like permissions, side effects, or error responses. For a tool with 4 parameters and no structured safety hints, the description should do more to compensate.
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 the schema already documents all parameters (x, y, click_count, button) with descriptions and defaults. The description adds no additional parameter semantics beyond what's in the schema, but it provides context on how to obtain x and y values ('from screenshots or cdp_find_elements rect values'), which is useful but not essential given the high schema coverage.
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 ('Click at raw x,y screen coordinates') and resource (screen coordinates), and distinguishes it from siblings by explaining it's for 'elements in shadow DOM or other hard-to-select elements' where other interaction tools might fail. It provides a concrete use case that differentiates it from tools like cdp_interact or cdp_find_elements.
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 ('Useful for clicking elements in shadow DOM or other hard-to-select elements') and provides guidance on alternatives by mentioning how to get coordinates ('Get coordinates from screenshots or cdp_find_elements rect values'), which implies that cdp_find_elements might be used first to locate elements before using this tool for clicking.
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 key behaviors: clearing existing content, setting new value, and triggering events. However, it lacks details on error handling, performance implications, or what 'properly handling' entails in 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.
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 behavioral details and usage guidance. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is reasonably complete: it covers purpose, behavior, and usage context. However, it could benefit from mentioning potential side effects or error scenarios, given the complexity of interacting with web frameworks.
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 the schema already documents all parameters (selector, value, clear_first). The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Set the value of an input/textarea') and resource ('input/textarea'), distinguishing it from sibling tools like cdp_type_text or cdp_interact by specifying it handles React/Vue/Angular controlled inputs. It avoids tautology by explaining functionality beyond the name.
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 ('Best for form fields that cdp_interact type struggles with'), providing a clear alternative (cdp_interact) and context for usage. This helps the agent choose between similar tools effectively.
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 full burden and does well by disclosing key behavioral traits: it 'tries multiple submission methods' (requestSubmit(), clicking, dispatching events, direct submit()), which reveals fallback logic and implementation details. However, it doesn't mention error handling or performance implications.
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?
Perfectly front-loaded with the core purpose, followed by implementation details and usage context. Every sentence earns its place: first states what it does, then how it works, then when to use it. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description provides excellent context about behavior and usage. The only minor gap is lack of information about return values or error conditions, but given the tool's simplicity, this is acceptable.
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 the schema already fully documents the single optional parameter. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score for high coverage.
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 ('Submit a form') and distinguishes it from siblings by emphasizing reliability and special handling for modern frameworks. It goes beyond a simple verb to explain the tool's unique approach to form submission.
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 provides when-to-use guidance: 'Works when Enter key fails.' This directly tells the agent to use this tool as an alternative to standard keyboard submission methods, which is crucial for sibling differentiation in a browser automation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses the behavioral trait of simulating real keyboard input, mentions compatibility with modern frameworks, and specifies the prerequisite focus requirement. It doesn't cover error conditions or performance characteristics, but provides solid 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?
Perfectly front-loaded with the core purpose in the first sentence, followed by important behavioral context and prerequisite. Every sentence earns its place - no wasted words, no redundancy, and optimal information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 100% schema coverage, and no output schema, the description provides excellent context about when and how to use it, framework compatibility, and prerequisites. It doesn't describe return values or error cases, but given the schema completeness and clear operational guidance, it's nearly 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 100%, so the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions, but the schema itself provides complete documentation for all parameters including defaults and purposes.
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 ('Type text at the current cursor position'), the mechanism ('using CDP Input.insertText'), and distinguishes it from siblings by mentioning it works with React/Vue/Angular controlled inputs. It explicitly differentiates from cdp_set_value and other input methods.
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 guidance: 'Focus an element first with cdp_interact focus action' and implicitly distinguishes from cdp_set_value by mentioning it simulates real keyboard input for controlled inputs. The description clearly establishes the prerequisite and appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool performs a scan operation (implying read/write to memory), includes an automatic skip mechanism based on epoch, and allows forced rescans. However, it lacks details on potential side effects, error handling, or performance impacts, which would elevate it to a 5.
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 supporting details in compact clauses. Every sentence adds necessary information without waste, such as the detection scope and usage rules, making it efficient and well-structured.
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 no annotations and no output schema, the description does well by covering purpose, usage, and key behaviors. However, it lacks information on return values or error cases, which would be helpful for a tool with memory storage implications. This minor gap prevents a perfect score.
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 100% description coverage, so the baseline is 3. The description adds value by explaining the semantics of 'force' in context ('to rescan anyway') and implying 'note' is for site memory, enhancing understanding beyond the schema's technical descriptions. It doesn't fully detail parameter interactions, keeping it at 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 specific action ('Scan current page structure and store in site memory') and resource ('current page'), distinguishing it from siblings like cdp_site_info or cdp_site_list. It specifies what is detected (iframes, shadow DOM, forms, key elements), making the purpose explicit and distinct.
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 ('Automatically skips if already scanned this conversation epoch') and when to use an alternative approach ('Use force=true to rescan anyway'). It also implies context by mentioning 'compaction resets this', helping the agent decide based on epoch state.
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:

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

Score Badge

Copy to your README.md:

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

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