cdp-tools-mcp gives AI agents comprehensive Chrome DevTools Protocol capabilities across debugging, browser automation, server management, and issue tracking.
Runtime Debugging
Connect to Chrome or Node.js debuggers simultaneously via CDP
Set line, conditional, logpoint, DOM mutation, event, and XHR breakpoints
Control execution: pause, resume, step over/into/out
Inspect call stacks, variables, scopes; evaluate expressions
Search source code by regex, load source maps for TypeScript/transpiled code
Browser Automation & Interaction
Launch/manage Chrome (headless, custom ports, viewport, flags)
Navigate pages, manage multiple tabs (create, switch, close)
Interact with elements: click, type, hover, press keys, drag, scroll, pinch zoom
Take screenshots (full page, viewport, element) or export PDFs
Smart element discovery with CSS selector extensions (:has-text(), :text())
DOM & Content Inspection
Query DOM, get element properties, take full DOM snapshots
Extract page text (outline, full, section modes)
Find interactive elements (links, buttons, inputs) with filtering
Detect/dismiss modals; verify UI integrity (dead buttons, overflow, broken links)
Console & Network Monitoring
Capture, search, and filter console logs and network requests
Inspect response bodies, filter by type/method/status
Set network throttling conditions (offline, slow-3g, fast-4g, etc.)
Recording & Replay
Record mouse/keyboard/navigation interactions with a visual overlay
Replay sequences with configurable pause points and timeouts
Export recordings as Playwright (.spec.ts) or Puppeteer (.test.js) tests
Conditional branching in sequences based on selectors, URLs, cookies, or localStorage
Storage Management
Get/set/clear cookies, localStorage, and sessionStorage
Server Management
Start, stop, restart, and monitor dev servers (npm, Docker, Docker Compose, any command)
Auto-restart with exponential backoff; monitor ports for failures
Cross-session server sharing with file-based log access
Issues Tracking
Create and track bugs/features linked to recorded reproduction sequences
Work on issues with auto-replay; resolve with automated verification
Multi-Agent & Connection Management
Multiple simultaneous debugger connections (e.g., Chrome + Node.js)
Tab-level isolation for nested agents managing their own tabs
Automatic stale connection cleanup
Configuration & Utilities
Switch local/global configs, toggle individual tools on/off
Make HTTP requests from browser context (with session/cookies) or directly from the server
Web dashboard for monitoring all sessions
Debug logging toggle; kill/reset Chrome instances as needed
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cdp-tools-mcp Set a breakpoint on line 42 of app.js and inspect the user variable."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server. Your agent runs the app, sees what happened, and redoes none of it by hand.
npx devharness@latestWas
cdp-tools-mcp. That name described the transport. CDP is now one of three things this does. Migrating.
Three things burn a debugging session, and only the first is about seeing.
You are the eyes. You start the app, click the thing, paste the stack trace back into chat, reload and report whether it worked.
Everything gets re-driven by hand. Relaunch the browser, log in again, refill the form, click back to the screen where the bug lives — every iteration. Slow, and the retyped arguments drift from what actually ran.
One failure stalls the whole session. A dead dev server, a missing parameter, a wedged tool: the agent stops and waits for you.
devharness closes all three. Real execution instead of guesses. Every call it has already made is replayable by index. Failures have recovery paths the agent takes itself.
Related MCP server: Chrome DevTools MCP
24 tool modules. 802 tests across 57 files, ~7s.
See — pause real execution and read the real frame: breakpoints (line,
conditional, logpoint, DOM mutation, event, XHR), call stack and scope, source
maps so TypeScript breakpoints hit TypeScript lines. Chrome and Node.js
(node --inspect), both at once. Console, network, storage, DOM. content verify
reports dead buttons, dead links, small touch targets, and overflow clipping from
CDP facts, not heuristics.
Repeat — every tool response carries its own history index:
**Repeat:** replay({ action: 'repeat', indices: [58] })indices takes a list, so four steps re-run in one call. Whatever the agent
already did, it redoes by reference rather than by retyping. Worth keeping?
replay({ action: 'create', ... }) promotes it to a named sequence, exportable as
a Playwright or Puppeteer test.
Recover — a call that fails validation comes back with a continuationToken
and the list of what was missing; the retry sends only the missing field. A
validated call blocked by a guard is already recorded, so acknowledging the block
and replaying resumes the exact call. If the server itself wedges,
config({ action: 'restart' }) respawns it and replays the MCP handshake, so the
host session never reconnects.
Prove — dev servers run under management (npm, flask, docker, compose) with
port monitoring. Issues bind a bug to its reproduction: workOn navigates back to
the failing state, resolve replays the sequence against the fix.
A dead server blocks tools rather than warning. An agent clicking away at a
dead server produces a long, confident, entirely fictional debugging session.
Configurable: inform, error, block.
Closing an issue needs a human click. resolve waits on a browser overlay
no agent can dismiss. Recording findings is automated; declaring something
actually fixed stays a human judgement.
Repeat is on every response, not just failures. Recovery and ordinary re-running are the same mechanism, so there's nothing extra to reach for when the session gets long.
getVariables degrades, never errors. full → reduced depth → names →
counts. A truncated answer that says it truncated beats a tool error.
Connections are named. Every tool takes connectionReason, so nested agents
each drive their own tab in one Chrome without fighting over "the current page".
Text beats screenshots. extractText costs a fraction of an image and
answers most page questions. Screenshot when the question is genuinely visual.
Claude Code:
claude mcp add devharness -- npx devharness@latestClaude Desktop:
{
"mcpServers": {
"devharness": {
"command": "npx",
"args": ["-y", "devharness@latest"]
}
}
}Other clients — npx devharness@latest over stdio.
As a Claude Code plugin — this registers the server for you:
/plugin marketplace add InDate/indate-tools
/plugin install devharness@indate-toolsThe plugin pins an exact server version rather than tracking @latest, so what
you installed is what runs until you update it.
Bundled Agent Skill at plugin/skills/devharness/. Same
guidance as docs/instructions.md, split for progressive disclosure: name and
description at session start, full catalogue only when debugging starts.
mkdir -p .claude/skills
ln -s ../../node_modules/devharness/plugin/skills/devharness .claude/skills/devharnessInstalling as a Claude Code plugin does this for you.
Node service:
1. node --inspect=9229 app.js
2. connectDebugger({ reference: "api", port: 9229 })
3. breakpoint({ action: 'set', connectionReason: "api", file: "user.ts", line: 42 })
4. Trigger the request.
5. inspect({ action: 'getVariables', connectionReason: "api" })
→ real frame: what userId and userRole actually wereBrowser fix:
1. launchChrome({ reference: "app" }) # launches and connects
2. Record the five clicks that reproduce it.
3. Fix the code.
4. Replay → pass or fail, against the real appdocs/GUIDE.md for depth, docs/instructions.md for the tool reference. examples/test-app ships eight seeded bugs to exercise it against known-wrong code.
devharness <command>, run from a shell inside an editor session, executes the tool in that session's own server process - against the browser and dev servers it already has open. Only sessions rooted at the shell's directory or above it are candidates, because issues, config and sequences resolve against the answering server's root; process ancestry picks among those. Nothing needs to be passed in.
devharness which # which session this shell belongs to
devharness call config '{"action":"status"}' # any tool, arguments as one JSON object
devharness sessions # who else is reachable
devharness send a1b2c3d4 "check this" --wait=60000
devharness bug "Title" Body words here # files an issue; feature does the same--session=<id> targets a session explicitly, --json prints the unrendered response, and the exit code is 1 when the tool returns an error. Each session listens on a unix socket under ~/.devharness/endpoints/, mode 0600 - not a TCP port, because the tools reachable through it evaluate JavaScript in that session's browser.
devharness run <sequenceName> is separate: it starts its own headless Chrome and replays a saved sequence, with no session involved.
Chrome DevTools MCP is better at performance tracing, device emulation, advanced browser automation.
devharness adds breakpoint debugging with variable inspection, Node.js targets, simultaneous connections, logpoints, server lifecycle, and — the part that compounds over a long session — replayable call history and self-service recovery.
Browser-only and performance-shaped → theirs. Backend code, stepping execution, long sessions where the agent keeps re-driving the same setup → this.
cdp-tools-mcp is deprecated on npm and points here. Tools unchanged. Package,
repo, and skill renamed.
-"args": ["-y", "cdp-tools-mcp@latest"]
+"args": ["-y", "devharness@latest"]Your MCP server name (devharness, or whatever you called it) is yours and keeps
working. Renaming it is cosmetic — but tools are addressed as
mcp__<server-name>__<tool>, so update project docs if you do.
State moved .cdp-tools/ → .devharness/ in 0.9.0. Migrates itself on first
run; profiles, config, sequences, and issues carry over. DEVHARNESS_DIR
supersedes CDP_TOOLS_DIR, which still works.
git clone https://github.com/InDate/devharness.git
cd devharness
npm install && npm run build && npm testIssues and PRs welcome. Reporting a bug? Attach a recorded reproduction sequence.
MIT
Assert a condition as a sequence step. Fails the sequence (isError, executor stops) if the condition is false - use with {{var:name.path}} templates to check values captured by a prior request({saveAs}) step.
| Name | Required | Description | Default |
|---|---|---|---|
| left | No | Value to check (typically a {{var:name.path}} template, resolved before this tool runs) | |
| right | No | Value to compare against. Not used for exists/notExists. | |
| message | No | Custom failure message | |
| operator | Yes | Comparison operator |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description adequately discloses the key behavioral trait: failing the sequence if the condition is false (isError, executor stops). It does not mention side effects or authorization needs, but for a simple assertion tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that efficiently convey purpose, behavior, and usage hint without any redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and failure behavior, but does not mention return values (likely void) or what happens on success (sequence continues). Given the tool's simplicity and lack of output schema, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds valuable context by mentioning template usage for left/right and noting that right is unused for exists/notExists operators, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool asserts a condition as a sequence step, with a specific verb-resource combination. It also explains the failure behavior, distinguishing it from sibling tools like 'execution' or 'request' that serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using with {{var:name.path}} templates to check values from prior request steps, providing clear context for appropriate use. However, it does not mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage breakpoints and logpoints. Actions: set (line breakpoint), remove (remove by ID), list (list all), setLogpoint (log without pausing), validate (test expressions), resetCounter (reset logpoint counter), waitForScript (wait for script load), setDOMBreakpoint (pause when element changes), setEventBreakpoint (pause when event fires), setXHRBreakpoint (pause on network requests), await (set breakpoint and wait for hit - user can abort)
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| action | Yes | ||
| timeout | No | Timeout ms | |
| selector | No | ||
| condition | No | ||
| eventName | No | Event: click, submit, input, keydown... | |
| lineNumber | No | ||
| logMessage | No | Message with {expr} interpolation | |
| targetName | No | Filter by element type | |
| urlPattern | No | URL substring to match | |
| breakpointId | No | ||
| columnNumber | No | ||
| maxExecutions | No | ||
| connectionReason | No | ||
| includeCallStack | No | ||
| includeVariables | No | ||
| domBreakpointType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses some behavioral traits (e.g., 'await' action 'sets breakpoint and waits for hit - user can abort'), but lacks details on side effects, permissions, or whether breakpoints persist across sessions. This partial disclosure is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the core purpose and then enumerates actions in a compact format. While concise, it could be better structured (e.g., bullet points) for faster scanning. Every sentence adds value, but the list format is dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters, no output schema, and no annotations, the description covers the primary actions but omits important context like return values (e.g., for 'list' action), parameter combinations, and error handling. It is adequate for basic use but incomplete for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 29% (low), so the description is expected to compensate. It lists actions and mentions some parameters (e.g., 'lineNumber' for 'set'), but does not map all 17 parameters to actions. The description adds moderate value beyond the schema, but significant gaps remain for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Manage breakpoints and logpoints' and lists 11 specific actions, making the tool's purpose unambiguous. It effectively distinguishes this tool from sibling debugging tools like 'assert' or 'console' by focusing exclusively on breakpoint management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a list of actions but offers no guidance on when to use this tool versus alternatives (e.g., 'assert' or 'network'). There is no explicit 'when-to-use' or 'when-not-to-use' context, leaving the agent to infer usage from action descriptions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage cdp-tools configuration. Actions: status (show where config is loaded from), useLocal (switch to project-local config), useGlobal (switch to global ~/.cdp-tools config), reset (reset to defaults), backup (create timestamped backup), cloneFromGlobal (copy global config to local), show (display current settings), listTools (list all toggleable tools with their status and dependencies)
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | useLocal: explicit project dir to use as "local" (overrides server cwd) | |
| action | Yes | Config action: status (show config location info), useLocal (switch to project config), useGlobal (switch to global config), reset (reset to defaults), backup (backup current config), cloneFromGlobal (copy global to local), show (display current config), listTools (list all toggleable tools with status and dependencies) | |
| seedFromGlobal | No | For useLocal action: if true (default), seeds new local config from global if it exists |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses each action's behavior (e.g., 'switch to project-local config', 'create timestamped backup'), making agent expectations accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, and lists actions in a clear, structured manner without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration tool with 3 parameters and no output schema, the description covers all actions and their effects comprehensively, leaving no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already describes all parameters. Description adds no extra parameter details beyond what is in the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Manage cdp-tools configuration' and enumerates all specific actions, making the tool's purpose unambiguous and distinct from sibling tools which are unrelated to configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description lists all supported actions with brief explanations, giving clear context for use. However, it does not explicitly state when not to use this tool or mention 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.
Connect to debugger
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | The debugger host (default: localhost) | localhost |
| port | No | The debugger port (optional, defaults to this session's auto-assigned port). Use this to connect to debuggers on different ports (e.g., Node.js on 9229, Chrome on 9222). | |
| reference | Yes | 3 descriptive words describing this debugging activity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral disclosure. It does not mention whether the connection is persistent, idempotent, or requires prior setup (e.g., launching a debugger), leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is under-specified. It lacks structure and does not earn its place; it repeats the tool name without adding valuable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the tool's moderate complexity (3 parameters), the description is incomplete. It does not explain return values, side effects, or what happens post-connection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description 'Connect to debugger' adds no meaningful parameter semantics beyond what the schema already provides for host, port, and reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Connect to debugger' is a tautology of the tool name 'connectDebugger'. It does not specify what connecting entails or distinguish it from sibling tools like disconnectDebugger or getDebuggerStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as disconnectDebugger or listConnections. The description fails to indicate prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor and manage console messages. Actions: list, get, recent, search, clear, setObjectDepth
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Message ID (required for get) | |
| full | No | Return full message without smart truncation (default: false) | |
| type | No | Message type filter (log, error, warn, etc.) | |
| count | No | Number of recent messages (default: 50) | |
| depth | No | Object expansion depth 1-10 (default: 2) | |
| flags | No | Regex flags (default: "") | |
| limit | No | Max messages to return (default: 100 for list, 50 for search/recent) | |
| action | Yes | Console action: list, get, recent, search, clear, setObjectDepth | |
| offset | No | Messages to skip (for list action, default: 0) | |
| reason | No | Why console needs clearing (required for clear) | |
| pattern | No | Regex pattern (required for search) | |
| argsIndex | No | Specific args array index to return | |
| textLimit | No | Max characters to return from text | |
| textOffset | No | Character offset for text extraction | |
| connectionReason | Yes | Connection reference (e.g., "unnamed-connection-default" or your renamed tab) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It mentions actions like 'clear' but does not disclose that it is destructive or requires a reason (as indicated by the schema). No details on idempotency, side effects, or read-only actions are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) with no filler. It front-loads the purpose and lists actions, making it quick to parse. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, multiple actions, no output schema), the description is insufficient. It does not explain how each action behaves, when to use specific parameters, or what the return format looks like, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so baseline is 3. The description adds no additional parameter guidance beyond listing actions, which is already in the schema's 'action' enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool is for monitoring and managing console messages, and lists the specific actions available. This distinguishes it from sibling tools like 'network' or 'content', though it could be more explicit about the scope (e.g., browser console).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor are there any prerequisites or exclusions. The description only states what the tool does, not when or why an agent would choose it over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Primary tool for page content. Prefer over screenshots. Actions: extractText (extract webpage text with outline/full/section modes), findInteractive (find all interactive elements like links, buttons, inputs with summary or filtered view), verify (run CDP-based UI verification for dead buttons, viewport issues, touch targets, overflow clipping)
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Mode: outline (metadata only), full (entire page), section (specific section by heading) - for extractText action | |
| save | No | Save extracted text to disk (.cdp-tools/extracts/) - for extractText action | |
| limit | No | Max results to return (for findInteractive action, default: 50) | |
| types | No | Filter by element types (for findInteractive action) | |
| action | Yes | Content action: extractText (extract webpage text), findInteractive (find all interactive elements), verify (run UI verification checks) | |
| checks | No | UI checks to run (for verify action): handlers (dead buttons via CDP), viewport (position), touch (target size), overflow (clipping), clickability (z-index blocking - expensive), links (dead hrefs), scroll (horizontal). Default: all except clickability | |
| search | No | Search term to filter results (for extractText, findInteractive actions) | |
| section | No | Section heading (for extractText with mode=section) | |
| showHidden | No | Include hidden elements (for findInteractive action, default: false) | |
| connectionReason | Yes | Connection reference (use the reference from launchChrome output, e.g., "unnamed-connection-default" or your renamed tab) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavioral traits. The description does not mention whether the tool is read-only, any side effects, authentication needs, rate limits, or what happens to the page state. It only describes the actions' purposes, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, using two main sentences: an overall purpose statement with sibling differentiation, and a colon-separated list of actions with short clarifications. Every part adds value with no redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 10 parameters and 3 actions with no output schema, the description lacks details on return values, error conditions, or parameter requirements per action. For example, it doesn't mention that 'connectionReason' is always required or what each action outputs. This leaves agents without critical context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a strong baseline. The description adds value by grouping parameters under actions (e.g., mode/save for extractText, limit/types/showHidden for findInteractive, checks for verify), giving context beyond the schema's individual descriptions. This organization helps agents select appropriate parameters for each action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the primary tool for page content, distinguishes it from screenshots with 'Prefer over screenshots', and enumerates three distinct actions (extractText, findInteractive, verify) with concise explanations of each. This provides a specific verb-resource mapping and helps differentiate from sibling tools like 'screenshot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a general preference over screenshots but does not explicitly state when to use this tool versus other content-related siblings like 'dom' or 'inspect'. It also lacks guidance on when not to use each action or prerequisites. The brief action descriptions imply use cases but are not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage the cdp-tools web dashboard. Actions: open (get URL to open in browser), status (show whether this session is hub or client), stop (stop the hub server if this session is the hub)
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Dashboard action: open (get URL to open dashboard), status (show hub status), stop (stop the hub if this session is the hub) |
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 conditional behavior for 'stop' (only if hub session) and the effects of each action, though it could mention potential side effects of stopping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, front-loaded with purpose, and efficiently covers all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description fully explains the three actions and their effects, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single enum parameter. The description adds meaning by explaining each action value beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages a web dashboard for 'cdp-tools' and enumerates three specific actions with brief explanations, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each action (open for URL, status for hub status, stop for hub stopping) and implies usage context, but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect modals
| Name | Required | Description | Default |
|---|---|---|---|
| minZIndex | No | Min z-index to consider | |
| connectionReason | Yes | Connection reference (use the reference from launchChrome output, e.g., "unnamed-connection-default" or your renamed tab) | |
| includeBackdrops | No | Include backdrop/overlay elements | |
| minViewportCoverage | No | Min viewport coverage (0-1, default: 0.25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description omits any behavioral traits. It does not disclose whether the tool reads the DOM, modifies state, returns results, or requires specific connection setup. The agent has no insight into 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words), but this brevity sacrifices clarity and completeness. While front-loaded, it fails to convey any useful information beyond the tool name, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain the return value, the interpretation of 'detect modals', and how the parameters affect behavior. It provides none of this, leaving the tool's complete behavior ambiguous for a moderate-complexity tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with individual parameter descriptions. However, the tool description adds no extra meaning to the parameters. The baseline of 3 is appropriate as the schema already documents each field adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Detect modals' is vague. It states a verb and resource but does not clarify what detection entails (e.g., finding modals in the DOM, checking for an open modal). Without context, the agent may confuse this with inspection or sibling tool 'dismissModal'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'dismissModal' or 'inspect'. The agent receives no hints about prerequisites, expected state, or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect debugger
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Why the connection needs to be disconnected | |
| reference | Yes | 3 descriptive words of the connection to disconnect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description lacks any behavioral details. It doesn't disclose effects of disconnection (e.g., whether it terminates a session, if it's reversible, or requires permissions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (2 words) but under-specified. The sentence doesn't earn its place as it provides no information beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools and two required parameters, the description is critically incomplete. No information about return values, side effects, or when disconnection is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with clear descriptions. The tool description adds no extra meaning; baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disconnect debugger' restates the tool name without adding specificity. It implies a disconnection action but fails to differentiate from siblings like 'switchConnection' or 'connectDebugger'. No scope or resource details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., switchConnection). No context, prerequisites, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dismiss modal
| Name | Required | Description | Default |
|---|---|---|---|
| index | No | Modal index (1-based) | |
| selector | No | CSS selector of the modal to dismiss | |
| strategy | No | Dismissal strategy: accept (click accept/agree), reject (click reject/decline), close (click close/X), remove (remove from DOM), auto (smart selection based on modal type) | auto |
| retryAttempts | No | Number of retry attempts when clicking buttons | |
| connectionReason | Yes | Connection reference (use the reference from launchChrome output, e.g., "unnamed-connection-default" or your renamed tab) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Dismiss modal' without disclosing what actions it performs (e.g., click accept, close, remove), error behavior, or what happens when no modal exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two words), but it sacrifices completeness. It is not verbose, but for a tool with 5 parameters and important strategy options, more detail would be valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, required parameters, or how the tool integrates with modal detection tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no extra meaning beyond the schema. It does not clarify how parameters like index, selector, or strategy interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Dismiss modal' conveys the basic verb+resource, but it does not distinguish from siblings like 'detectModals' or provide any scope. It is adequate but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites or context. The description is entirely silent on usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect and query the DOM. Actions: querySelector (find element by CSS selector and get basic info), getProperties (get detailed properties of an element), snapshot (get full DOM structure snapshot)
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | DOM action: querySelector (find element by selector), getProperties (get detailed element properties), snapshot (get full DOM snapshot) | |
| maxDepth | No | Maximum depth for DOM snapshot (default: 5, for snapshot action) | |
| selector | No | CSS selector (required for querySelector and getProperties actions). Supports extended selectors: :has-text("text") for partial match, :text("text") for exact match. Example: button:has-text("Submit") | |
| connectionReason | Yes | Connection reference (use the reference from launchChrome output, e.g., "unnamed-connection-default" or your renamed tab) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description describes the three actions and their basic outcomes. It does not mention side effects, permissions, or performance implications (e.g., snapshot depth). The schema covers parameter details, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and well-structured, with actions listed in parentheses and clearly separated. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description gives reasonable expectations for each action's result ('basic info', 'detailed properties', 'full DOM snapshot'). Combined with the schema's param descriptions, it covers the essential usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so baseline is 3. The description adds brief context for each action but does not significantly enhance understanding beyond what the schema already provides for parameters like selector syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inspect and query the DOM' with three specific actions (querySelector, getProperties, snapshot), each briefly explained. This distinguishes the tool from sibling tools like 'inspect' or 'console' by explicitly listing its capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It only describes what it does, without mentioning when not to use it or comparing to sibling tools like 'inspect' or 'content'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control execution flow when paused at breakpoints. Actions: pause (pause execution), resume (resume execution), stepOver (step to next line), stepInto (step into function call), stepOut (step out of current function), acknowledge (acknowledge breakpoint pause to allow other tools to run while paused)
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Execution control action to perform | |
| connectionReason | No | Connection reference (use the reference from launchChrome output, e.g., "unnamed-connection-default" or your renamed tab) |
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 the behavioral effect of each action (e.g., 'acknowledge' allows other tools to run while paused). However, it does not mention potential side effects, required permissions, or error states, leaving gaps in understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a concise list of actions with brief explanations. Every sentence earns its place, no fluff, and the purpose is front-loaded. Appropriate size for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and the tool controls debugging flow, the description covers the core actions but lacks broader context. It does not explain prerequisite states (e.g., must be paused at a breakpoint) or typical usage flow, which would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema: it repeats the action enum labels with brief explanations ('pause execution') but does not provide additional meaning or examples that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool controls execution flow when paused at breakpoints, listing specific actions (pause, resume, stepOver, etc.). This distinguishes it from sibling tools like breakpoint (which handles breakpoints themselves) and connectDebugger (which sets up the connection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when paused at breakpoints but does not explicitly state when to use this tool versus alternatives like breakpoint or step. No exclusions or alternative tool names are mentioned, leaving the agent to infer context from the action list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Chrome status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as read-only, idempotency, or side effects. It offers no insight into what 'Chrome status' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is brief, it is underspecified. True conciseness balances brevity with informativeness; this description is too minimal to be effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain what 'Chrome status' includes. It provides no context, leaving the agent without critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description adds no additional meaning, but none is required. The baseline score of 4 applies as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Chrome status' is a tautology, restating the tool name without adding any specificity or differentiation from sibling tools like getDebuggerStatus or getDebugLoggingStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The agent is left to infer usage from the name alone, with no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get debugger status
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | 3 descriptive words of the connection to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only states the action without mentioning side effects, authentication needs, rate limits, or what 'status' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (6 words), but under-specified for clarity. It is not inflated, yet lacks essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a single required parameter, the description fails to explain what the returned status looks like or how the reference should be used. Incomplete for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameter description ('3 descriptive words of the connection to check'), so description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Get debugger status' clearly identifies the action and resource, but does not differentiate from sibling tools like getChromeStatus or getDebugLoggingStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With many sibling status tools, an explicit when-to-use or not is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check debug logging status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only implies a read-only operation without detailing what is returned or any side effects, leaving significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence. It is front-loaded and contains no extraneous text, but could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema, no annotations), the description is minimally adequate. However, it fails to mention what the status output looks like, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. The description adds value by clarifying the tool's purpose, meeting the baseline for no params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check debug logging status' clearly states the action (check) and the resource (debug logging status). However, it does not differentiate from sibling tools like getDebuggerStatus, which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as setDebugLogging or getDebuggerStatus. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get source code at line range
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | File URL or path | |
| endLine | No | End line number | |
| startLine | No | Start line number | |
| connectionReason | No | Connection reference (use the reference from launchChrome output, e.g., "unnamed-connection-default" or your renamed tab) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it fails to mention any side effects, authentication needs, or behavior on invalid input (e.g., missing file or bad line range). It only states a simple read operation without deeper context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of five words, containing no fluff. Every word serves a purpose, and the structure is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters and no output schema or annotations, the description fails to explain the return format (e.g., plain text, array of lines), the need for a debugger connection, or error handling. It is insufficient for an agent to use the tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description adds nothing beyond the schema; 'at line range' merely echoes the startLine/endLine parameters. Baseline 3 is appropriate as the description does not improve semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get source code at line range' clearly specifies the verb (Get), resource (source code), and scope (line range), making the tool's purpose immediately understandable and distinguishing it from siblings like 'content' or 'console'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as prerequisites (e.g., needing a debugger connection) or conditions where it should not be used. It offers no context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform browser input actions. Actions: click (click element), type (type text into element), press (press keyboard key), hover (hover over element), focus (focus element by selector), focusNext (Tab to next focusable element), focusPrevious (Shift+Tab to previous focusable element), drag (drag from one point to another), scroll (scroll wheel at position), mousemove (move mouse to position), pinch (pinch zoom gesture)
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | ||
| y | No | ||
| to | No | ||
| key | No | ||
| from | No | ||
| text | No | ||
| count | No | Tab count | |
| delay | No | Keystroke delay ms | |
| steps | No | Drag smoothness | |
| action | Yes | ||
| append | No | Append text instead of replacing (default: false) | |
| deltaX | No | Horizontal scroll px | |
| deltaY | No | Vertical scroll px | |
| selector | No | CSS selector. Supports :has-text("x"), :text("x") | |
| clickCount | No | ||
| scaleFactor | No | >1 zoom in, <1 zoom out | |
| handleModals | No | ||
| detectChanges | No | ||
| settleTimeout | No | DOM settle timeout ms | |
| dismissStrategy | No | ||
| connectionReason | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists actions but does not explain side effects, required permissions, or whether actions are synchronous. Important context like the required 'connectionReason' parameter is not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the purpose. However, the list of actions is crammed into one line; a structured list would improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 21 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain required parameters like connectionReason, optional parameters like steps or delay, or how actions interact with the browser state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 43% schema description coverage, the description should compensate. However, it adds minimal meaning beyond the schema: it lists actions but does not clarify the context of many parameters like x, y, from, to, or handleModals. The description does not help the agent understand parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs browser input actions and lists all supported actions. It is specific about the verb and resource, but does not differentiate from sibling tools, though no sibling tools seem to overlap directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites, limitations, or examples of appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect and debug code. Actions: getCallStack (get call stack when paused), getVariables (get variables in call frame), evaluateExpression (evaluate JavaScript), searchCode (search code by pattern), searchFunctions (find function definitions)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (for searchCode action default: 100, for searchFunctions default: 50) | |
| action | Yes | Inspection action: getCallStack (get call stack when paused), getVariables (get variables in call frame), evaluateExpression (evaluate JavaScript), searchCode (search code by pattern), searchFunctions (find function definitions) | |
| filter | No | Regex filter for variable names (for getVariables action) - applies to ALL scopes. Required when too many variables exist | |
| isRegex | No | Treat as regex (for searchCode action, default: true) | |
| pattern | No | Regex pattern (required for searchCode action) | |
| maxDepth | No | Max expansion depth (for getVariables and evaluateExpression actions, default: 2). Auto-reduced if response too large | |
| maxTokens | No | Max tokens for getVariables response (default: 1000). Depth auto-reduced to fit, filter required if still exceeded | |
| urlFilter | No | URL filter regex (for searchCode and searchFunctions actions) | |
| expression | No | JavaScript expression (required for evaluateExpression action) | |
| callFrameId | No | Call frame ID (required for getVariables, optional for evaluateExpression) | |
| functionName | No | Function name (required for searchFunctions action) | |
| caseSensitive | No | Case sensitive (for searchCode and searchFunctions actions, default: false) | |
| expandObjects | No | Expand objects/arrays (for getVariables and evaluateExpression actions, default: true) | |
| includeGlobal | No | Include global scope (for getVariables action, default: false) | |
| connectionReason | No | Connection reference (use the reference from launchChrome output, e.g., "unnamed-connection-default" or your renamed tab) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lists actions but does not disclose behavioral traits such as side effects, permission requirements, or limitations. The tool appears to be a grouping of multiple sub-functions, but this is implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat lengthy with a bullet-style list, but the structure is clear. Could be more concise by removing redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters and no output schema, the description fails to provide a comprehensive understanding of the tool's overall behavior. It only lists actions without explaining how they relate or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 repeats some parameter info from the schema (e.g., action enums) but does not add significant new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Inspect and debug code' with a list of actions, which gives a general purpose. However, it lacks specificity to distinguish from sibling debugging tools like 'breakpoint' or 'console'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description does not mention when not to use it or how it differs from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track and manage bugs and features. Actions: list (show all issues with optional filters), create (create new issue, optionally linking a sequence), workOn (start working on issue with auto-replay), resolve (mark as fixed/implemented), acknowledge (acknowledge pending bugs to unblock tools)
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Issue ID (for workOn, resolve actions) | |
| type | No | Issue type (required for create, optional filter for list) | |
| action | Yes | Issue action: list (list all issues), create (create new issue), workOn (start working on issue), resolve (mark as fixed/implemented), acknowledge (acknowledge pending bugs) | |
| search | No | Search term to filter issues by description or recording name (for list) | |
| status | No | Issue status (optional filter for list) | |
| startUrl | No | Starting URL for manual issue verification (required for create when no sequenceName provided) | |
| description | No | Issue description (required for create) | |
| sequenceName | No | Name of existing sequence to link (for create - moves sequence to issues folder) | |
| includeSequence | No | Include sequence recording for issue (default: true). When false, no sequence is created and Chrome does not open. | |
| keepBrowserOpen | No | Keep browser tab open after verification (default: false, closes tab after resolve) | |
| connectionReason | No | Browser connection reference (for workOn - to replay sequence) | |
| includeCompleted | No | Include fixed/implemented issues in list (default: false, only shows active issues) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description takes on the full burden. It discloses key behaviors: workOn involves auto-replay, acknowledge unblocks tools, create optionally links a sequence. However, it does not explain side effects like Chrome opening during create or verify, nor does it detail prerequisites (e.g., browser connection for workOn).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that lists actions and their purpose, front-loading the tool's capability. It avoids redundancy, though breaking into separate action lines could improve readability. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters and 5 actions, no output schema, and no annotations, the description is adequate but not complete. It lacks guidance on error handling, return values, action sequencing, and when certain parameters are required. For a complex tool, more detail would help an AI agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a clear description. The tool description adds marginal value by contextualizing actions and some parameters (e.g., 'linking a sequence' for create), but baseline is appropriate since the schema already provides detailed semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Track and manage bugs and features' and enumerates the five specific actions (list, create, workOn, resolve, acknowledge), making the tool's purpose immediately understandable. It is distinct from sibling tools that focus on debugging, browser control, or session management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description briefly explains each action (e.g., 'list (show all issues with optional filters)'), implying when to use them, but does not explicitly state when to choose this tool over siblings like replay or getDebuggerStatus. There are no exclusion criteria or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kill Chrome process
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port of specific Chrome instance to kill. If not provided, kills all Chrome instances. | |
| reason | Yes | Why Chrome needs to be killed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It only states 'Kill Chrome process' without mentioning side effects (e.g., data loss), required reason, or safety concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence and no filler. While efficient, it could be expanded slightly to include scope or usage hints without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description is incomplete. It lacks behavioral context, side effects, and interaction with other tools (e.g., launchChrome). Parameters are documented in schema, but overall guidance is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both params (port, reason). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Kill Chrome process' is a specific verb+resource combination that clearly indicates the tool's action. It distinguishes from siblings like launchChrome and getChromeStatus, though the description does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as resetChromeLauncher or getChromeStatus. There is no mention of appropriate contexts or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch Chrome with debugging
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to open (default: blank page) | |
| port | No | The debugging port (optional, defaults to this session's reserved port). Use this to launch multiple Chrome instances on different ports. | |
| width | No | Viewport width in pixels (optional). If set, the browser viewport will be resized after launch. | |
| height | No | Viewport height in pixels (optional). If set, the browser viewport will be resized after launch. | |
| headless | No | Launch in headless mode (no visible window, prevents focus stealing). Default: false | |
| reference | No | Connection reference name (3 descriptive words). If not provided, defaults to "unnamed-connection-default". Use this to identify the connection when calling other tools. | |
| chromeArgs | No | Extra Chrome command-line flags to pass through at launch, e.g. ["--use-fake-device-for-media-stream", "--use-fake-ui-for-media-stream"]. Merged after the managed defaults. The CDP_TOOLS_EXTRA_CHROME_ARGS env var (space-separated) is also always merged. Only applies when this call actually launches Chrome (ignored when an existing instance on the port is reused). | |
| autoConnect | No | Automatically connect debugger after launch | |
| forceNewInstance | No | Always spawn a fresh Chrome process on a new port instead of reusing/tabbing into an existing instance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the action without mentioning key behaviors like potential focus stealing, reuse of existing instances, or the need for specific permissions. This is insufficient for a tool that launches a browser.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It earns its place by stating the core purpose without unnecessary words, though it could benefit from slight expansion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and no output schema, the description is incomplete. It omits details about post-launch behavior, connection management, and return values. The schema covers parameters but the behavioral flow is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters well. The description adds no additional meaning beyond the schema. Baseline of 3 is appropriate as it doesn't detract but doesn't add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Launch Chrome with debugging' clearly states the verb (launch) and resource (Chrome with debugging). It is specific enough to convey the basic action, though it does not differentiate from sibling tools like connectDebugger or killChrome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., connectDebugger, killChrome). There is no mention of prerequisites, when not to use, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List debugger connections
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'List debugger connections' without disclosing what information is returned, prerequisites, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no unnecessary information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is reasonably complete. However, it could benefit from specifying what a 'connection' consists of (e.g., active, remote, etc.).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0), and schema coverage is 100%. The description adds no additional meaning but is not required to since no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('debugger connections'), clearly indicating the tool's function. It distinguishes from sibling tools that perform actions like connect, disconnect, or switch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 versus alternatives like connectDebugger or switchConnection. The usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load source maps
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | The directory containing .js.map files |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'load', which could imply reading or mutation, but does not clarify side effects, permissions, or state changes. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words), but conciseness should not sacrifice necessary detail. It is appropriately sized for a simple tool but lacks completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain what happens after loading (e.g., populates internal state, returns parsed data). It does not, leaving the agent uncertain about the tool's effect. The sibling tools imply debugging context, but the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the sole parameter 'directory', which has a clear description. The tool description adds no extra meaning, but baseline is 3 given no parameter ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'load' and resource 'source maps', but lacks specificity about what 'load' entails (e.g., parse, store, return). It does not differentiate from siblings like getSourceCode, but no direct overlap is obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description does not mention prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor and manage network requests. Actions: list (list requests with optional type filter and pagination), get (get specific request by ID), search (search requests by regex pattern), enable (enable network monitoring), disable (disable network monitoring), setConditions (set network throttling conditions)
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Request ID (required for get action) | |
| flags | No | Regex flags (for search action, default: "") | |
| limit | No | Max results to return (for list action default: 100, for search action default: 50) | |
| action | Yes | Network action: list (list network requests), get (get specific request details), search (search requests by pattern), enable (enable network monitoring), disable (disable network monitoring), setConditions (set network conditions) | |
| method | No | Filter by HTTP method (for search action) | |
| offset | No | Number of results to skip (for list action, default: 0) | |
| preset | No | Network condition preset (required for setConditions action) | |
| pattern | No | Regex pattern to search for (required for search action) | |
| statusCode | No | Filter by status code (for search action) | |
| includeBody | No | If true, saves response body to disk and returns file path (for get action, default: false) | |
| resourceType | No | Filter by resource type (for list and search actions) | |
| connectionReason | No | Connection reference (use the reference from launchChrome output, e.g., "unnamed-connection-default" or your renamed tab) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects (e.g., enabling/disabling monitoring may be destructive), required permissions, or rate limits. The description only lists actions without 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a list; it is concise but could be better structured by separating action groups. It front-loads the overall purpose but the list format is somewhat dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (12), multiple actions, and no output schema, the description covers the basic purpose and actions but lacks details on return values, error conditions, or parameter relationships. It is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to compensate. However, the description adds minimal extra meaning beyond the schema, just grouping actions and briefly restating their purposes. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool purpose as 'Monitor and manage network requests' and enumerates specific actions (list, get, search, enable, disable, setConditions), distinguishing it from sibling tools like 'request' or 'config'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists all actions but provides no guidance on when to use this tool versus alternatives or when specific actions are appropriate. The context is implied by action names but no explicit exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record and replay command sequences for testing and automation. Actions: repeat (immediately execute commands by history indices - use this to repeat recent actions), history (view command history), create (create sequence from indices), list (list in-memory sequences), get (get sequence details), delete (delete from memory), save (save sequence to disk), load (load sequence from disk), listSaved (list saved files), deleteSaved (delete saved file), run (load and execute sequence from disk in one step), step (execute next N commands in paused sequence), finish (complete remaining commands), insert (insert recorded commands into sequence), status (show active sequence status), startMouseRecording (start recording mouse events), stopMouseRecording (stop recording and get events), mouseRecordingStatus (check recording status)
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| limit | No | Max items (default:50) | |
| lines | No | Log line numbers | |
| action | Yes | ||
| format | No | ||
| global | No | Use ~/.cdp-tools/ | |
| record | No | ||
| stepTo | No | Pause after step | |
| indices | No | Command indices | |
| issueId | No | ||
| newName | No | ||
| showAll | No | Show all sequences including completed/fixed issues | |
| filename | No | ||
| startUrl | No | ||
| issueType | No | ||
| overwrite | No | ||
| startFrom | No | Start step (1-indexed) | |
| stepCount | No | Steps to run | |
| variables | No | ||
| sequenceId | No | ||
| description | No | ||
| intoHistory | No | ||
| recordingId | No | ||
| showOverlay | No | ||
| stepTimeout | No | Per-step ms | |
| outputFormat | No | ||
| totalTimeout | No | Total ms | |
| includeHovers | No | ||
| insertIndices | No | ||
| simplifyEvents | No | ||
| expectedOutcome | No | ||
| insertAfterStep | No | ||
| preferSelectors | No | Use CSS selectors | |
| connectionReason | No | ||
| issueDescription | No | ||
| preferCoordinates | No | Use x,y clicks | |
| showReplayOverlay | No | ||
| killChromeOnFinish | No | run: kill Chrome after finishing (skipped on pause/abort) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It lists actions like 'delete', 'save', 'load', implying state changes, but does not disclose repercussions such as irreversibility of delete, resource usage, or permissions required. The description provides some transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the main purpose but then becomes a long, dense paragraph listing 20+ actions with colons. It is not especially concise or well-structured; a bulleted list or grouping would improve readability. It is adequate but not optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (38 params, many sub-actions, no output schema), the description is incomplete. It covers action purposes but lacks parameter details, return value formats, error conditions, and usage constraints. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 34%, so the description should compensate. However, it does not systematically explain parameters; it only mentions a few (e.g., indices for 'repeat', lines for 'create') in the action list. Most parameters like 'startUrl', 'issueId', 'variables' are not described, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Record and replay command sequences for testing and automation' as the overall purpose. The list of sub-actions further clarifies what the tool can do, but it does not explicitly distinguish this tool from siblings like 'input' or 'navigate' which might also involve command sequences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance for individual sub-actions (e.g., 'repeat (immediately execute commands by history indices - use this to repeat recent actions)'). However, there is no guidance on when to use this tool overall versus alternative sibling tools, nor 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.
Make an HTTP request as a sequence step. destination "node" sends it from the MCP server process directly (no browser, no CORS/cookies). destination "browser" runs fetch() inside a connected tab (uses that page's cookies/session/origin).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to request | |
| body | No | Raw request body (e.g. JSON.stringify it yourself) | |
| method | No | GET | |
| saveAs | No | Sequence step only: captures {ok,status,statusText,headers,body,durationMs} into the run's variable store under this name, for later {{var:name.path}} use | |
| headers | No | Request headers | |
| timeoutMs | No | Request timeout in ms (default 30000) | |
| destination | Yes | browser: fetch inside the connected tab (shares cookies/session/origin). node: fetch directly from the MCP server process | |
| connectionReason | No | Required when destination is "browser" - which tab runs the fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behavioral differences: node uses server-side fetch (no CORS/cookies), browser uses tab's fetch (with session). However, it does not mention side effects like potential state changes from POST/PUT requests or error behavior beyond schema fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The first sentence states the core purpose, the second explains the critical destination distinction. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema or annotations, the description is minimal. It explains destinations but lacks context on sequence steps (saveAs), required connectionReason for browser, and overall how this tool fits into the sequence workflow. Moderate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 88%, so baseline is 3. The description adds semantic context for the 'destination' parameter by clarifying the runtime environment, but other parameters (url, method, headers) are adequately described in the schema already.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it makes an HTTP request as a sequence step and explains two destinations. It uses specific verbs and resources, but does not explicitly differentiate from sibling tools like 'navigate' or 'network', which have distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives guidance on when to use node vs browser destination, but lacks overall usage context (e.g., when to prefer this over 'navigate' for URL loading or 'network' for intercepting requests). No explicit 'when not to use' or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset Chrome launcher
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Why Chrome launcher needs to be reset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and the description does not disclose any behavioral traits, side effects, or prerequisites beyond the minimal action name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is too brief and under-specified, failing to earn its place by omitting essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter, the description is entirely inadequate for understanding the tool's purpose and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'reason', so baseline is 3. The description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Reset Chrome launcher' which is a verb+resource but lacks differentiation from sibling tools like killChrome or launchChrome, making it barely more than a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool vs alternatives such as killChrome or launchChrome.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download file to disk
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to download | |
| filename | Yes | Filename to save as | |
| overwriteIfExists | No | Overwrite if exists |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It fails to mention side effects such as file overwrites, disk space requirements, error handling, or confirmation prompts. The schema's parameter descriptions partially compensate but the description itself adds no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words), but lacks structure and front-loading of critical info. While brevity is good, the lack of elaboration makes it less useful for an agent, balancing to a moderate score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is too sparse to fully inform tool invocation. Missing details on return values, error cases, and disk writing behavior make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a purpose statement. The tool description adds no further parameter meaning beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Download file to disk' uses a clear verb+resource, making the tool's primary action obvious. However, it does not differentiate from potentially similar sibling tools like 'storage' or 'console', leaving some ambiguity in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, or any prerequisites like network access or write permissions. The agent receives no help in choosing this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Visual verification only. Use extractText for content. Actions: fullPage (full page screenshot), viewport (viewport screenshot), element (element screenshot), pdf (print to PDF with Chrome or WeasyPrint engines)
| Name | Required | Description | Default |
|---|---|---|---|
| clip | No | Region to capture | |
| type | No | ||
| scale | No | Page scale 0.1-2 | |
| action | Yes | ||
| engine | No | ||
| baseUrl | No | ||
| quality | No | JPEG quality 0-100 | |
| timeout | No | Timeout ms | |
| fullPage | No | ||
| selector | No | CSS selector. Supports :has-text(), :text() | |
| landscape | No | ||
| mediaType | No | ||
| saveToDisk | No | Output path | |
| stylesheets | No | ||
| paperWidthCm | No | ||
| paperHeightCm | No | ||
| optimizeImages | No | ||
| printBackground | No | ||
| connectionReason | Yes | ||
| autoSaveThreshold | No | Auto-save bytes threshold |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists actions and mentions PDF engines, but does not disclose behavioral traits such as side effects, auth requirements, rate limits, or what happens on failure (e.g., missing element, timeout). This is insufficient for a complex tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. However, it is under-specified for 20 parameters and could benefit from structured bullet points or grouping of related parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, nested objects, no output schema), the description only covers actions and PDF engines. It lacks details on return values, behavior, and parameter usage, leaving the agent with insufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 35%, so the description must compensate. It adds value by listing actions and mentioning engines, but does not explain many parameters like clip, scale, quality, selector, etc. The agent lacks sufficient understanding of how to use these parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for visual verification only, distinguishes it from extractText, and lists the specific actions available (fullPage, viewport, element, pdf). This provides a specific verb+resource and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Visual verification only. Use extractText for content,' which tells the agent when to use this tool versus alternatives. However, it does not provide further guidance on when to choose each action or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage development servers. Actions: start (start a server from npm script), stop (stop a running server), restart (restart a server), list (list running servers with status), logs (get log file paths or docker command), stopAll (stop all servers), setAutoRun (enable/disable auto-start on MCP startup)
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Server name | |
| cwd | No | ||
| env | No | ||
| port | No | ||
| action | Yes | ||
| global | No | Use ~/.cdp-tools/ | |
| runner | No | ||
| autoRun | No | ||
| command | No | Command: npm run dev, flask run, docker compose up | |
| interval | No | Check interval ms | |
| serverId | No | ||
| description | No | ||
| monitorPort | No | ||
| monitoringLevel | No |
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 core actions and their effects (e.g., 'start a server from npm script', 'get log file paths or docker command'), but omits details on side effects, permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear front-loaded purpose and an enumerated list of actions. It could be slightly more structured, but it is efficiently written without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no output schema, and no annotations, the description lacks information on return values, error handling, and the full behavior of many parameters, making it incomplete for comprehensive tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 29% (4 of 14 parameters have descriptions). The description does not explain the meaning or usage of undocumented parameters like cwd, env, port, runner, or monitorPort, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Manage development servers' and enumerates all actions (start, stop, restart, etc.), making the purpose specific and distinct from sibling tools which are Chrome DevTools-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for server management tasks by listing actions, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it contrast with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle debug logging
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | Set to true to enable debug logging, false to disable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Toggle debug logging' without disclosing effects, permissions, or state changes beyond the toggle action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. Appropriate length for a simple toggle operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle, the description is minimal. It lacks explanation of return behavior, side effects, or how to verify the change (e.g., using getDebugLoggingStatus).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description adds no extra meaning, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Toggle debug logging' clearly states the verb and resource. It is not a tautology, but it does not distinguish from sibling tools like getDebugLoggingStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Access and manage browser storage (cookies, localStorage, sessionStorage). Actions: getCookies (get cookies), setCookie (set cookie), getLocalStorage (get localStorage), setLocalStorage (set localStorage), clear (clear storage)
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | localStorage key (optional for getLocalStorage, required for setLocalStorage) | |
| url | No | URL to get cookies for (optional for getCookies action) | |
| name | No | Cookie name (required for setCookie action) | |
| path | No | Cookie path (optional for setCookie action) | |
| types | No | Storage types to clear (for clear action, default: all) | |
| value | No | Cookie/storage value (required for setCookie and setLocalStorage actions) | |
| action | Yes | Storage action: getCookies (get cookies), setCookie (set cookie), getLocalStorage (get localStorage), setLocalStorage (set localStorage), clear (clear storage) | |
| domain | No | Cookie domain (optional for setCookie action) | |
| reason | No | Why storage needs to be cleared (required for clear action) | |
| secure | No | Secure cookie (optional for setCookie action, default: false) | |
| expires | No | Cookie expiration timestamp (optional for setCookie action) | |
| httpOnly | No | HTTP only cookie (optional for setCookie action, default: false) | |
| connectionReason | No | Connection reference (use the reference from launchChrome output, e.g., "unnamed-connection-default" or your renamed tab) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It mentions 'Access and manage', implying both read and write, but fails to disclose that 'clear' is destructive and requires a reason. No mention of permissions, rate limits, or side effects beyond the action names. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a parenthetical list. It is concise but slightly repetitive (e.g., 'getCookies (get cookies)'). Still efficient for a multi-action tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters and 5 actions, the description omits critical information like return values, side effects of each action, and usage context (e.g., when to use 'clear' vs individual actions). No output schema exists, so the description should compensate, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it only repeats the action enum values with parenthetical explanations. No additional context about parameter interdependencies or formatting is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Access and manage browser storage' and lists the specific actions. However, it does not differentiate from sibling tools like 'network' or 'console' beyond the obvious domain, and the actions are listed but not described in a way that highlights their distinct purposes. The verb 'manage' is somewhat broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool over siblings, nor does it offer guidance on selecting among the five actions. The agent must rely solely on parameter enums and names, which is insufficient for effective decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch debugger connection
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | 3 descriptive words of the connection to switch to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits such as side effects on the current connection, persistence, or required state. The agent cannot infer safety or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise but at the expense of necessary detail. It is not verbose but lacks structure and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too brief. It does not explain return values, preconditions, or the effect of the switch, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter 'reference' is described as '3 descriptive words of the connection to switch to'. The description adds no additional meaning, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch debugger connection' clearly indicates the action and resource, but lacks differentiation from siblings like connectDebugger and listConnections. It is vague about what 'switch' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it doesn't mention that listConnections should be used first to get available connections, or that connectDebugger is for new connections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage browser tabs. Actions: list (show all open tabs), create (open new tab with reference), rename (change tab reference), switch (switch active tab), close (close a tab)
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to (for create action) | |
| action | Yes | Tab action: list (list all tabs), create (create new tab), rename (rename tab reference), switch (switch to tab), close (close tab) | |
| reference | No | Tab reference (3 descriptive words) - required for create/rename/switch/close actions | |
| newReference | No | New reference for tab (3 descriptive words) - required for rename action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions actions but does not disclose side effects (e.g., what happens to existing tabs on creating new ones), error conditions (e.g., invalid reference), or required permissions. The description is too brief to fully inform the agent about 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence with a concise list of actions. It is front-loaded with the main purpose and uses minimal words. While effective, it could be slightly more structured (e.g., separate lines) but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the actions but lacks details on return values, error handling, and prerequisites. For a tool with 4 parameters and multiple actions (list, create, rename, switch, close), it is moderately complete but leaves gaps about expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is documented in the schema. The description adds minimal extra value: it reiterates the action enum and notes that reference is '3 descriptive words', which is also in the schema. Baseline 3 is appropriate; no significant enhancement over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Manage browser tabs' and enumerates five specific actions (list, create, rename, switch, close) with brief explanations. This provides a clear verb+resource pairing and differentiates from sibling tools like 'navigate' or 'content' by focusing on tab management, though not explicitly distinguishing from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists actions but provides no guidance on when to use this tool versus alternatives (e.g., 'navigate' for navigation, 'content' for DOM interaction). It does not specify prerequisites (e.g., must have browser connected) or when not to use certain actions. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.12assertbreakpointconfigconnectDebuggerconsolecontentdashboarddetectModalsdisconnectDebuggerdismissModaldomexecutiongetChromeStatusgetDebuggerStatusgetDebugLoggingStatusgetSourceCodeinputinspectissueskillChromelaunchChromelistConnectionsloadSourceMapsnavigatenetworkreplayrequestresetChromeLaunchersaveToDiskscreenshotserversetDebugLoggingstorageswitchConnectiontabEach tool has a clearly distinct domain and action set. Despite many tools, there is little to no overlap: e.g., breakpoint vs execution, content vs screenshot, navigate vs tab are all well-differentiated.
All tool names consistently use camelCase with verb + noun pattern. Sub-actions are also consistently named (e.g., set, remove, list). No mixing of conventions.
35 tools is on the higher side but appropriate for the comprehensive scope covering debugging, navigation, input, network, storage, breakpoints, and server management. Some granularity (e.g., multiple status tools) could be consolidated, but overall reasonable.
The tool surface covers major browser automation and debugging workflows: navigation, DOM interaction, input, network, console, storage, breakpoints, execution control, screenshots, and logging. Minor gaps like performance profiling or mobile emulation exist but core operations are well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Autonomous cloud agent tasks: real browser + your tools, structured evidence-backed results.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/InDate/devharness'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
