mcp-chromium-cdp

by duquesnay

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: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with intentional separation between selector-based and semantic alternatives (e.g., chrome_click vs chrome_click_text, chrome_type vs chrome_type_text). Descriptions explicitly note when to prefer which tool, reducing ambiguity.
Naming Consistency5/5
All tools follow a consistent chrome_ prefix with verb_noun (or verb_preposition) structure, e.g., chrome_navigate, chrome_get_title, chrome_click_text, chrome_wait_for. The naming pattern is uniform and predictable.
Tool Count4/5
At 25 tools, the set is on the heavier side but each tool serves a specific browser automation need, including advanced features like SPA detection and form extraction. The count is justified for a comprehensive CDP-based server, though it could be streamlined slightly.
Completeness4/5
The toolset covers the core browser automation lifecycle: navigation, interaction, content extraction, tab management, waiting, scrolling, and state checks. Minor gaps exist (e.g., no cookie management or file upload), but the included tools enable effective automation for most scenarios.
Average 3.9/5 across 25 of 25 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It does not mention whether existing text is replaced or appended, whether the element must be visible, or how the text is dispatched. This leaves key 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?
One concise, front-loaded sentence with no filler. All words contribute to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Core functionality is clear for a simple two-parameter tool, but the ambiguity with chrome_type_text and lack of behavioral details prevent the description from being fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully with descriptions. The tool description adds only 'input field' context, which is marginally useful but doesn't provide additional semantics beyond the schema's 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Type text') and target ('input field') with a CSS selector, clearly identifying what it does. However, the sibling tool chrome_type_text likely performs a similar action, and the description does not distinguish between them.
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 instead of chrome_type_text or other typing/clicking tools. The description gives no context about prerequisites, timing, or alternatives.
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, and the description carries the full burden. It does not disclose behavioral details such as whether the page must be loaded, how hidden elements are treated, or the return format. It only states what is retrieved, not any requirements or side effects.
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 concise sentence that efficiently conveys the tool's function. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description is minimally adequate. However, it lacks edge-case handling and does not clarify how it differs from similar tools like chrome_get_content. A note about return value or usage preference 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 zero parameters, and the schema confirms this with 100% coverage. The description adds no parameter details because none exist, but the zero-parameter baseline is 4, and no further explanation is needed.
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 ('Get') and the resource ('visible text content of the current page'), making the tool's purpose specific. It partially distinguishes from sibling chrome_get_content through the 'visible' qualifier, but does not explicitly name it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like chrome_get_content or chrome_execute_script. The description lacks any context for selection, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the action without revealing whether it waits for page load, replaces the current tab, or any side effects. The description adds no behavioral context beyond the tool name, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, 'Navigate to a specific URL in Chrome', with no unnecessary words. It is front-loaded and directly states the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description omits important context such as whether it navigates the current tab or opens a new one, and does not differentiate it from sibling navigation tools. The lack of an output schema or annotations leaves gaps in understanding the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter 'url' having a description already. The tool description adds no further meaning about the parameter, so the baseline score of 3 is appropriate.
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 action: navigate to a specific URL in Chrome. It uses a specific verb and resource, but does not differentiate from sibling navigation tools like chrome_open_new_tab or chrome_go_forward, so it loses a point.
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 when the user needs to go to a URL, but provides no explicit guidance on when to use this tool versus alternatives like opening a new tab or using back/forward navigation. The lack of exclusions or alternative mentions keeps it at an implied level.
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 responsibility for behavioral disclosure. It does not specify whether the new tab becomes active, whether the URL is loaded asynchronously, what happens with invalid URLs, or what the return value indicates. The description is minimal and lacks these details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loads the core action. However, it repeats information already present in the schema ('optionally with a URL'). It is concise, but not exceptionally informative beyond the schema.
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 simplicity (one optional parameter, no output schema), the description adequately covers the basic purpose. However, it leaves open questions about return values, tab focus behavior, and error handling. It is minimally viable but not complete for an agent that might need behavioral details.
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 already provides 100% coverage with the parameter description 'Optional URL to open in the new tab'. The tool description merely restates this as 'optionally with a URL', adding no extra semantic detail. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Open a new tab in Chrome') and resource (Chrome tabs). It distinguishes from siblings like chrome_navigate (navigate existing tab) and chrome_close_tab (close tab) by specifying 'new tab'. Very clear and specific.
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 does not provide guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It simply states what the tool does. No mention of when to choose this over chrome_navigate or how it fits into a broader workflow.
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, the description carries the full burden of behavioral disclosure. It does not mention that closing a tab is irreversible, potentially loses unsaved state, or what happens if it's the last tab. This lack of side-effect disclosure is a significant gap for a destructive action.
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 concise sentence with no unnecessary words. It is perfectly sized for the simplicity of the action and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple browser action with no parameters and no output schema, the description is adequate to convey the basic function. However, it lacks any context about when to use it or its behavioral impact, making it incomplete for an agent that needs to decide if this is the right tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object. The description adds meaning by specifying the target as the 'current tab,' which is implicit but helpful. Per the rubric baseline of 4 for zero parameters, this is appropriate.
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 'Close the current tab' clearly states the action (close) and the resource (current tab), distinguishing it from sibling tools like chrome_navigate or chrome_open_new_tab. It is specific and unambiguous.
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, nor does it mention any prerequisites or consequences. For example, it doesn't clarify how closing the current tab affects the browser window or the tab 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not mention what happens when there is no forward history, whether any side effects occur, or what the tool returns. 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, concise sentence that exactly captures the core action. Every word earns its place; there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple, but the description lacks important context such as behavior when forward history is empty, return values, or error conditions. No output schema or annotations exist to compensate. It is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds nothing about parameters, but none are needed. This is appropriate.
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 'Go forward in browser history' clearly states the action (go forward) and the resource (browser history). It is specific and distinguishable from sibling tools like chrome_go_back and chrome_reload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is typically used after a back navigation, nor does it reference sibling tools like chrome_go_back.
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?
The description relies solely on the verb 'reload' to imply behavior. It does not disclose side effects such as losing unsaved form data, re-fetching resources, or waiting for page load. With no annotations, the burden falls on the description, and it provides minimal 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 a single, front-loaded sentence that conveys the essential information without any wasted words. It is appropriately sized for a simple action with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters or output schema, the description is minimally adequate but leaves gaps. It does not explain when to use it, what side effects might occur, or how it behaves relative to navigation tools, which is important given the large set of siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The input schema is empty and fully covered, matching the baseline of 4 for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reload the current page' clearly states the action (reload) and the resource (current page), and 'reload' is distinct from sibling tools like navigate, go_back, and go_forward. It unambiguously identifies the tool's purpose.
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. It does not mention, for example, that it should be used to refresh a stale page rather than navigating away, nor does it reference sibling tools like chrome_navigate or chrome_check_page.
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 alone carries the burden of behavioral disclosure. It only states the action, not any behavioral traits such as whether it waits for page load, what happens if no title exists, or whether it returns a string or null. This is a minimal disclosure.
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, precise sentence that states everything necessary without any fluff. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a parameterless getter, the description is reasonably complete. It tells the agent exactly what the tool does. However, it does not describe the return format (e.g., a string) or edge cases like missing titles, but this is minor for such a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The baseline for zero parameters is 4, and the description does not need to explain any parameter semantics. The description adds sufficient meaning for a parameterless getter.
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 action ('Get') and the specific resource ('the title of the current page'), which distinguishes it from sibling tools like chrome_get_current_url and chrome_get_content. The purpose is immediately obvious and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. For example, it does not mention that this tool is ideal for retrieving the page title specifically, nor does it contrast with chrome_get_current_url or chrome_get_visible_text. The usage is implied by the name, but there is no explicit contextual 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action without mentioning what happens if there is no history, whether it waits for page load, or how it affects the current tab. This leaves significant behavioral ambiguity.
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 exceptionally concise, consisting of a single, direct sentence with no wasted words. It is front-loaded and immediately comprehensible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (zero parameters, no output schema), the description is mostly complete for a simple browser back action. However, it does not address edge cases like empty history or navigation behavior, though these are relatively minor gaps for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description does not need to elaborate on parameters since there are none, and it correctly omits any parameter-related information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Go back in browser history' uses a specific verb and resource, clearly indicating the action of navigating backward through the browser's history. It distinguishes itself from the sibling tool chrome_go_forward by explicitly stating the backward direction.
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 chrome_navigate or chrome_reload, nor does it mention any preconditions or exclusions. The only contextual cue is the tool name itself, which is insufficient for clear 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 must carry the full burden of behavioral disclosure. It only states the function without addressing side effects, read-only status, handling of empty tab lists, or any other operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. No unnecessary words or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no inputs, the description is mostly adequate, specifying the key output fields (titles and URLs). However, it does not describe the return structure (e.g., array of objects) or any edge-case behavior, which could be clarified given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters (schema is an empty object), so there are no parameter details to explain. The description confirms no input is needed, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the target (all open tabs), and the expected output (titles and URLs). This differentiates it from sibling tools that focus on a single tab or navigation actions, such as chrome_get_current_url or chrome_open_new_tab.
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 chrome_* tools, there is no mention of use cases, scenarios, or exclusions, leaving the decision entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not mention whether the operation is read-only, whether it waits for page load, or what the return format is beyond 'HTML content'. This is a minimal description with no added 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 a single, front-loaded sentence that conveys the full purpose without any wasted words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's minimal complexity (0 parameters, no output schema), the description adequately states the core functionality. However, it could go slightly further to specify that the HTML is returned as a string, but this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully covers all inputs. The baseline score of 4 for 0-param tools applies; there is no parameter information to add.
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 action ('Get'), the resource ('HTML content'), and the scope ('current page'). This distinguishes it from sibling tools like get_visible_text (text-only) and get_title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use when you need the raw HTML of the current page. However, it provides no explicit guidance on when to use this tool instead of alternatives like get_visible_text or get_current_url, nor any 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. While it mentions execution and returning a result, it does not disclose potential side effects (e.g., page navigation, DOM changes, security implications) or limitations like async handling. The 'ADVANCED' and 'last resort' labels hint at risk but do not elaborate on behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently concise: two sentences, front-loaded with the core function followed by usage guidance. Every sentence earns its place, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, it covers the basic purpose and usage. However, it omits important context for an advanced tool: what exactly is returned (e.g., serialized JSON, promise resolution), how errors are handled, and whether the script runs in page context. The lack of an output schema makes these gaps more significant, leaving the agent uncertain about invocation outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single 'script' parameter, and the description adds no extra meaning beyond what the schema already conveys. The baseline of 3 applies because the schema does the heavy lifting; the description simply restates 'JavaScript code to execute' without adding specifics like expected patterns or return behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute JavaScript in the current page and return the result.' It uses a specific verb and resource, and the second sentence differentiates it from sibling structured tools by positioning it as a last resort, which distinguishes it from the other chrome_* tools.
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 guidance: 'Use as last resort when chrome_click, chrome_type, or other structured tools cannot accomplish the task. Prefer semantic tools for better reliability.' This clearly states when to use and when not to use, and names alternatives.
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 burden. It indicates a read-only operation (get) and the object (active tab), but does not disclose return format, error handling, or edge cases. For a simple getter, this is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action and clearly specifies the target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully covers the operation. The tool's simplicity means no additional context is needed, and the URL is a well-known type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4; the description need not explain any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current URL of the active tab. It uses a specific verb (Get) and resource (current URL), and the scope (active tab) distinguishes it from siblings like chrome_get_title and chrome_get_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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or relate to sibling tools, leaving the agent to infer usage from the name and function.
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, the description must carry the transparency burden. It discloses automatic resizing and returns base64 PNG with metadata, but does not specify viewport vs full-page capture, page load requirements, or what metadata includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with clear front-loading of the primary action, followed by key behaviors and output format. Every clause contributes information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-param tool, the description covers the core purpose, resizing behavior, and output format. However, it leaves ambiguous whether the screenshot is full-page or viewport, and metadata content is unspecified. No output schema exists, so these gaps are notable but not critical for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents maxDimension (optional, default 2000px for Claude API compatibility). The description's 'automatic resizing to fit API limits' adds context connecting the parameter to the tool's behavior, so it adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Take a screenshot of the current page' – a specific verb and resource. It also mentions automatic resizing and output format, which distinguishes it from sibling tools, none of which are screenshot tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (capturing a visual of the current page) and mentions API limit compatibility, but does not explicitly discuss when to use it versus content extraction tools like chrome_get_content or chrome_get_visible_text, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries responsibility for behavioral disclosure. It discloses the SPA-related synthetic event handling via ensureInteractive, which is valuable, but it omits what happens on missing selectors, waits, or navigation side effects. This is acceptable for a simple click tool but leaves some ambiguity.
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 concise sentences, front-loaded with the core action, and includes the key optional behavior in a clear conditional. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple click tool with two well-documented parameters and no output schema, the description plus schema cover the essential behavior. It could mention error handling or return values, but the low complexity does not demand it.
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 already provides full descriptions for both parameters (selector and ensureInteractive). The description adds a brief mention of React SPAs but does not meaningfully expand beyond the schema's own explanation of the hover-focus-wait-click sequence.
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 action ('Click') and the targeting method ('CSS selector'), which distinguishes it from sibling tools like chrome_click_text that use text-based targeting. The verb+resource structure is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance to use ensureInteractive for React SPAs, which is a context-specific usage instruction. However, it does not explicitly mention when to prefer this tool over chrome_click_text or other sibling click tools, so a small gap remains.
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, the description carries the behavioral disclosure burden. It discloses that hover activates synthetic event handlers in React SPAs, providing useful context. However, it does not mention potential side effects, error handling, or whether the action is synchronous, leaving some gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the core action, the second provides usage context. No fluff or redundancy, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, no output schema), the description covers the essential purpose and usage scenario. It could improve by noting error behavior or return value, but for a hover action, the provided context is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter 'selector' is fully described as 'CSS selector for the element to hover.' The description repeats 'CSS selector' without adding extra syntax, constraints, or examples, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Hover over an element using a CSS selector' with a specific verb and resource. It also distinguishes the tool from chrome_click by explaining when hover should precede click, which aligns with its role among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: 'Essential for React SPAs where hover activates synthetic event handlers' and 'Use before chrome_click when dealing with dropdowns, tooltips, or interactive elements that require hover state.' This provides clear context and directly references an alternative tool (chrome_click).
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. It discloses what the tool returns (scroll position, boundary detection, dimensions) and mentions behavioral options (instant/smooth). However, it omits potential failure cases (e.g., invalid selector) and does not mention side effects or limitations.
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 then listing specifics. Every sentence provides value, with no filler or repetition.
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?
The description, combined with the schema, gives a fairly complete picture: what it does, key parameters, expected outputs, and use cases. Minor gaps include not explicitly noting that 'distance' is required for up/down (though the schema states this) and not covering edge cases like selector not found.
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% coverage with descriptions for all four parameters. The tool description mentions the parameters but does not add new semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.
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 specifies the action ('Scroll the page or a specific element') with the verb and resource. It lists supported capabilities (direction, distance, element targeting, behavior), and no sibling tool performs scrolling, so it naturally distinguishes itself.
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 mentions use cases: 'Useful for infinite scroll detection and pagination.' This gives clear context for when to use it, but it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5.
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, the description carries the full burden of disclosing behavior. It states that the tool is read-only ('Extract'), lists the returned data, and highlights support for specific form types and filled/empty detection. It lacks details on error handling or behavior with no forms, but for a read-only extraction tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding distinct value: purpose, return payload, and supported contexts. No fluff, front-loaded with the primary verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is complete: it explains what is returned, mentions compatibility across form types, and flags filled/empty state. No critical gaps remain for typical 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 covers 100% of the single parameter (formSelector), explaining its optional nature and default behavior. The tool description itself does not add parameter-specific details, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Extract structured form data without custom scripting.' It specifies the exact resource (forms) and the return payload (fields, submit buttons, fieldsets). This differentiates it from sibling tools like chrome_extract_interactive and chrome_execute_script.
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 phrase 'without custom scripting' signals an alternative to scripting tools, and the mention of standard forms, React forms, and Shadow DOM forms gives context for when it applies. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of the highest bar.
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, description carries full burden; it discloses performance expectation (<500ms), absence of screenshot, and the specific state fields returned. This is meaningful behavioral detail for a read-only health-check, though it does not describe failure behavior or whether the check waits for page load completion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences: first states purpose and key differentiator, second lists return fields and performance guarantee. Every word earns its place with no redundancy or filler.
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?
Despite no output schema, the description lists all expected return values, which is sufficient for a simple health-check tool. It omits potential nuances like whether the page must be fully loaded or how 'visible errors' are determined, but the overall context is clear for autonomous agents.
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?
Tool has zero parameters, and schema coverage is trivially 100%; description correctly implies no inputs are needed. Baseline for zero-parameter tools is 4, and no additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs a quick page state check without screenshot, and enumerates specific return data (URL, title, load state, visible errors, form count, interactive elements count). This distinguishes it from sibling tools like chrome_screenshot, chrome_get_current_url, and chrome_get_title by combining state signals into a fast health-check.
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?
Explicitly frames usage as a fast health-check for autonomous agents and notes it is without screenshot, giving clear context. It does not name alternative tools or state when not to use, but the positioning against screenshot-based checks is evident.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool detects frameworks and returns names and versions, and implies a read-only diagnostic action. It could mention detection limitations or method, but for a simple detection tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, main action first. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers its purpose, output, and usage context. It doesn't detail return data structure, but without an output schema, the general description of 'framework names and versions' is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description correctly avoids adding unnecessary parameter information. Baseline for 0 params is 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 verb 'Detect' and the resource 'SPA frameworks on the page', lists specific frameworks (React, Vue, Angular, Svelte), and notes that it returns names and versions. This distinguishes it from sibling tools like chrome_execute_script or chrome_extract_interactive.
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 suggests using this tool to determine if the 'ensureInteractive' pattern is needed for clicks, providing a clear context. It does not mention alternatives or when not to use it, but the context is specific enough.
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, the description carries the burden of behavioral disclosure. It discloses a key behavioral trait: 'Limited to 100 elements for performance.' It also details the output structure (text, role, selector, visibility, enabled status). It does not mention potential side effects, but the tool appears read-only, and the disclosed limit adds significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences. The first sentence states the action, the second lists the output details, and the third gives the primary use case. Every sentence adds value with no redundancy or fluff, making it well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), but the description adequately covers its purpose, output fields, limitations, and usage context. It could be slightly more explicit about edge cases (e.g., behavior when no interactive elements exist), but for its complexity, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The input schema is empty, and the description adds no parameter-specific information, which is appropriate given there is nothing to explain. The description focuses on output and usage, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Extract all interactive elements with their text and metadata.' It specifies the exact element types (buttons, links, inputs) and metadata fields returned, distinguishing it from sibling tools like chrome_extract_forms by its broader scope and explicit use case in relation to click/type tools.
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 explicit usage guidance: 'Use this to discover available interactions before calling chrome_click_text or chrome_type_text.' This clearly indicates when to use the tool, though it does not explicitly mention when not to use it or name alternative tools, so it falls slightly short of a 5.
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?
No annotations are provided, so the description carries the full burden. It discloses the safe, non-injection approach (CDP APIs) and a critical constraint (property name must be alphanumeric + underscore/hyphen only). This adds meaningful behavioral context, though it does not cover potential errors or return type nuances.
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 three concise sentences, each adding essential information: the core operation, the safe CDP mechanism, and the explicit usage guideline. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter getter tool with full schema coverage, the description provides enough context for an agent to select and invoke it correctly. It could be slightly more complete by stating what value format is returned or how missing properties are handled, but given the tool's low complexity, the description is reasonably sufficient.
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 already describes both parameters (selector as CSS selector, property as name to retrieve). The description adds the same property-name restriction already present in the schema, so it offers little additional semantic value. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get a property value from an element. It distinguishes itself from siblings by explicitly mentioning 'without script injection' and pointing to chrome_execute_script as the alternative to avoid, making the tool's unique role obvious.
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?
Usage guidance is explicit: 'Use this instead of chrome_execute_script for reading element properties.' This directly tells the agent when to select this tool over a sibling and scopes it to reading element properties, which is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden and discloses the label search order (label 'for' attribute, parent label, aria-label, placeholder) and error behavior (returns actionable error with suggestions). This gives useful behavioral context beyond the basic operation.
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: the first states the primary function and key feature, the second adds search order and error handling. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter tool and no output schema, the description provides sufficient context: purpose, usage preference, search algorithm, and error handling. It could mention whether typing replaces existing text or waits for element, but for this scope it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters fully (100% coverage). The description adds value by detailing the search order for the label parameter, which is not fully captured in the schema. This goes beyond the baseline 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 tool types text into an input field identified by its label, and explicitly frames it as a semantic alternative to chrome_type. This distinguishes it from sibling tools like chrome_type and chrome_execute_script.
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 gives explicit guidance to prefer this over chrome_execute_script for form filling, and indicates it is a semantic alternative to chrome_type. It does not explicitly state when not to use it, but the context of labeling suggests a clear use case.
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, the description carries the transparency burden. It discloses key behavioral traits: XPath contains() matching, optional ARIA role filtering, and error handling for 0 or >1 matches. It doesn't mention possible side effects of clicking, but for a click tool the action is explicit enough.
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 three sentences, front-loaded with the core purpose. The subsequent sentences add method details, error behavior, and usage preference without redundancy. Every sentence earns its place, and the structure is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, this description covers purpose, method, optional filtering, error handling, and usage guidance. It is complete enough for an agent to select and invoke the tool correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that text matching uses XPath contains() (clarifying substring vs exact match) and that the text is visible. It also ties the 'role' parameter to ARIA filtering. This goes beyond the schema's basic definitions.
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 opens with a specific action and target: 'Click an element by its visible text content.' It distinguishes itself from related tools by calling itself a 'semantic alternative to chrome_click' and clearly contrasts with chrome_execute_script. This fully clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Prefer this over chrome_execute_script for clicking buttons/links.' It also implies its use case as a semantic alternative to chrome_click. However, it doesn't enumerate situations where this tool should not be used or when an alternative would be better, so it's not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description carries full burden. It discloses return format (success status, conditions met, actual state, time elapsed), timeout behavior (returns current state instead of error), and chaining capability, providing valuable behavioral context beyond what annotations would offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct purpose: purpose, return behavior, timeout/chaining. No unnecessary wording, and the most important information (purpose) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters all documented in schema and no output schema, the description compensates by explaining return values and timeout behavior. It covers the key aspects: what it does, what it returns, and how it behaves on timeout, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with detailed parameter descriptions, so baseline is 3. Description adds the chaining concept, indicating multiple conditions can be combined, and clarifies that the tool returns which conditions were met—modest but useful addition beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Wait for UI state changes after actions' with a clear verb and resource. It distinguishes from sibling chrome_* tools by focusing on waiting for conditions rather than navigation or interaction.
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?
Description states contextual use 'after actions' and notes 'Can chain multiple conditions,' giving user guidance on when to use. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for typical workflows.
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:

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

Score Badge

Copy to your README.md:

[![mcp-chromium-cdp MCP server](https://glama.ai/mcp/servers/duquesnay/mcp-chromium-cdp/badges/score.svg)](https://glama.ai/mcp/servers/duquesnay/mcp-chromium-cdp)

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/duquesnay/mcp-chromium-cdp'

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