Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the behavioral disclosure burden. It only states the basic action and does not mention side effects, waiting behavior, error conditions, whether radios can be unchecked, or what the tool returns. This is minimal for a state-changing operation.

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, front-loaded sentence with no fluff or repetition. Every word contributes to the core 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?

With no output schema and no annotations, the description is too thin for full context. It omits handling of radio buttons, return values, error cases, and integration with the session lifecycle, which are relevant 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 low (33%), but the description adds some meaning by linking the 'checked' parameter to the check/uncheck action and clarifying the target element type. However, it does not explain selector format or other parameter details 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 action ('Check or uncheck') and specific target ('checkbox / radio'), using a specific verb and resource that distinguishes it from sibling tools like cdp_click or cdp_select. Even without naming alternatives, the purpose is unambiguous.

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 cdp_click, cdp_select, or other navigation actions. It does not state prerequisites (e.g., element must be a checkbox/radio) or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It does disclose support for right/middle click, double-click, and modifier keys, adding value beyond the schema. However, it omits important behavioral traits such as whether the click triggers navigation, requirements like element visibility, or what happens on failure. The force parameter is also not explained in either the schema or description.

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 front-loaded with the primary purpose and directly enumerates variants. Every word earns its place, with no redundancy or fluff.

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 8 parameters, no annotations, and no output schema, the description provides a solid overview but leaves gaps: it does not mention the force parameter, mutual exclusivity of selector vs coordinates, prerequisites like an active session, or potential side effects. It is adequate for basic usage but incomplete for edge cases.

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 25%, with descriptions for session_id and click_count. The description compensates by explaining the semantics of selector, x, y, button, modifiers, and double-click (via click_count). It does not explain the force parameter, but overall it adds significant meaning beyond the sparse 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 clicks an element by CSS selector or at page coordinates, and lists supported variants (right/middle click, double-click, modifier keys). It distinguishes from sibling tools like cdp_hover or cdp_type by focusing specifically on click actions.

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 when to use the tool: whenever a click is needed. It explains the two usage modes (selector or coordinates) and available options, but does not explicitly exclude cases or compare to alternatives like cdp_press for keyboard events. This is clear context but lacks explicit exclusions or alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing side effects. It states the session is disconnected and dropped from the session list, providing useful context. However, it omits details about whether the browser is closed, idempotency, or the implications of using the session after closing.

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, front-loaded sentence that efficiently conveys the main action and effect without any 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?

For a simple one-parameter close operation with no output schema, the description adequately covers the core behavior. It clearly explains what happens to the session, though it does not mention return values or error handling, which is acceptable for this level of simplicity.

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 already documents the sole parameter 'session_id' with the description 'Session id returned by cdp_connect', which fully covers its meaning. The tool description adds no additional parameter information, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Disconnect' and identifies the resource as 'this session', clearly distinguishing it from sibling tools like cdp_connect or cdp_list_sessions. It also details the effect of removing the session from the session list, further clarifying its purpose.

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 is provided on when to use this tool versus alternatives. The description implies it is for closing an existing session, but it does not state when to call it (e.g., after completing work) or contrast it with cdp_connect or cdp_list_sessions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior. It mentions the critical non-launching behavior, the capture_dir side effect (starting to save requests with no count limit), and the return of session_id. It does not detail failure modes or network interaction specifics, but the most important behavioral traits are disclosed.

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 three sentences, front-loaded with the primary purpose. Each sentence adds value: the core action, URL format, capture behavior, and return value. No redundant words or filler.

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 connection tool with 5 parameters and no output schema, the description adequately explains the main flow: connect, optionally capture, and receive a session_id for later tools. It does not elaborate on error handling or the exact mechanics of the capture filters, but the schema covers those details. The description is sufficient for an agent to understand the tool's role.

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, providing a baseline of 3. The tool description adds meaningful context by explaining that cdp_url accepts HTTP or WebSocket formats and that capture_dir triggers continuous JSON saving with no count limit. This extra guidance elevates the score above 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?

The description clearly states the tool's function: attaching to an already-running Chromium browser via CDP, explicitly noting it does not launch a browser. It distinguishes from siblings by focusing on connection/setup rather than navigation or DOM actions, and specifies the return value (session_id).

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 clear context: use when a browser is already running and needs to be controlled via CDP. It explicitly excludes launching a browser, providing a 'when not to use' cue. However, it does not name alternative tools for launching or other connection methods, so it stops short of full comparative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses an important behavior: 'Large documents are truncated.' Since no annotations are provided, the description carries the transparency burden. However, it does not mention return format, error behavior, or explicitly confirm that the operation is read-only, leaving 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 two short sentences with no wasted words. The core purpose is front-loaded, making it easy to scan.

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 output schema, the description should clarify what exactly is returned and any constraints. It only warns about truncation and omits error cases, the effect of max_chars, and prerequisites like an existing session (though session_id is in the schema). It feels minimal for a 3-parameter tool.

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 low (33%), and the description compensates partially: 'innerHTML of a selector' explains the selector parameter, and 'Large documents are truncated' relates to max_chars. It does not explicitly link max_chars to the truncation limit or explain other 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 action ('Get') and the resource ('page HTML, or innerHTML of a selector'). It is specific enough to distinguish from siblings like cdp_screenshot or cdp_page_info, but does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use this tool when you need page HTML or a selector's innerHTML. It does not explicitly mention when not to use it or name alternative tools, but the usage context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility for behavioral disclosure. It discloses the core action (evaluating JS) and the return behavior, but omits side effects, error handling for non-serializable results, async behavior, and security implications of executing arbitrary code in the page.

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, front-loaded sentence with no wasted words. It efficiently conveys the essential purpose and return behavior.

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 that executes arbitrary JavaScript, the description is under-specified. It lacks information about side effects, return value limitations, error conditions, and usage context. No output schema or annotations exist to compensate, making the description inadequate for safe and 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 coverage is 50%; the expression parameter lacks a schema description. The tool description clarifies that 'expression' is JavaScript code, but does not add detail about evaluation context, async handling, or result serialization. The session_id parameter is adequately described in 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 runs a JavaScript expression in the page and returns the JSON-serializable result. This specific verb+resource combination distinguishes it from sibling tools like cdp_click or cdp_type, which perform DOM interactions rather than arbitrary JS evaluation.

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, no exclusions, and no mention of prerequisites beyond the parameters. The usage context is only implied by the tool's purpose, not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. The verb 'Read' implies a non-destructive operation, and 'Optional url limits the set' clarifies filtering behavior. However, it does not disclose session requirements, return format, or what happens when no cookie matches.

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 short sentences with no padding. The key action and optional parameter behavior are front-loaded, making it easy to scan.

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 2-parameter getter, the description is adequate: it explains what is retrieved and the optional filter. Missing details like exact return format or error behavior are not critical for a read-only operation, though they would improve 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?

The schema already describes session_id as 'Session id returned by cdp_connect'. The description adds meaning to the undocumented url parameter by explaining that it 'limits the set', effectively covering both parameters' 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 verb 'Read' and the resource 'cookies', specifying that it reads from the browser context. It also distinguishes the tool from its sibling cdp_set_cookies by focusing on reading rather than writing.

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 is provided on when to use this tool versus alternatives. It does not mention cdp_set_cookies or any other sibling, nor does it state any exclusions or preconditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only restates the action without revealing side effects, error conditions, whether it waits for page load, or what happens if history is empty. This adds no information beyond the tool 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 description is a single short sentence, so it is concise and not padded. However, it is underspecified and does not fully 'earn its place' because it conveys minimal added value beyond the tool name. It could benefit from a few more details without becoming verbose.

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 annotations and output schema, the description is too incomplete. It does not mention the need for a connected session, the effect on the current page, or any behavioral constraints. For a navigation tool, this is insufficient for an agent to use it reliably.

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 one parameter, session_id, with a description that covers 100% of the schema. The tool description itself adds no extra parameter meaning, so the baseline of 3 applies because the schema already documents the parameter 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 'Go back in history' clearly states the action and resource: it navigates backward in the browser session history. This distinguishes it from siblings like cdp_navigate (go to a specific URL) and cdp_reload (reload current page), though it does not explicitly name those alternatives.

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?

There is no guidance on when to use this tool versus alternatives. The description only states the action without indicating prerequisites (e.g., active session) or exclusions (e.g., when at the earliest history entry). No use-case context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 states the basic action ('hover') without mentioning whether the element needs to be visible, whether hover events are triggered, any side effects, or failure behavior. This minimal information does not adequately disclose the tool's runtime 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 a single, concise sentence that states exactly what the tool does with no filler or redundancy. It is front-loaded with the core action and target, making it easy to parse.

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 is adequate for a simple hover action, but it lacks context about return values, error conditions, or prerequisite states (e.g., element presence). Given the absence of annotations and output schema, it only minimally fulfills the completeness requirement, leaving the agent without full operational 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 description clarifies the 'selector' parameter by specifying it is a CSS selector, which is not otherwise described in the schema. Since schema coverage is 50% (session_id is described), the description adds meaningful value for the otherwise undocumented parameter, though it does not elaborate on session_id 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 uses a specific verb ('Hover') and a specific resource ('an element matched by CSS selector'), clearly distinguishing it from sibling tools like cdp_click or cdp_mouse_move. It precisely states the action and target in a single concise sentence.

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 about when to use this tool versus alternatives such as cdp_mouse_move or cdp_click. The description neither states explicit usage context nor mentions any exclusions, leaving the agent without information on tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It clarifies the scope ('all active CDP sessions in this MCP process') but does not mention whether the operation is read-only, what the return format is, or any side effects. The verb 'list' implies a safe read, but richer context would improve 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 sentence that is front-loaded and contains only essential information. Every word earns its place, with no redundant phrasing.

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, parameterless list tool, the description provides adequate context about what is listed and the scope. It doesn't describe the return value, but no output schema exists and the operation is straightforward. Sibling tools and the name reinforce its purpose.

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 takes zero parameters, so the schema is complete (100% description coverage). The description adds no parameter details, but with no parameters there is nothing to explain; the baseline for 0 params is 4.

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 action ('List') and the resource ('all active CDP sessions') with a specific scope ('in this MCP process'). This distinguishes it from sibling tools which perform actions on sessions (e.g., connect, navigate) rather than listing them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The purpose is implied: it is used to see which CDP sessions are currently active. However, there is no explicit guidance on when to use this tool versus alternatives, such as after connecting or before performing session-specific operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility. It only states the basic action and that no click occurs, but provides no details about coordinate system, whether events are fired, browser prerequisites, or handling of invalid coordinates. This is a significant gap for a user-action simulation 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 one short sentence that directly conveys the purpose. It is front-loaded with the action ('Move the mouse') and wraps up the key constraint ('without clicking'). 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?

For a simple action, the description is adequate yet leaves out important details such as coordinate reference system, behavior on invalid coordinates, and whether a page must be loaded. Since there is no output schema, the description should have provided at least minimal context 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 description coverage is only 33% (only session_id has a description). The description adds the term 'page coordinates' to clarify x and y, but does not explain units, origin, or whether coordinates are relative to viewport or page. This partial compensation is helpful but not fully sufficient.

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 action: move the mouse to page coordinates without clicking. It uses a specific verb (move) and resource (mouse), and the phrase 'without clicking' distinguishes it from sibling tools like cdp_click and cdp_hover.

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 when to use the tool (when you want to move the mouse without triggering a click) but does not explicitly name alternatives or exclusions. Siblings like cdp_click and cdp_hover are not mentioned, so the guidance is mostly implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility for disclosing behavior. It fails to mention critical aspects such as the wait_until parameter's effect, whether navigation blocks until completion, or any side effects. The single sentence is too terse for a navigation 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?

The description is a single, front-loaded sentence that conveys the core action without waste. Every word earns its place.

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 tool has 3 parameters, no annotations, and no output schema, yet the description remains minimal. It does not explain what happens after navigation (e.g., return behavior, wait states), which leaves the agent without important execution 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?

Schema description coverage is only 33% (only session_id is described). The description adds no meaning for the url or wait_until parameters, and it does not compensate for the under-documented schema. No parameter semantics are provided beyond what the schema fields themselves imply.

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 ('Navigate') and resource ('session's current page to a URL'), making the action unmistakable. It clearly distinguishes itself from siblings like cdp_reload and cdp_go_back, which handle different navigation actions.

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 given about when to use this tool versus alternatives like cdp_reload or cdp_go_back. The description simply states what it does without providing context for choosing between similar navigation-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior. It mentions that the tool lists requests already saved on disk, defaults to the last 50 summaries, and that include_body/include_headers are used to read the JSON files. This adds meaningful behavioral context beyond the schema, though it doesn't disclose error cases or explicitly state read-only nature.

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 two sentences long, front-loaded with the main purpose, and every sentence provides essential information: what the tool does, the default behavior, how to access full content, and the capture prerequisite. There is no unnecessary verbosity.

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 8 parameters, no annotations, and no output schema, the description is incomplete. It fails to explain the filter parameters (method, status, url_contains, resource_type) and does not describe the return format. The description provides some context about default behavior and prerequisites but leaves significant gaps for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 13%, and the description only adds meaning for include_body/include_headers and the default limit. The parameters method, status, url_contains, and resource_type are left completely unexplained in both the schema and the description, so the description does not compensate for the low 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 starts with 'List requests already saved on disk,' which is a specific verb+resource combination that clearly states what the tool does. It also distinguishes this tool from siblings like cdp_network_start and cdp_network_stop by focusing on reading already-saved data rather than capturing it.

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 clear context for when to use the tool by stating 'Capture must have a dir (from cdp_connect capture_dir or cdp_network_start),' implying that this tool is used after a capture has been set up. It also gives guidance on using include_body/include_headers to read JSON files, but it does not explicitly name alternative tools or list when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It details output behavior (JSON file plus requests.jsonl), session scoping, and no count limit, adding meaningful context beyond the schema. Does not mention error handling or performance impact.

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?

Three short sentences, each adding value: what the tool does, where output goes, no count limit, and when to call it. Purpose is front-loaded with no superfluous 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 start command, this covers the core aspects: purpose, output destination, session scoping, and ordering. It lacks explicit description of return value and prerequisites, but given the simplicity of a start operation and the absence of an output schema, it is nearly 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 covers only 40% of parameters; the description partially compensates by clarifying 'dir' as the destination and 'matching request' implying filter parameters. However, method, url_contains, and resource_type are not elaborated, relying on the agent to infer their meaning from names.

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?

Starts with the action verb 'Start network capture for this session,' clearly identifying the tool's function. Distinguishes from siblings like cdp_network_stop and cdp_network_log by focusing on initiating capture and specifying file output.

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?

Provides explicit timing guidance ('Call before navigating if you need the first document request'), indicating when to invoke relative to navigation. Lacks explicit alternatives or when-not-to-use conditions, so not a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. The note 'Files already written to dir are kept' adds useful behavioral context, but it doesn't disclose other traits like whether the capture session is ended or if logs remain accessible.

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 short sentences, both earning their place. The action is front-loaded and the side-effect note is relevant. 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?

For a simple stop tool with one parameter and no output schema, the description covers the essential action and a key side-effect. Context is adequate; missing details like session handling are minor for this simplicity.

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 session_id well-described as returned by cdp_connect. The description adds no parameter-specific info, but the schema already provides full 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 stops capturing, with a specific verb and resource. It distinguishes from siblings like cdp_network_start and cdp_network_log, though it doesn't explicitly name 'network' in the description.

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 the tool, prerequisites, or alternatives. It doesn't mention that cdp_network_start should be called first or that cdp_network_log can retrieve results after stopping.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It states the tool 'returns' information, implying a read-only operation, but does not explicitly mention session requirements, potential errors, or the absence of side effects. This is minimal but not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler words. Every word contributes to specifying the tool's purpose, making it appropriately concise for such a simple 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 simple read-only tool with one parameter and no output schema, the description covers the essential return values. However, it does not specify the exact structure or format of the returned data, which is a minor gap given the tool's simplicity.

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 single parameter session_id is fully described in the schema with a reference to cdp_connect, achieving 100% schema description coverage. The description adds no additional parameter semantics, so the baseline of 3 applies.

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 the specific verb 'Return' and names the resources 'current page URL, title, and frame URLs', making the tool's function unmistakable. This clearly differentiates it from siblings like cdp_content or cdp_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 implies use when current page metadata is needed, but provides no explicit guidance on when to use this tool versus alternatives such as cdp_content or cdp_evaluate. There is no mention of exclusions or prerequisites beyond the session_id parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavioral traits. It discloses the core action and the focusing behavior, but it does not mention potential side effects of shortcut presses, error conditions, or absence of return values. This is adequate but lacks deeper 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, front-loaded sentence with useful examples and no redundant words. Every element earns its place, making it highly 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?

For a simple input action tool with no output schema, the description covers purpose, key format examples, and the optional selector behavior. It could mention error handling or that a session must be active, but overall it is sufficiently complete for an agent to invoke 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 low (33%), but the description compensates by explaining 'key' with examples and 'selector' with its focusing effect. Session_id is already described in the schema. Thus, the description adds meaningful semantic value 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?

Description uses a specific verb ('Press') and resource ('key or shortcut') with concrete examples (Enter, Control+A), making the purpose unmistakable. It clearly differentiates from sibling tools like cdp_type (text input) and cdp_click (mouse click).

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 through examples (e.g., shortcuts like Control+A) and the optional selector focusing behavior, but it does not explicitly state when to prefer cdp_press over alternatives like cdp_type or cdp_click, nor does it mention any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 only states the action. It does not explain side effects such as page reload from network, reset of DOM state, interaction with wait_until, or prerequisites like an active session or loaded page.

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?

A single short sentence, 'Reload the current page,' is maximally concise and front-loaded. Every word earns its place; there is no redundancy or irrelevant content.

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 a required session_id, an optional wait_until with four enum values, no output schema, and no annotations, a five-word description is inadequate. It lacks context about prerequisites (session/page), the meaning of wait_until, and expected behavior after invocation, making the description too thin to fully guide correct use.

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 description provides no information about the session_id or wait_until parameters. Schema coverage is 50% (wait_until has only an enum, no description). The description fails to compensate by explaining what the wait_until values mean or how they affect execution.

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 'Reload the current page' uses a specific verb ('reload') and a clear resource ('current page'), making the tool's purpose unambiguous. It naturally differentiates from sibling tools like cdp_navigate or cdp_go_back by focusing on refreshing the existing page.

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 you want to refresh the current page) but offers no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or contrast with sibling navigation tools, leaving the agent to infer the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must convey behavioral traits. It discloses that the output is 'image content' and that it captures the 'current page,' implying a read-only snapshot. However, it does not explicitly state that it does not modify the page, nor does it mention any side effects, session requirements, or limitations (e.g., only viewport by default). The description adds some value but could be more transparent.

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, clear sentence that immediately conveys the core function. It is front-loaded with the action and resource, and contains no filler or redundant information. Every word earns its place.

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 tool is simple, but the description lacks important contextual information. It does not explain the full_page parameter's effect, nor does it mention the need for a valid session_id (though the schema covers that). There is no output schema, but the description does state the return format ('image content'). Given the low complexity, the description is mostly sufficient but has clear gaps around parameters and session prerequisites.

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 50%: session_id is described in the schema, but full_page is not. The tool description does not mention either parameter, so it adds no meaning beyond the schema. Full_page's behavior (full-page vs. viewport-only capture) is left unexplained, and the description does not clarify how the parameters relate to the tool's function.

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 function: 'Capture the current page as a PNG screenshot (returned as image content).' This uses a specific verb ('capture'), identifies the resource ('current page'), and specifies the output format ('PNG screenshot'). It is distinct from sibling tools like cdp_navigate or cdp_click, which perform different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., an active session from cdp_connect), conditions for use, or situations where another tool (such as cdp_content for DOM text) would be more appropriate. The usage context is only implied by the tool's name and basic function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry full behavioral disclosure. It mentions the three modes but does not state side effects, return values, or behavior when conflicting parameters (e.g., selector and x/y) are provided together.

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, front-loaded sentence with no redundancy, efficiently communicating all three scrolling capabilities.

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 6 parameters, three modes, no output schema, and no annotations, the description is too sparse. It lacks parameter combination rules, return value, and edge-case behavior, which are essential for correct autonomous 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 descriptions only cover x/y and session_id (50% coverage). The description adds meaning by linking selector to element scroll and delta_x/delta_y to wheel scrolling, but it doesn't clarify parameter relationships, defaults, or precedence among modes.

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 with a specific verb ('scroll') and enumerates three distinct modes: element scroll, wheel delta, and coordinate jump. This distinguishes 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 provides clear context on when to use the tool: for scrolling by element, delta, or coordinates. It doesn't explicitly mention alternatives, but the scenarios themselves guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It adds the selection mechanism ('by value, label, or index') but omits important side effects such as whether it triggers change events, handles multi-select, waits for page updates, or errors when no matching option is found. This is not enough for an agent to predict runtime 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 a single concise sentence that leads with the verb and object, immediately stating the tool's purpose. It contains no redundant wording or filler, making it optimally scannable.

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 six parameters, no annotations, and no output schema, the description should provide more operational context. It does not mention return values, error conditions, prerequisites like an active session (beyond the session_id parameter), or the effect of selecting options on the page state. This leaves the agent under-informed for a tool with moderate complexity.

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 17%, so the description must compensate. It clarifies the roles of value, label, and index, but does not explain the 'selector' syntax (e.g., CSS selector) or the 'values' array for multiple selection. This leaves significant gaps for the agent to choose and set 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's function with a specific verb ('Choose'), a targeted resource ('<select> element'), and the selection criteria (value, label, or index). This distinguishes it from sibling tools like cdp_click or cdp_type.

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 when to use the tool by mentioning '<select> element', but it does not explicitly contrast with alternatives or state exclusions. For example, it does not mention that cdp_evaluate could be used for more complex DOM manipulations or when to prefer cdp_click.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the burden. It reveals that cookies are written to the browser context of the session, but does not explain whether existing cookies are overwritten, whether the operation is destructive to other cookies, or what happens if the session is invalid. These behavioral details are critical for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with no wasted words. It is concise and front-loaded, though it sacrifices informational depth; still, it earns its place as a brief overview.

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 no output schema and no annotations, the description is too sparse to be contextually complete. It lacks behavioral expectations (e.g., overwrite semantics, session requirements) and does not explain the cookie object structure, leaving significant gaps for the 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?

Schema coverage is only 50% (only session_id has a description; the cookies array's nested fields are undocumented). The description adds no meaning beyond the schema, failing to compensate for the missing parameter explanations, such as the role of path, secure, or httpOnly in the cookie objects.

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 the specific verb 'Write' and clearly identifies the resource ('cookies onto the browser context of this session'). This distinguishes it from sibling cdp_get_cookies, which reads cookies, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention that a session must be active (via cdp_connect) or that it should be used instead of cdp_get_cookies for writing. Usage is only implied by the tool name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does a good job: it discloses the behavioral difference between modes (fill replaces value, type fires real key events, insert is paste-like), and clarifies that without a selector it targets the focused element. It doesn't mention the deprecated 'clear' field or error behaviors, but core behaviors are well covered.

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?

Three short sentences, all substantive. The first sentence states the action, the second explains selector usage, and the third clarifies modes. No filler or redundant restatement, and it's front-loaded with the primary 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?

For a 7-parameter tool with no output schema, the description covers the main usage scenarios and mode semantics. It doesn't describe what happens on selector miss or explain the 'clear' deprecation, but those are partially addressed in the schema. The core functionality is well explained, and the tool is simple enough that this is adequate.

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 description adds plain-language meaning to the mode parameter ('replace value', 'real key events', 'paste-like') and explains the semantics of the selector parameter (targets element vs focused element). This compensates for the schema leaving 'text' and 'selector' without descriptions, and reinforces the enum meanings that are spelled out in 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 opens with 'Input text' and clearly distinguishes behaviors: with a selector it fills/types the element, without it types into focused element. It also explains the three modes (fill, type, insert), making it entirely clear what the tool does and how it differs from sibling tools like cdp_press.

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 by explaining how to use it with or without a selector, but it does not explicitly state when to prefer this tool over alternatives like cdp_press or cdp_click. There are no exclusions or comparative guidance, so it's only implied usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry behavioral details. It discloses the target element type and the path existence requirement, but does not mention side effects, event triggering, or behavior on invalid selectors. This is minimal but not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff, front-loaded with the core action.

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 3-parameter tool with no output schema, the description gives purpose and a key constraint, but lacks details about return values, failure modes, or whether the operation waits for upload. It's adequate but not comprehensive.

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?

Only session_id is described in the schema (33% coverage); the description adds meaning by indicating 'files' are server-side paths and 'selector' targets a file input. This compensates for the low 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 clearly states the tool's function: setting files on an `<input type=file>`. It uses a specific verb and resource, and its purpose is distinct from sibling navigation and interaction 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 implies usage when a file input needs to be populated, and adds a critical prerequisite that paths must exist on the server machine. However, it does not explicitly state when to prefer this over other input tools like cdp_type, nor does it provide exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of behavioral disclosure. It explains the two operational modes but leaves ambiguity about whether the timeout applies when a selector is given, and it does not disclose behavior on timeout failure (e.g., error vs. return false).

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 directly front-loaded with the main action. It is concise, with no unnecessary words or repetition.

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 tool is simple, but the description does not cover all essential context: return values are not mentioned, timeout behavior with selector is ambiguous, and there is no annotation or output schema to fill gaps. It is adequate but not complete for a tool with no annotations.

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 33%, so the description must compensate. It clarifies that 'selector' is a CSS selector and 'timeout' is in milliseconds, adding meaning beyond the schema. However, it does not clearly explain how timeout interacts with selector-based waiting, leaving some 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 tool's purpose: waiting for a CSS selector to appear or waiting a fixed timeout. This is a specific verb-plus-resource combination that distinguishes it from sibling tools like cdp_wait_response, which likely waits for network responses.

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 clear context for when to use the tool: when you need to wait for an element to appear or when you need a fixed delay. However, it does not explicitly exclude alternatives or mention sibling tools, so it stops short of full guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the body is truncated and that method/status are optional filters, but does not explain timeout behavior, what happens on no match, or whether the response is consumed or left in the network log. Some behavioral traits are provided but significant gaps remain.

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 front-loads the core action, includes key filtering options, and notes the truncated body. Every part adds value with no redundancy.

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?

This is a moderately complex async tool with no annotations, no output schema, and low parameter documentation. The description does not cover timeout semantics, error conditions, or whether the response is removed from the network log, making it incomplete for safe autonomous use.

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 20% (only session_id). The description adds meaning for url_contains, method, and status, but entirely omits the timeout parameter, which has no schema description. This is a critical omission since timeout controls waiting behavior and has a default value that is not self-explanatory.

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 states a specific verb ('Wait') and a resource ('a response whose URL contains url_contains'), with optional filters. It clearly distinguishes from siblings like cdp_wait (page load) and cdp_network_log (network logging), and mentions return values.

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 waiting on network responses but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of exclusions or prerequisites, leaving the choice to the agent's inference from the tool name and sibling context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.