cdp-bridge

Server Quality Checklist

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

Latest release: v0.1.21
Disambiguation4/5
Tools have largely distinct purposes, but some overlap exists between browser_switch_tab and browser_focus_tab, and between browser_execute_js and browser_batch. The descriptions help disambiguate, so no major confusion.
Naming Consistency4/5
All tools share the 'browser_' prefix, which is good. The verb part mostly follows verb_noun pattern (e.g., focus_tab, get_tabs), but browser_screenshot and browser_batch break that pattern slightly. Overall consistent.
Tool Count5/5
With 10 tools, the server is well-scoped for browser automation. Each tool serves a clear purpose, and the count is neither too few (which would feel incomplete) nor too many (which would be overwhelming).
Completeness4/5
The tools cover core browser operations: navigation, tab management, screenshots, JS execution, and DOM scanning. Missing explicit form filling or network interception, but the batch tool allows arbitrary CDP commands, so agents can fill gaps. Minor but not significant.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 8 of 9 community issues answered or closed in the last 6 months
- 25 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 provided, so description must describe behaviors. It does not mention whether it waits for page load, handles errors (e.g., invalid URL), or any side effects on the active tab. The description is minimal.
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 one sentence with a clear imperative. It is appropriately front-loaded but could be slightly more detailed without becoming verbose.
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 and an output schema existing, the description does not explain return values (e.g., page title) or post-navigation state. For a straightforward navigation, it minimally suffices but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage; the description merely restates 'The URL to navigate to.' for the url parameter, adding no additional meaning or constraints (e.g., format, protocol, relative vs absolute).
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: 'Navigate the active tab to a URL.' It distinguishes from sibling tools like browser_switch_tab (which switches tabs without navigation) and browser_execute_js (which runs JavaScript).
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 guidelines on when to use this tool versus alternatives like browser_batch or browser_scan. No mention of prerequisites (e.g., page must be interactive) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals behavioral traits like DOM change monitoring and CDP support, but lacks details on security, error handling, or state modifications. Since no annotations are present, the description carries full burden and provides moderate value.
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 short and well-structured with a clear one-line summary followed by bulleted arguments. Every sentence adds value 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?
Given the tool's complexity and the existence of an output schema, the description covers core functionality (execution, result capture, DOM monitoring) but omits constraints (page load requirement) and security considerations, leaving room for improvement.
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?
With 0% schema description coverage, the description partially compensates by explaining the script parameter (JavaScript or CDP JSON), switch_tab_id, and no_monitor flags. However, details like tab ID format or CDP command syntax are missing.
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 executes JavaScript in the browser and captures results and DOM changes. This distinguishes it from sibling tools like browser_navigate or browser_screenshot which perform different actions.
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 (e.g., browser_batch for multiple actions). No when-not-to-use instructions.
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 reveals that the HTML is stripped of scripts, styles, and invisible elements, and that the tool returns a tab list. This adds value beyond the schema but does not mention error handling, permission needs, or whether the tool modifies state (it appears read-only but not confirmed).
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, with a single sentence for the main purpose and a list of arguments. It front-loads the key information. However, the argument list is in a paragraph style; a structured format (e.g., bullet points) would enhance readability without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavior and output (simplified HTML plus tab list) and mentions the LLM optimization. The presence of an output schema reduces the need to detail return values, but the description is missing edge cases (e.g., behavior when no tabs exist) and does not explicitly state whether the tool is read-only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, placing the full burden on the description. The description explains all three parameters ('tabs_only', 'text_only', 'switch_tab_id') with their effects and usage intent. For example, it notes 'tabs_only' saves tokens and 'switch_tab_id' switches tab before scanning. This is strong compensation, though additional details like data types or constraints would improve it.
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 gets simplified HTML content of the active tab plus tab list. The verb 'Get' and resource 'simplified HTML content' are specific. However, it does not explicitly distinguish from sibling tool 'browser_get_tabs', which also deals with tabs. The mention of tab list indicates overlap, but the focus on scanned content differentiates it.
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 guidance via the 'tabs_only' argument, implying when to skip page content to save tokens, but lacks explicit when-to-use versus alternatives like 'browser_get_tabs' or 'browser_navigate'. No exclusion criteria or preconditions are stated.
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?
Discloses polling behavior with timeout and interval, and truthiness test. But doesn't state what happens on timeout (likely throws error) or if condition has side effects. No annotations provided, so description carries full burden but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with clear bullet points for parameters. First sentence directly states purpose. Minor informality with 'Args:' but overall efficient and 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?
Covers purpose and parameters but lacks return value description. Output schema exists but description doesn't integrate it. Missing edge cases like timeout behavior. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning: condition_js is a 'JavaScript expression or script' with truthiness check, timeout is 'Maximum seconds to wait', interval is 'Seconds between checks', switch_tab_id is 'Optional tab ID to make active before waiting.' Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Wait until JavaScript condition returns a truthy value.' This is a specific verb+resource and distinguishes from siblings like browser_execute_js which executes JS without waiting.
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 explicit guidance on when to use this tool vs alternatives. Does not mention when-not to use or suggest sibling tools for different scenarios. Only mentions optional tab switch.
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 full burden for behavioral disclosure. It mentions returns base64 PNG, but omits details like full-page vs viewport capture, size limits, or required permissions.
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 two sentences, no redundancy, and the purpose is 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 simple tool and the existence of an output schema, the description covers basic semantics but lacks crucial behavioral details (e.g., scroll handling, timeouts) that an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; the tool description compensates by explaining the tab_id parameter: 'Optional tab ID to screenshot. Uses active tab if empty.' This adds meaningful context 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 the action ('Take a screenshot') and the resource ('active tab', optionally any tab). It distinguishes from siblings like browser_save_image and browser_scan by focusing on screenshot capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing screenshots but provides no guidance on when to use this tool versus alternatives like browser_save_image or browser_batch, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses inheritance of tab_id and timeout behavior, but does not mention error handling, execution order, or atomicity. This is adequate but not thorough for a complex batch operation.
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 reasonably concise, with the main purpose in the first sentence. The argument list is clear but slightly verbose. It is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, it does not need to explain return values. It covers batching, inheritance, and timeout. However, missing details on error propagation and whether commands execute sequentially or in parallel slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does: explains commands with an example, clarifies tab_id inheritance, and defines timeout. This adds significant meaning beyond the raw 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 states 'Run multiple extension/CDP commands in one request', which is a specific verb and resource. It clearly distinguishes from sibling tools like browser_navigate or browser_screenshot, which are single-purpose actions.
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 use for batching multiple commands but does not explicitly state when to use it versus alternatives, nor does it mention conditions for avoiding it. Some guidance is inferred from the sibling list, but lacks explicit when-not or prerequisites.
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 clearly indicates a read operation that returns tab metadata. It does not detail edge cases (e.g., empty tab list) or performance implications, but the behavior is straightforward.
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 of 10 words, front-loading the key action and result. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is almost complete. It specifies the return content but does not mention that the result is an array or what happens when no tabs are open. Minor improvement could be made, but overall adequate.
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 fully covered. The description adds value by explaining what the output contains (IDs, URLs, titles), which is not part of the input schema. Baseline is 4 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 uses a specific verb ('Get') and resource ('all open browser tabs') and lists the returned fields (IDs, URLs, titles). It clearly distinguishes from sibling tools like browser_switch_tab or browser_navigate, which operate on individual tabs rather than listing them.
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 an agent needs a list of all open tabs, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions or prerequisites.
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 must carry the behavioral burden. It explicitly states that the Chrome tab is not changed, which is a key behavioral trait. However, it does not mention error handling or side effects for invalid tab_id.
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 plus an Args section, with no wasted words. It is front-loaded with the core purpose and efficiently provides parameter guidance.
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 simplicity (1 param), no annotations, and an output schema, the description covers the main behavior and parameter origin. It could mention failure modes or constraints, but overall it is complete enough.
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% description coverage, so the description must add meaning. It explains that tab_id comes from browser_get_tabs, which adds context beyond the schema. Could be more specific about format but 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 it switches the active MCP browser tab without changing the visible Chrome tab. This is a specific verb+resource and distinguishes from sibling tools like browser_focus_tab.
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 tells where to get tab_id (from browser_get_tabs) but does not explicitly guide when to use or avoid this tool compared to alternatives like browser_focus_tab. Usage context is implied but not clearly stated.
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?
No annotations provided, so description bears full burden. It comprehensively details output_path behavior (directory, file, error conditions) and return value structure (status, saved_path, size_bytes). Every aspect of the tool's behavior is disclosed.
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 longer but well-structured with bullet points for output_path behavior. Every sentence adds value; however, minor redundancy (e.g., 'Args:' formatting) could be trimmed. Still efficient for the amount of detail.
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 2 parameters, one required, and presence of output schema (implied by 'Returns:'), the description fully covers input handling, output behavior, and return values. No gaps in information for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with empty parameter descriptions. The description adds full semantic meaning: screenshot_json_str_or_file is JSON from browser_screenshot or file path; output_path behavior with three cases. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save base64 screenshot data to PNG file.' It specifies the verb (save), resource (screenshot data), and output format (PNG). It distinguishes from siblings like browser_screenshot which captures the screenshot, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions that input comes from browser_screenshot tool, and details the behavior of output_path. While it doesn't name alternative tools, the context shows it's the complementary save tool, and no sibling has overlapping functionality.
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?
No annotations provided, but description fully discloses behavior: it goes through chrome.tabs.update + chrome.windows.update, avoids CDP restriction, activates tab and focuses window. All relevant behavioral traits are explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: first line states purpose, then contrast with sibling, use case, implementation details, and parameter explanation. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (1 param), has output schema, and description covers purpose, usage, behavioral details, and parameter source. Includes sibling differentiation and reasoning for implementation. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has single parameter tab_id with no description, but tool description adds: 'The tab ID to focus (from browser_get_tabs).' This provides source context beyond the schema, though minimal. Score slightly below 5 due to brevity.
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 the tool's action: 'Bring a Chrome tab to the foreground: activate the tab AND focus its window.' It also explicitly distinguishes from sibling tool browser_switch_tab by explaining what this tool does differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Unlike browser_switch_tab... this actually makes the tab visible to the user. Use this when the user can't find the tab the agent is working on.' Clearly states when to use and contrasts with alternative.
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-bridge-mcp MCP server](https://glama.ai/mcp/servers/Unagi-cq/cdp-bridge-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Unagi-cq/cdp-bridge-mcp)

Score Badge

Copy to your README.md:

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

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