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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds behavior they cannot express: the operation is atomic and nothing is written unless every hunk applies, the result reports compiler/linter problems, and a checkpoint id is returned for undo. Atomicity and undo are exactly the non-obvious traits an agent needs before mutating many files.

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?

Front-loads the atomicity guarantee and preference statement in the first sentence, then spends the remainder on the format example, which earns its space for a grammar-driven parameter. It is long, but nearly every line carries required syntax or 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?

With no output schema, the description correctly describes what comes back (diagnostics plus checkpoint id) and covers the destructive/atomic semantics. It omits how failures are surfaced and how this relates to edit_file/write_file, which are the remaining gaps for a multi-file mutation 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 67% and documents cwd and check, but leaves the required 'patch' parameter undescribed. The description compensates by specifying the exact patch grammar (Begin/Update/Add/Delete/Move/End, +/-/space prefixes, optional anchor) and the context-line convention, which is what makes the required parameter usable.

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?

States a specific verb (apply) and resource (multi-file patch) plus a distinguishing trait: atomic, all-or-nothing. Combined with 'Preferred way to change code', an agent can separate it from nearby file-mutation siblings like edit_file and write_file.

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?

Explicitly positions itself as the preferred mechanism for changing code, which is real usage guidance. It stops short of naming the alternatives (edit_file, write_file) or stating when a single-file edit is preferable, so it is clear context without 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the risk profile is known. The description adds the read-only precondition for parallel execution, which is useful. But it omits error-handling behavior (what stopOnError vs failOnAnyError actually do, especially with both defaulting to false) and the 20-call cap from the schema.

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, front-loaded with what the tool does followed by the key constraint. No filler. It is terse to the point of under-specification, but that is a completeness problem rather than a verbosity one.

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 meta-tool with 4 parameters, 0% schema description coverage, and no output schema, the description is thin. It should define batch entry structure, the 20-call ceiling, and the distinct roles of stopOnError/failOnAnyError to make the tool safely invocable. Annotations cover safety but not orchestration semantics.

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 0% across 4 parameters, so the description must compensate — and largely does not. Only the conditional meaning of 'parallel' is addressed; 'calls', 'stopOnError', and 'failOnAnyError' are never explained, and the maxItems:20 limit is not mentioned. This leaves the most consequential semantics undocumented.

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?

States a specific verb and resource: 'Run several tool calls in one request.' An agent immediately knows this is a multiplexer/batch executor, distinct from any single-call sibling. However, it does not clarify what a 'call' entry must contain (tool name + args) or how results are returned, leaving some ambiguity.

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 one explicit usage rule: parallel mode is permitted only when every called tool is read-only. That is genuine guidance. But it says nothing about when to prefer batch over issuing calls individually, nor about how stopOnError/failOnAnyError affect execution, so the guidance is partial.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the safety profile is largely covered. The description adds the return behavior ('Returns the updated snapshot'), but it omits meaningful behavioral context for a click tool — e.g. that clicking may navigate, submit forms, or trigger irreversible actions, which matters given destructiveHint=true.

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 the targeting preference front-loaded and the return value second; every word earns its place and nothing is redundant.

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, zero-required, destructive mutation tool with no output schema and only 43% parameter documentation, the description is thin. It does not explain the button, modifiers, doubleClick, or snapshot options, nor the side effects an agent should anticipate before clicking.

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 43%, and four parameters (button, snapshot, modifiers, doubleClick) have no schema description at all. The description only hints at the ref/selector/text triage, which the schema already labels as alternatives, so it does not compensate for the 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?

States a specific verb (click) and resource (an element), plus the three supported targeting modes (ref, selector, text). It is clearly distinguishable from sibling read-only tools like browser_get_text or browser_snapshot, though it does not distinguish itself from the near-identical chrome_click or adjacent interaction tools such as browser_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 parenthetical '(preferred)' on ref implies a targeting precedence, which is light usage guidance. However, there is no explicit when-to-use vs. when-not, and no mention of prerequisites (e.g. that a ref must come from a prior browser_snapshot) or which siblings to prefer for hovering, typing, or pressing keys.

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 annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds a valuable non-obvious behavioral detail: the persistent profile is not destroyed, which meaningfully clarifies the scope of the destructive action. It still does not say what live session state or tabs are lost when the browser closes.

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. The essential action is stated first, and the important caveat about the persistent profile is appropriately appended.

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 zero-parameter close operation with no output schema, the description plus annotations provide sufficient context to invoke the tool correctly. Minor omissions remain, such as behavior when no browser is open or confirmation of what session state is discarded.

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 zero input parameters, so there are no parameter semantics for the description to explain. The schema itself has 100% description coverage, and the baseline for a zero-parameter tool 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 states a specific verb and resource: 'Close the Playwright browser.' The parenthetical narrows the scope by clarifying that the persistent profile remains on disk, which distinguishes this from destructive cleanup that would delete profile state.

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 explicit when-to-use or when-not-to-use guidance. It implies end-of-session cleanup, but it does not name alternatives such as browser_tabs, chrome_close_tab, or other browser lifecycle 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?

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior. The description usefully adds the content types captured (errors, failed requests, dialogs), but says nothing about the mutating effect of the 'clear' parameter, buffering, or whether logs persist across navigations.

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 tight sentence with no filler, and the most important content types are front-loaded. It reads as a fragment rather than a verb-led instruction, but no words are wasted.

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 three undocumented parameters, no output schema, and a 'clear' flag that appears to wipe captured data, the definition is too thin to invoke safely. An agent cannot know what clear does or what limit/onlyErrors control.

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 0% for all three parameters, so the description is the only place semantics could be added — and it adds none. 'clear', 'limit', and 'onlyErrors' are never mentioned; 'onlyErrors' is only obliquely implied by the phrase 'page errors'.

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 names the specific resources retrieved — console messages, page errors, failed requests, dialogs — so an agent knows exactly what it gets. It omits an action verb and gives no differentiation from the sibling chrome_console, which appears to expose the same data.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as chrome_console or browser_dialog despite heavy sibling overlap. The agent must infer usage entirely from the tool name.

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 annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the write-capable nature is covered structurally. The description usefully adds that dialogs are never auto-accepted (so the agent must handle them explicitly), but it does not explain what accept vs dismiss does to the underlying page or how promptText applies.

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 tight sentences, front-loaded with the resource and scope. No filler, though the second sentence is a caveat rather than a usage instruction.

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 2-parameter tool with an undocumented enum and no output schema, the description leaves real gaps: it never maps the action values to behavior or explains promptText, so an agent must infer the accept/dismiss/prompt semantics from the schema alone.

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 0% with 2 parameters, and the description explains neither 'action' (whose enum values status/accept/dismiss map directly onto the stated capabilities) nor 'promptText' (presumably the text submitted on accept of a prompt). Only the verbs 'inspect'/'answer' loosely hint at the action values.

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?

States a specific verb+resource: inspect or answer a JavaScript dialog, scoped to the Playwright browser. It reasonably distinguishes it from the sibling chrome_dialog, though it never names that sibling explicitly.

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?

Usage is only implied — the tool is obviously for when a dialog is blocking the browser, but the description gives no guidance on when to use status vs accept vs dismiss, nor any prerequisite or alternative routing.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the risk profile is covered by structured data. The description adds nothing behavioral beyond that: it says nothing about execution context/privileges, sandboxing, timeouts, or error behavior for arbitrary code execution.

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, front-loaded with the action and then the argument format. No 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?

With one parameter and annotations covering safety, the description is nearly sufficient. But there is no output schema, so the return value (serialized result, or what happens on a thrown error / non-serializable value) should have been mentioned to let an agent call this 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 0%, so the description carries the burden and does so usefully: it clarifies that 'script' can be a bare expression ("document.title") or a function body requiring an explicit return. That is real semantic guidance beyond the bare string type.

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?

States a specific verb and resource: 'Run JavaScript in the page.' This is clearly distinguishable from read-oriented siblings like browser_get_text or browser_snapshot, though it never explicitly names them or notes its overlap with browser_console/chrome_evaluate.

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 the two argument forms but gives no guidance on when to reach for this tool versus browser_get_text, browser_snapshot, or browser_console. No prerequisites, no when-not, no alternatives are 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?

Annotations already cover safety (readOnly, idempotent, non-destructive) and open-world behavior, so the bar is lower. The description adds the useful nuance that only 'visible text' is returned, but it omits truncation behavior for maxChars, handling of missing selectors, and default selector behavior, leaving meaningful 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?

A single sentence with no wasted words, and the core resource is front-loaded. It is arguably too thin, but as a pure conciseness measure it is efficient and well-structured.

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 two-parameter, no-output-schema tool, the description leaves key behaviors unspecified: what happens when selector is omitted (whole page?), how maxChars truncation works, and failure behavior when a selector matches nothing. Annotations cover safety, but the description is insufficient for the agent to invoke it confidently.

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 0%, so the description must compensate. It clarifies that the selector is a CSS selector, but says nothing about the maxChars parameter, leaving one of two parameters undocumented in both the schema and the 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?

States a specific resource ('visible text') and its two scopes ('page or of an element'), making clear what kind of content is returned. It lacks an explicit verb and does not distinguish itself from siblings like browser_snapshot or browser_evaluate, so it falls short of a 5.

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 such as browser_snapshot or browser_evaluate. The phrase 'page or of an element (CSS selector)' hints at two modes but provides no conditions or preferences for selecting between them or among siblings.

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?

Annotations already declare the safety profile (destructiveHint=true, openWorldHint=true, idempotentHint=false), so the description is not burdened with that. However, it adds nothing beyond them: no mention of whether hovering triggers hover-only UI, side effects, or failures on missing elements. No contradiction with the annotations, just zero added 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?

Four words, front-loaded, no filler. It is as concise as possible, though the brevity borders on under-specification.

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 three-optional-param interaction tool with full schema coverage and no output schema, the minimal description is borderline adequate. It omits target-resolution precedence (ref vs text vs selector) and what hovering actually produces, which an agent would benefit from.

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%, with each of ref, text, and selector documented as alternatives, so the schema carries semantics. The description adds nothing about precedence among the three targeting modes, which is the one thing missing. Baseline 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?

States a specific verb and resource: hover over an element. It is distinguishable from the other browser_* tools (click, type, scroll) by its unique action, though it offers no explicit sibling differentiation.

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

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

There is no guidance on when to hover versus clicking, typing, or waiting, and no note about prerequisites such as having a snapshot ref available. The agent must infer usage entirely from the name.

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?

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false and readOnlyHint=false. The description adds genuinely useful context not in the annotations — persistent profile with remembered logins, and that it returns a page snapshot with element refs. It does not, however, explain why navigation is flagged destructive (loss of current page state).

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 tight sentences, front-loaded with the action and runtime, then the return value. No 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?

With no output schema, the description usefully states the return value, and annotations cover the safety profile. But it omits newTab semantics and any routing guidance among the many browser/chrome siblings, so it is adequate rather than 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 0%, so the description must carry parameter meaning, but it only implies 'url' and 'snapshot' (via 'Returns the page snapshot'). The newTab parameter is undocumented in both schema and description, leaving a meaningful gap.

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?

States a specific verb+resource ('Open a URL in the Playwright-controlled Chrome') and distinguishes the runtime from the chrome_* extension siblings. An agent can tell it navigates the Playwright browser, though it does not name which sibling to prefer.

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 when-to-use guidance, no prerequisites, and no mention of when to choose this over chrome_navigate or fetch_url. The agent must infer usage entirely from the verb.

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?

Annotations already flag destructiveHint=true, readOnlyHint=false, openWorldHint=true, and non-idempotency, so the safety profile is covered. The description adds the chord syntax convention but says nothing about focus requirements, that keystrokes can mutate page state, or any rate/confirmation 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?

A single well-formed sentence with the action front-loaded and examples inline. No wasted wording, though it is sparse enough that a clause about focus or the snapshot flag could have earned 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?

For a two-parameter mutating tool with no output schema, the description covers the primary input but omits the snapshot parameter entirely and gives no behavioral context beyond annotations. Adequate but with a visible gap.

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 0%, so the description must carry the load. It does clarify the 'key' parameter with chord examples like 'Control+A' and 'ArrowDown', which is genuinely useful syntax information absent from the schema. However, the second parameter 'snapshot' is never mentioned, leaving half the parameters undocumented.

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?

States a specific verb and resource ('Press a key or chord on the page') and supplies concrete examples, which separates it from browser_type and browser_click. It does not explicitly name the sibling it differs from, so it stops short of a 5.

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 press a key versus using browser_type, browser_click, or a chord-based alternative, and no stated prerequisites such as an element needing focus. Usage is only implied by the examples.

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?

Annotations declare destructive/openWorld/non-idempotent, and the description adds real behavioral detail beyond them: a dedicated tab is opened, it uses the caller's profile logins, and the recording is scoped to subsequent browser_* actions until stop. It does not explain why the operation is flagged destructive or what happens to the recording output, leaving a small gap.

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 tight sentences, front-loaded with the core action and followed by the lifecycle constraint. No filler or restated title.

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 9-parameter tool with no output schema, the description covers the lifecycle adequately but says nothing about how the resulting video is identified or retrieved, nor about the parameter space (resolution, format, fps, headless behavior). It is minimally viable rather than 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?

The schema has 0% description coverage across 9 parameters (fps, format, width/height, headless, resourceWaitMs, url, name, useProfileLogins), and the description documents none of them. It only obliquely hints at useProfileLogins via 'with your profile logins', so the agent must infer the meaning and units of nearly every parameter.

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?

States a specific verb and resource ('Start recording a video of a browser session') and immediately clarifies the mechanism ('Opens a dedicated recording tab'). An agent can distinguish this from browser_record_stop and from browser_screenshot without opening the schema.

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?

Gives clear context — recording begins here and captures 'every browser_* action afterwards ... until browser_record_stop' — which effectively names the terminating sibling. It lacks an explicit when-not-to-use (e.g., versus record_clip or one-off screenshots), 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.

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations by stating the output is an mp4 via ffmpeg and that it returns a file path, but it does not explain how the destructive discard option affects saved output.

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 states the action, output format, and return value without filler. Every clause contributes to understanding the 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 destructive mutation tool with two completely undocumented parameters and no output schema, the description is too sparse. It covers stop/save/return format, but omits any explanation of discard or trimStart, leaving significant gaps 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 0%, and the description does not mention either parameter. It provides no meaning for 'discard' or 'trimStart', so an agent cannot infer how these options alter the stop/save behavior from the description alone.

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 ('Stop') and resource ('the recording'), and specifies the save behavior and output format. It distinguishes itself from browser_record_start by describing the stop/save action rather than starting a recording.

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 phrase 'Stop the recording and save the clip' implies this should be used after a recording has been started, which is clear context. However, it does not name alternatives such as browser_record_start or record_clip, nor does it say 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?

Annotations already disclose readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description adds no behavioral context beyond the basic action, such as whether the resize affects subsequent screenshots, evaluations, or page layout. With annotations covering the safety profile, the description's lack of additional detail is a notable gap.

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. However, it is so terse that it borders on under-specification for a tool with two required parameters and no parameter documentation.

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 two-parameter mutation tool, annotations cover the safety profile, but the description provides no parameter semantics, units, or usage context. With no output schema and 0% schema description coverage, an agent lacks enough guidance to invoke this correctly without guessing units or intent.

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 0% for two required parameters (width and height). The description does not mention units (pixels?), valid ranges, or any meaning beyond what the bare property names already imply, so it fails to compensate for the missing schema descriptions.

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 and resource: 'Set the viewport size.' This clearly distinguishes it from siblings like browser_screenshot or browser_evaluate, which capture or inspect browser state. It lacks any further scope or differentiation, but the core 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no context about how resizing interacts with other browser operations. The description only states what it does, not when or why to call 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuine behavioral fact not in annotations: the image is both returned to the model and persisted to disk. It omits where the file lands and what format, which caps it below 5.

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 front-loaded sentence that loses no words and immediately states scope and return behavior. Nothing redundant or padding-like.

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, the description carries the return-value burden and does so partially, explaining that an image comes back and is saved to disk. It leaves unspecified the save location, image format, and whether the returned image is inline, which an agent might need for follow-up steps.

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 75%, so ref/text/selector are already documented in the schema; the description adds only the page-vs-element framing. The boolean fullPage has no description in either place, leaving one parameter's semantics unexplained.

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+resource ('Screenshot of the page (or one element)') and clarifies scope (whole page vs. a single element), which lets an agent distinguish it from browser_snapshot or browser_get_text. It does not name those siblings explicitly, so it falls short of a 5.

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?

Usage is only implied by 'The image is returned so you can see it,' which suggests reaching for this when visual output is needed rather than text. No when-to-use/when-not or comparison against browser_get_text or browser_snapshot is given, so the routing decision is left to inference.

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?

Annotations already declare the mutation/safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false), and the description adds nothing behavioral on top — no note on prerequisites (page must be loaded), what happens if the ref/text/selector is not found, or whether the scroll delta is bounded. For a state-changing tool with no output schema this is a real gap.

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 tight sentence with both use modes front-loaded and no filler. It could have been split into a target-selection clause and a delta clause for faster scanning, but it wastes nothing.

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?

Five optional parameters, no output schema, and the description only broadly names both modes without covering default deltas, overloaded-parameter precedence, or failure behavior when a target is not found. It is minimally adequate but not complete for a tool with this many knobs.

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 60%, and the description contributes the useful unit detail that deltaY/deltaX are in pixels, which the schema omits. However it does not explain precedence when ref, text, and selector are all supplied, nor the deltaY=600 default behavior, so it only partially compensates for the coverage gap.

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?

States a specific verb (scroll) plus both targeting modes (pixel delta vs element into view), so the agent knows exactly what the tool does. It does not differentiate itself from the near-identical sibling chrome_scroll or from other viewport-affecting tools, which keeps it from a 5.

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 when-to-use guidance at all: nothing about when to scroll versus calling browser_snapshot, browser_wait_for, or a click that auto-scrolls. No prerequisites or sequencing hints are given.

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 annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, covering the safety profile. The description adds no further behavioral context: it does not mention event triggering, multi-select behavior, side effects, or what 'destructive' might mean in this 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 front-loaded sentence with no wasted words, but it is under-specified for a tool with five parameters and browser-interaction complexity. Brevity here reflects missing information rather than efficient communication.

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 only partial schema parameter coverage, the description should explain how to choose between ref, text, and selector, and what value/values do. It provides none of this, leaving the agent with insufficient context beyond the annotations and schema for a five-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 description coverage is 60% (ref, text, and selector have descriptions; value and values do not). The description does not explain any parameter semantics or clarify how ref, text, value, values, and selector interact, so it fails to compensate for the coverage gap.

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 and resource: select option(s) in a <select>. It is clear enough to know the operation, but it does not distinguish this tool from siblings like browser_click or browser_type, nor does it mention the browser-automation context.

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 such as browser_click, browser_type, or browser_evaluate. The description only restates the operation with no context about preconditions or selection criteria.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context by disclosing the return format (ref handles) and the workflow dependency for click/type, but says nothing about snapshot freshness, staleness after navigation, or size limits.

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, zero filler, with the output format stated first and the usage trigger second. Every clause 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?

For a no-parameter, read-only snapshot tool with no output schema, the description covers what the tool returns (ref handles) and when to reach for it. It could mention that refs become invalid after navigation, but nothing essential for correct invocation 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already conveys.

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?

Names a specific verb+resource (accessibility snapshot of the current page) and specifies the output shape ([ref=eN] handles), which distinguishes it from browser_screenshot and browser_get_text by implication. It stops short of explicitly contrasting itself with those 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?

"Use it before clicking/typing" gives a concrete trigger condition and positions the tool in the interaction workflow. It does not state when-not to use it or name the visual/text alternatives (browser_screenshot, browser_get_text) explicitly.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the agent knows some actions mutate and destroy state. The description adds the useful fact that one tool multiplexes four distinct operations addressed by index, but it never says that 'close' is irreversible or that index is mandatory for select/close. No contradiction with annotations.

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 tight sentence with the core purpose front-loaded and zero filler. It is efficient, though the terseness is partly under-specification rather than true compression.

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 four-action multiplexer with zero required parameters, no output schema, and no action/parameter mapping rules, the description is too thin. An agent still cannot tell which parameters are valid per action or how this tool relates to the chrome_* tab siblings.

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 0% and no parameter is required, so the description carries the full burden — yet it only obliquely implies 'index' is the addressing key and 'open (new)' hints that url pairs with the new action. It does not state that url is used only with action='new', nor that index is required for select/close, leaving invalid combinations undocumented.

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 names four concrete verbs (list, open, select, close) and the resource (tabs), plus the addressing mechanism (by index), so an agent immediately understands it is a tab-management multiplexer. It falls short of a 5 because it never distinguishes itself from the closely-overlapping siblings chrome_list_tabs, chrome_new_tab, chrome_switch_tab, and chrome_close_tab.

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?

'by index' is the only usage signal; there is no statement of when to pick this tool over the four chrome_* tab siblings, no prerequisites, and no guidance on which action to use in which situation. The four actions are simply enumerated without routing logic.

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?

Annotations declare destructiveHint=true, but the description is what explains why: the default behavior replaces the field's existing value, and only slowly:true preserves key-by-key entry. It also discloses that submit:true fires Enter, a side effect not captured by annotations. Focus/permission requirements remain unmentioned.

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 tight clauses with no filler, and the destination plus the default overwrite behavior are front-loaded. The telegraphic 'slowly: true' shorthand is compact but slightly cryptic without a comma-joined explanation.

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 5-parameter mutation tool with annotations and no output schema, the description covers the main non-obvious behaviors (overwrite default, slow typing, Enter submission). It omits failure handling and ref-vs-selector precedence, which are minor given the schema already defines both targeting options.

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 40% and slowly/submit have no schema descriptions, yet the description supplies their exact semantics (slow = per-key typing, submit = Enter press) plus the default replace behavior of text. ref and selector are already documented in the schema, so the remaining gap is small.

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?

States a specific verb (type) and the exact target set (input/textarea/contenteditable), which is more precise than the tool name alone. It does not name a sibling or draw an explicit boundary against browser_press_key or browser_click, so it stops short of a 5.

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?

Usage is implied by the target-element list, and the slowly/submit flags hint at when each mode applies (character-by-character vs instant, Enter submission). There is no explicit when-to-use/when-not guidance and no routing to browser_press_key for plain key presses.

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?

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent behavior, so safety context exists. The description adds virtually nothing beyond them — no note that the named local path must exist, that it interacts with the host filesystem, or what happens if the element is not a valid file input.

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 tight sentence with the action front-loaded. Effectively sized, though the parenthetical overloads it with locator terminology that arguably belongs in usage guidance.

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, open-world mutation tool with five parameters, no output schema, and no required params, the description omits the prerequisite (ref acquisition), the path/paths semantics, and any failure or side-effect behavior. What an agent needs to call it correctly is largely 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?

The description names ref/selector/text, mapping to three of the five parameters, but says nothing about the single-vs-multiple file distinction between 'path' and 'paths', which is the most consequential semantic in the schema. With 60% schema coverage, some compensation occurs but the critical path/paths ambiguity is left unresolved.

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?

States a specific verb+resource ('Upload local file(s)') and mentions the target forms (file input or upload button), which distinguishes it from sibling tools like browser_click or browser_type. The trailing '(ref/selector/text)' is confusingly framed as if those were upload methods rather than element locators, slightly muddying the 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 when-to-use guidance, no exclusions, and no mention of prerequisites such as obtaining a ref from browser_snapshot before calling this. The agent is left to infer the workflow entirely.

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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=false), so the description's marginal job is to explain wait semantics — and it does not. The single most important behavior for a wait tool, what happens when the timeout elapses (throw vs. return a negative result), is never stated, nor is whether it blocks other operations.

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?

One compact sentence, front-loaded with the primary mode and trailing the fallback mode. Minor inaccuracy in the parenthetical state list (says 'appear ... visible/hidden/attached' while the enum also includes 'detached') is the only blemish.

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?

No output schema exists, so the description should at minimum establish return/timeout behavior and the full state vocabulary; it does neither. For a four-parameter, zero-required tool with no schema documentation, this leaves a real gap an agent must guess around.

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 0%, so the description carries the burden and only partially does. It maps 'text'/'selector' to the two wait modes and names usable states, but it calls out only three of the four enum values (omitting 'detached') and never defines what 'attached' vs 'visible' means or that text and selector should not both be supplied.

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?

States a specific verb (wait) and the two wait-able resources (selector or text), plus the alternate timeout-only mode, so the agent knows this is a blocking-until-condition tool rather than a poll/read tool. It does not explicitly contrast itself with siblings like browser_get_text or browser_snapshot, which is the only thing keeping it from a 5.

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?

Usage is implied: pass selector/text to block on a condition, or pass only timeoutMs to pause. There are no explicit when-to-use/when-not rules, no note that text and selector are alternatives, and no mention of a sibling for non-blocking inspection. Useful but inferred rather than 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?

Annotations already disclose the risky profile (destructive, openWorld, non-idempotent, not read-only), so the safety burden is largely covered. The description adds that this is a fallback path, but omits critical behavior for a dispatcher: what happens when 'tool' is unknown, whether args are forwarded verbatim, and whether the call is proxied elsewhere.

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?

One front-loaded sentence with no filler or redundancy. It is efficient, though brevity here borders on under-specification rather than tight editing.

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 generic dispatcher that can invoke arbitrary capabilities with arbitrary arguments, the description is thin: no guidance on valid tool identifiers, argument-passing contract, error behavior for missing capabilities, or reference to capability_list for discovery. With no output schema and 0% param coverage, the description should carry far more.

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 0% and there are two parameters, including a nested 'args' object with no documented shape. The description says nothing about what 'tool' should contain (a capability name) or how 'args' must be structured to match the target capability's schema, so it fails to compensate for the coverage gap.

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 phrase 'fallback dispatcher' conveys a generic act of routing, and the qualifier 'capability present on the live server but missing from a cached client catalog' is really a usage condition rather than a statement of what the tool does. An agent can infer it invokes a named capability, but the verb is vague and the resource is abstract.

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 the trigger condition (a capability is on the live server but absent from the cached catalog), which is a real usage cue. However, it never names the natural partner tool (capability_list) for discovering capabilities, nor does it state when this fallback should NOT be used versus a normal direct call.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description only adds the word 'live', hinting the catalog is dynamically generated, without saying whether it reflects runtime-registered capabilities or anything about result shape.

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, front-loaded sentences with no filler; the core purpose leads and the parameter hint follows. Slightly terse relative to what is left unexplained, but nothing is wasted.

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 two-parameter, no-required-input read tool with no output schema, the definition is minimally workable. It still leaves includeDescriptions behavior and the return shape (names only vs. full metadata) to inference, which matters for an agent choosing between this and capability_call.

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 0%, so the description must compensate and only partly does: it explains prefix ('filter tool names') but leaves includeDescriptions completely undocumented, and it does not say whether prefix matches tool names, capability IDs, or both, nor whether it is case-sensitive.

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?

States a specific verb and resource — 'List the live MCP capability catalog' — which clearly distinguishes it as the read/enumeration counterpart to capability_call. It stops short of naming that sibling explicitly, but the pairing is unambiguous from the verb.

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?

'Use prefix to filter tool names' addresses how to use a parameter rather than when to choose this tool over capability_call or when a full unfiltered listing is appropriate. Usage is implied by the name/description but never stated as a condition.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that problems are reported rather than auto-fixed, but omits output format, whether a nonzero exit is surfaced, and whether all listed linters always run or only those matching the file type.

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 front-loaded sentence with zero filler; the enumerated linters are the substance of the tool and earn their length.

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 two loosely documented parameters, the description carries real burden. It explains what runs and that problems are reported, but leaves the path/paths semantics and the result shape unexplained, so it is only marginally 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?

Schema coverage is only 50%: 'paths' carries no description at all. The description says 'on specific files' but never clarifies the relationship between the singular 'path' and plural 'paths' parameters, nor whether both are required or mutually exclusive, so it fails to compensate for the coverage gap.

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 ('Run') and resource ('compilers/linters') and enumerates the actual tools invoked (tsc, eslint, node --check, go vet, etc.). This is far more concrete than a bare 'check' name, though it never distinguishes itself from lsp_diagnostics, vscode_diagnostics, or run_command, which also surface problems.

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 when-to-use guidance, no statement of prerequisites, and no routing to alternatives despite several siblings (lsp_diagnostics, vscode_diagnostics, run_command) that overlap with static analysis. The agent must infer the selection criterion entirely.

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?

Annotations already establish this as a read-only, idempotent, non-destructive operation, so safety is covered. The description usefully adds the semantics of what a checkpoint represents (one per file-changing tool call) and that it reports touched files, but stays silent on ordering, retention window, or pagination behavior for older checkpoints.

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?

One tightly written sentence with no filler; the resource is front-loaded and the parenthetical definition earns its place by clarifying a project-specific term.

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 only one optional parameter, the description conveys enough to call it correctly and previews the return shape (checkpoints with their touched files). It falls just short on the meaning of the limit parameter and return ordering.

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 'limit' parameter has no description in the schema (0% coverage), and the description only gestures at it via the word 'recent'. It does not state whether limit counts checkpoints or files, or what happens when there are fewer than the limit.

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?

States a specific verb (List) and resource (checkpoints), and even defines what a checkpoint is — one per file-changing tool call — plus the payload (files touched). It does not, however, distinguish itself from the sibling checkpoint_rewind, which an agent might confuse for the read side of this feature.

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?

Usage is only implied: an agent can infer this is the discovery step before calling checkpoint_rewind, but the description never says so and offers no when-to-use or when-not-to-use guidance. No alternative is named despite checkpoint_rewind being an obvious adjacent tool.

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?

Annotations already flag destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing exactly what is destroyed: the target checkpoint 'and every later checkpoint', plus the default-target 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?

One sentence, front-loaded with the destructive verb 'Undo', with the scope and default packed in without filler. Every clause 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?

For a destructive, non-idempotent single-param tool with no output schema, the description covers the action, the default target, and the collateral scope. It could still note that the undo is itself not trivially reversible, but the annotations carry the risk signal.

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 0% and the single parameter 'id' is undocumented in the schema. The description compensates by explaining that id refers to a checkpoint and that omitting it defaults to the latest checkpoint.

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?

Names a specific action (restore/undo) and resource (files at a named checkpoint), and states the scope includes the named checkpoint plus every later one. It is clearly distinguishable from checkpoint_list, the only nearby sibling.

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?

It explains the default (latest checkpoint when no id is given) and the blast radius of the operation, but never states when to prefer this over alternatives (e.g. checkpoint_list to inspect first) or any precondition. Usage is implied rather than prescribed.

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?

Annotations already declare destructiveHint=true, openWorldHint=true and readOnlyHint=false, so the agent knows this is an unsafe, side-effecting call into page-supplied code. The description adds the mechanism (page-declared tools) but says nothing about trust boundaries, failure modes, or that the invoked behavior is entirely page-controlled. Adds some context; not rich.

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, front-loaded with the purpose and followed by the prerequisite action. Nothing redundant.

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?

There is no output schema, and for an open-world, destructive tool that proxies arbitrary page-declared APIs the description never indicates what is returned or how errors from the page tool surface. The snapshot prerequisite is covered, but return/error behavior is left entirely implicit.

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 60%; tabId, frameId and snapshotId are documented in the schema, but the required toolName and the free-form nested args object are undocumented anywhere. The description only indirectly supports snapshotId via the snapshot-first instruction and adds no syntax for args, so it does not compensate for the coverage gap.

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?

States a specific verb (invoke) and resource (a tool the web page itself declares), and names the concrete declaration surfaces (window.mcp / window.__mcp_tools__ / meta[name=webmcp-tool]). This clearly separates it from browser_evaluate or chrome_evaluate, which run agent-supplied code rather than page-declared 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?

Gives an explicit prerequisite in 'Take a chrome_snapshot first to see the catalog,' routing the agent to the sibling that produces the toolName/snapshotId it needs. No when-not guidance or statement about what to do if the page declares no 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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds real value beyond them: it explains the trusted/debugger click path and the DOM-click fallback when the debugger cannot attach, which tells the agent about reliability trade-offs.

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 front-loaded sentence with zero filler: mechanism, parameter semantics, and fallback all in one clause chain. Nothing wasted.

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 an action tool with annotations covering the safety profile and no output schema, the description covers mechanism, ref semantics, and failure fallback adequately. Minor gaps: no mention of whether it scrolls into view or what a failed click reports, but these are small for a click primitive.

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 60%, and the description clarifies the ref semantics ([#N], element reference) which the schema alone does not. It says nothing about doubleClick, tabId, frameId, or snapshotId beyond what the schema already documents, so it lands at the baseline for partial 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?

States a specific verb and resource (click an element) and specifies the mechanism (trusted mouse click via Chrome debugger) with a fallback. The [#N] ref format is called out, which is useful given the ref parameter is only typed as integer. Does not explicitly distinguish itself from the sibling browser_click, so it falls short of a 5.

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?

Implies usage (you need a [#N] ref, presumably from chrome_snapshot) and discloses the fallback path, but never states when to prefer this over browser_click or other click siblings. The condition selecting the alternative is left to inference.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true. The description adds no behavioral context beyond that, such as irreversibility, what happens to the active tab, or permission requirements. It merely restates the 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?

'Close a tab.' is extremely concise with no wasted words, but it is under-specified for a destructive tool. It front-loads the action but omits any caveat or scoping detail that would help an agent use it safely.

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 tool with rich annotations, the definition is minimally functional. However, it lacks any mention of the default active-tab behavior or how it relates to sibling close tools, leaving the agent to rely entirely on the schema and 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 coverage is 100% and the schema documents tabId with a default value. The description adds no parameter meaning beyond what the schema provides, so the baseline of 3 applies when the schema does the heavy lifting.

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

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

States a specific verb 'Close' and resource 'tab', making the action clear. However, it provides no differentiation from sibling tools such as browser_close or chrome_switch_tab, so an agent cannot easily distinguish this tool's scope without opening the schema.

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 when-to-use guidance, no alternatives, and no prerequisites are given. The agent must infer appropriate usage entirely from the tool name and 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful scope context ('since the debugger attached' implies a bounded, non-persistent buffer), but says nothing about retention limits, when the buffer resets, or what clearing does.

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 efficient sentence with the scoping constraint front-loaded and no filler. It is a sentence fragment without a verb, but that costs little.

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, the description should characterize the returned message structure and the effect of 'clear'; it does neither. It never states the prerequisite that the debugger must already be attached for any messages to exist.

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%: tabId is documented in the schema (default: active tab) but 'clear' is bare in both schema and description. The description never mentions that clear discards captured messages, which is the one parameter most likely to surprise a caller.

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 names the resource precisely — console messages and exceptions from a tab — with the scoping qualifier 'since the debugger attached'. It is clear what this tool returns, though it never states an explicit verb (retrieve/list) and gives no differentiation from the near-identical sibling 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?

There is no when-to-use guidance, no prerequisites (e.g., debugger must be attached), and no routing advice. The sibling list contains both browser_console and chrome_console, and the description does nothing to help an agent choose between them.

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?

Annotations already flag destructiveHint=true, readOnlyHint=false, and non-idempotence. The description adds genuine context: dialogs are never auto-accepted, and the required read-then-answer sequence. It doesn't detail consequences of accept vs dismiss, which would push it higher.

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 tight sentences with the constraint ('never accepted automatically') front-loaded, followed by the procedure. Zero wasted 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 dialog handler with no output schema, the description covers the essential behavior and sequence. It omits what 'status' returns for a non-blocking tab, a minor gap given the small tool surface.

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 33%; tabId is documented in the schema itself, and the enum action values are self-explanatory. The description usefully clarifies that promptText applies to prompt() dialogs, but adds nothing for the status vs accept vs dismiss distinction beyond the schema 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 gives a specific verb ('inspect or answer') and resource ('JavaScript dialog'), and enumerates the dialog types (alert/confirm/prompt/beforeunload). No sibling tool handles dialogs, so the agent can identify it unambiguously.

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?

It supplies clear context ('that is blocking a tab') and a workflow ('read the message, then accept or dismiss'). It stops short of naming alternatives or explicit when-not-to-use conditions, but the trigger condition 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so safety and repeatability are covered structurally. The description adds little behavioral context beyond enumerating return fields; it says nothing about ordering, truncation at the default limit, or whether the list is scoped to the active browser profile.

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, front-loaded sentence with zero filler; the resource leads and the fields follow. It is perhaps too terse to earn a 5 relative to the gaps above, but there is no wasted wording.

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, the parenthetical field list is genuinely useful for anticipating the response shape, which partially compensates. However, an agent still cannot tell ordering, default result count, or whether 'since' is required for meaningful output, so the definition is only minimally 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 only 50%: 'since' is documented in the schema as an ISO time filter, but 'limit' has no description at all in either place. With low coverage, the description should compensate, yet it never mentions pagination, the default of 10, or ordering of the returned items.

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 names a specific resource ('Recent Chrome downloads') and enumerates the returned fields (file path, state, size, source URL, referrer), so an agent knows exactly what data this yields. It is not a verb+resource phrasing, but the retrieval intent is unambiguous and the tool is clearly distinct from browser_* and file_* 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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The word 'Recent' implies a recency filter but the agent is not told how recency interacts with the 'since' parameter or when to prefer this over chrome_status, chrome_snapshot, or resource_status.

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?

Annotations already declare this is non-read-only, destructive, open-world, and non-idempotent. The description adds the useful 'via the debugger' context and the fact that the result must be JSON-serializable, but says nothing about what can be mutated, error/timing behavior, or the consequences of running arbitrary code.

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, front-loaded with the action and scope, zero filler. Every clause 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?

No output schema exists, so the description reasonably covers the return ('the JSON-serializable result is returned'), and annotation coverage handles the safety profile. However, for a tool that executes arbitrary code, the lack of any note on error handling, async/promise handling, or scope limits leaves real 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 50%: tabId is documented in the schema (default active tab) while expression has no schema description. The description compensates partially by stating an expression must be passed and that its result must be JSON-serializable, but adds no format or syntax detail beyond that.

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 and resource — run JavaScript in a tab's page context — and notes the mechanism (via the debugger). It is clearly distinguishable from retrieval siblings like chrome_get_text or chrome_console, though it does not explicitly contrast itself with browser_evaluate or chrome_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?

There is no when-to-use guidance, no prerequisites, and no naming of alternatives such as chrome_console or browser_evaluate. The only hint is the procedural 'Pass an expression', which is invocation mechanics rather than selection 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?

Annotations already flag this as non-read-only, destructive, non-idempotent and open-world. The description usefully adds that the extension is loaded 'from disk' and that a version is reported back, but it does not warn that reloading can interrupt an active browser session or require the extension to already be installed.

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 front-loaded sentence with no filler; every clause carries information (what is reloaded, from where, the precondition, and the returned datum).

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?

There is no output schema, but the description explains that the new version is reported. With zero parameters and annotations covering the safety profile, the only minor gap is what happens if the extension is absent or a session is active.

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 baseline is 4. There is nothing for the description to clarify, and it does not introduce confusion about inputs.

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?

States a specific verb (reload) and resource (the Free Codin Agent Chrome extension), plus the side effect (report the new version). This is clearly distinguishable from siblings like chrome_status or chrome_pairing_setup.

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 parenthetical '(after it was updated)' gives a clear triggering condition, so the agent knows when this is appropriate. No explicit alternatives or when-not-to-use guidance, but no sibling overlaps this operation either.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description's one added behavioral fact is that output is truncated, which is real value, but it omits what truncation does to the result (cut-off point, indicator) and whether auth/session state matters.

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 front-loaded parenthetical fragment with zero filler. It is efficient, though the brevity borders on under-specification rather than deliberate concision.

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, the description should say what the return value looks like (plain string? object with metadata?), and it only says the text is truncated. Annotations do carry the behavior/safety load, so the tool is callable, but key return-shape information 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 only 50%: tabId is documented in the schema but maxChars has just a default (40000) with no description, and the description does not compensate for either parameter. The mention of 'truncated' loosely hints at maxChars but gives no units, limits, or behavior when exceeded.

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?

Names the resource and the exact extraction method ('Visible text of a tab (document.body.innerText, truncated)'), so an agent knows this returns rendered visible text rather than HTML or a DOM dump. It does not, however, distinguish itself from close siblings like chrome_snapshot, chrome_evaluate, or browser_get_text.

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 statement of when to use this tool versus chrome_snapshot (structure), chrome_screenshot (pixels), or chrome_evaluate (arbitrary JS). The agent must infer the choice from the terse purpose line alone; no prerequisites or exclusions are given.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the "real Chrome" scope, which is mildly useful context consistent with the open-world annotation, but it does not disclose auth needs, return shape, or rate limits.

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 waste. Every word contributes to stating what is listed and where.

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 zero-parameter read operation with rich annotations, the description is nearly complete enough to call the tool correctly. The main omission is any indication of what tab information is returned, though that is a minor gap for a list-tabs 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?

The tool takes zero parameters, so there is no parameter semantics to explain. Per the rubric, a zero-parameter tool has a baseline of 4, and the description does not need to compensate for undocumented inputs.

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 ("List") and resource ("tabs") and scopes it to the user's real Chrome, making the purpose immediately clear. It does not explicitly differentiate itself from the similarly named sibling browser_tabs, which prevents a top score.

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 such as browser_tabs or chrome_switch_tab. The description also omits prerequisites or context for invocation.

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 annotations already disclose that this is a non-readonly, open-world, non-idempotent, destructive operation. The description adds that the call waits for the page to load, which is useful beyond the annotations, but it does not explain what navigation may disrupt, error behavior, or timeout handling.

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 immediately states the action, target, and loading 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 simple navigation tool with annotation coverage and no output schema, the description provides the essential action and wait condition. It is mostly complete, though it could better distinguish itself from browser_navigate and mention any timeout or failure 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 50%, and while tabId is documented in the schema, the url parameter has no schema description. The description partially compensates by constraining url to http(s) URLs, but it does not otherwise clarify expected format, redirect behavior, or tabId defaulting.

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 ('Navigate') and resource ('a tab to an http(s) URL'), and adds the loading condition. It does not distinguish this tool from the similarly named browser_navigate sibling, which is a noticeable gap.

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 indication of when to use chrome_navigate instead of alternatives such as browser_navigate, chrome_switch_tab, chrome_new_tab, or chrome_close_tab. Usage is only implied by the verb 'Navigate'.

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?

Annotations already disclose the safety profile (readOnly=false, destructive=true, openWorld=true, idempotent=false). The description adds only 'real Chrome' as context and does not explain what gets destroyed, how 'active' affects focus, or any side effects beyond what the annotations state.

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. For a simple open-a-tab action, that is appropriately 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?

The tool has no output schema, two undocumented parameters, and annotations indicating destructive and open-world behavior. The description does not cover parameter meanings, side effects, or return behavior, so it is not complete enough 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 0% and the description does not mention either parameter. It does not explain the 'url' default of about:blank or the 'active' default of true, leaving both parameters undocumented. With two undocumented parameters, the description fails to compensate for the schema gap.

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 gives a specific verb and resource: 'Open a new tab' in 'real Chrome.' It clearly states what the tool does, but does not differentiate from siblings like chrome_navigate, chrome_switch_tab, or browser_tabs.

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 when-to-use guidance and no mention of alternatives. An agent must infer that this is for creating a new tab rather than navigating or switching, but the description gives no explicit routing information.

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?

Annotations already declare the operation destructive, non-idempotent, and open-world. The description adds valuable context beyond that: the secret is never returned, both the extension and .env are updated, and a worker restart is required to enforce the change. It does not cover permissions or failure modes, so it is not fully exhaustive.

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, front-loaded with the action, followed by the security guarantee and the enforcement step. Every sentence carries practical information for invoking the tool correctly.

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 one-parameter setup tool with no output schema, the definition covers the action, dual update target, non-return of the secret, and required restart. It could state prerequisites such as an active connected extension, but annotations already cover the safety profile and the description is otherwise sufficient.

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 single rotate parameter is already documented in the schema as rotating even if token authentication is configured. The description only implies configure-vs-rotate behavior and adds no syntax or additional parameter meaning beyond the structured 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?

States a specific verb (configure/rotate), resource (Chrome bridge pairing token), and dual target (connected extension and .env). It is clearly distinct from sibling tools like chrome_status or chrome_extension_reload, which handle page or extension state rather than pairing credentials.

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 says to restart the MCP worker afterward and the schema notes rotate behavior, so some usage context is implied. However, it does not explicitly say when to use this instead of chrome_status, chrome_extension_reload, or other chrome tools, and it names no when-not conditions or alternatives.

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?

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The phrase 'as a trusted key event' is genuine added context (events are dispatched as trusted rather than synthetic), but it is not elaborated on and no focus/consequence behavior is disclosed.

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

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

A single front-loaded sentence that gives the action and the input format with zero filler. Every clause 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?

For a five-parameter action tool with annotations present and no output schema, the definition plus schema descriptions cover what an agent needs to invoke it (target, focus, staleness guard). Only minor behavioral detail is missing, which is acceptable given schema richness.

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 80% and the required 'key' parameter has no schema description, so the examples ('Control+a' chord syntax) materially compensate by showing the accepted input format. The remaining focus/tab/frame semantics are already documented 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?

States a specific verb plus resource ('Press a key or chord') and grounds it with concrete examples ('Enter', 'Tab', 'Escape', 'Control+a') that clearly distinguish it from text-typing siblings like chrome_type. Strong and specific, though it never explicitly names or routes away from a sibling tool.

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 statement of when to use this versus chrome_type or browser_click, no prerequisites, and no exclusions. Usage is only implied by the examples, leaving an agent to infer the right 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?

The annotations already cover safety traits (readOnly, idempotent, non-destructive). The description adds valuable context beyond annotations by disclosing that the output is an image and that the capture is limited to the visible viewport rather than the full 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 only two sentences and is front-loaded with the core action and scope. The second sentence is helpful for output expectations but slightly redundant, keeping it just short of perfectly economical.

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 screenshot tool with rich annotations and a fully documented schema, the description covers purpose, viewport scope, and return type adequately. It does not address relative usage versus other screenshot tools, but that 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?

Schema description coverage is 100%, and the single optional parameter tabId is fully documented in the schema. The description adds no further meaning about the parameter, so the baseline score 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 states a clear action and resource: taking a screenshot of a tab in the real Chrome, scoped to the visible viewport. It implicitly distinguishes itself from browser_screenshot by specifying 'real Chrome', but does not explicitly name or differentiate against sibling tools such as browser_screenshot or chrome_snapshot.

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 explicit guidance on when to use this tool versus alternatives like browser_screenshot, windows_screenshot, or chrome_snapshot. The description only states what the tool does, leaving usage context and exclusions to inference.

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?

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety and mutability profile is known without the description. The description adds the meaning of negative y values, which is useful behavioral detail, but does not explain what makes scrolling destructive, whether a snapshot is required, or how stale actions are handled beyond what the schema already says.

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 front-loaded sentence that contains no redundant or filler language. It is sized appropriately for a simple scroll 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 four-parameter scroll tool with no output schema, the description is minimally adequate: it covers the core action and y semantics. It still omits usage routing against browser_scroll and does not discuss the snapshotId stale-action behavior that the schema mentions, which would be helpful context for safe 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 75%, and the undocumented parameter is y. The description compensates by defining y as pixel distance and explaining that negative values scroll upward, which is exactly the missing semantics. The other three parameters are covered by their schema descriptions.

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 (Scroll) and resource (the inspected tab), and specifies the unit and direction semantics ('by y pixels', 'negative scrolls up'). However, it does not distinguish this Chrome-specific tool from the sibling browser_scroll, leaving an agent to infer the platform split.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as browser_scroll or when scrolling may be unnecessary. The direction note implies basic operation but not selection criteria.

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?

Annotations already declare it as read-only, idempotent, non-destructive, and open-world. The description adds valuable behavioral context about the snapshot's content format and the required ordering before interaction actions, though it does not mention rate limits or pagination 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?

Two tightly written sentences with zero waste. The output format is front-loaded, followed immediately by the action-oriented usage instruction.

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, the description usefully summarizes the return shape (interactive elements with refs, site tools) and pairs it with the required workflow. It omits details about maxElements, frameId behavior, and what 'site tools' entail, but is sufficient for correct tool selection and basic 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 75%, so most parameters are documented in the schema. The description adds no parameter-specific semantics beyond the general output format, so a 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?

States a specific verb and resource ('snapshot of a tab') and specifies the output content ('interactive elements with [#N] refs, plus page-declared site tools'). It distinguishes a semantic snapshot from a visual screenshot implicitly, but does not explicitly contrast it with siblings like chrome_screenshot or browser_snapshot.

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?

Gives clear usage context: 'Take one before clicking or typing.' This tells the agent when to call it, but does not state when to avoid it or name an alternative tool.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds the useful clarification that the status refers to the real logged-in Chrome bridge rather than a headless browser, but says nothing about what the reported status looks like or failure modes.

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 front-loaded sentence with no filler; the essential identifying information comes first.

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 no-argument status probe with no output schema, the description leaves the return values (e.g., connected/disconnected, extension version) entirely unspecified, which is the one remaining gap an agent would care about.

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?

Zero parameters and 100% schema coverage, so there is nothing for the description to disambiguate. Baseline 4 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?

It names a specific resource (the Chrome extension bridge connection) and clarifies that the bridge targets the user's real, logged-in Chrome, so an agent can tell it apart from browser_* or chrome_* action tools. It stops short of explicitly contrasting itself with the neighboring chrome_pairing_setup / chrome_extension_reload 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 never says when to call this versus alternatives, whether it must be checked before other chrome_* calls, or what a negative result implies. The read-only diagnostic nature is only implied.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds the window-focus side effect (behavior beyond the annotations), but says nothing about what happens with an invalid or stale tabId.

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?

One short, front-loaded sentence with the action and its window side effect. Zero 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 one-parameter, no-output-schema tool whose annotations already carry the safety profile, the description covers the essential behavior. Minor gap: no indication of error behavior for an invalid tabId or whether focus is mandatory.

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 single tabId parameter is documented there (including the 'default: active tab' note). The description adds no format, range, or sourcing detail beyond the schema, so baseline 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?

Specific verb+resource: 'Activate a tab and focus its window' clearly distinguishes it from siblings like chrome_list_tabs, chrome_new_tab, and chrome_close_tab. It stops short of naming those siblings explicitly, but 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?

No guidance on when to switch tabs versus creating (chrome_new_tab) or listing (chrome_list_tabs) them, and no note on prerequisites such as the tab already existing or being reachable. The agent must infer the usage 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds useful behavioral context: it replaces the current value unless append is true, and submit: true presses Enter afterward. It does not mention auth, rate limits, or failure behavior, but this is solid additional detail beyond the annotations.

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. Core action comes first, followed by the important append and submit modifiers.

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 destructive annotation, no output schema, and a mutation-oriented tool, the description covers the essential behavioral modifiers. It leaves out explicit ref provenance from chrome_snapshot, but the schema's snapshotId field hints at that dependency.

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 compensates by explaining append and submit semantics, plus the core ref and text roles. However, it does not fully document all seven parameters, and some context such as where ref originates from is left implicit.

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 and resource: focus an element by ref and type text. It distinguishes the action itself, but does not explicitly differentiate it from sibling tools like browser_type or chrome_press_key.

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?

It implies the tool is used to type text into a referenced element, but gives no explicit guidance on when to choose it over browser_type, chrome_click, chrome_press_key, or other alternatives. No when-not-to-use conditions are mentioned.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds nothing beyond the name: it doesn't say whether directory copies are recursive, whether existing destinations are overwritten, or what happens on partial failure (the allowPartialUndo param hints at snapshot limits). With annotations doing the disclosure work, this minimal description is weak but not contradictory.

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 with zero waste and the verb front-loaded, which is structurally fine. But the brevity comes at the cost of substance rather than being earned 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?

For a destructive mutation tool with two undocumented required parameters (source, destination) and no output schema, the definition is far too thin. Annotations cover the safety signal, but the description leaves overwrite semantics, recursive directory behavior, and the partial-undo limitation entirely unexplained.

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 25%: source, destination, and overwrite are undocumented in the schema, and the one-sentence description adds no meaning for any of the four parameters. It fails to compensate for the coverage gap, e.g. it never mentions that copying can overwrite an existing destination.

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?

States a specific verb and resource ('Copy a file or directory'), so the operation is unambiguous. However, it offers no differentiation from the closely related sibling move_path or delete_path, which an agent selecting among filesystem tools would benefit from.

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 when-to-use, when-not-to-use, or alternative guidance is provided. The purpose implies copying rather than moving or deleting, but nothing routes the agent between copy_path, move_path, and delete_path.

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?

Annotations already declare destructiveHint=true and non-idempotent, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: deletions are recoverable via checkpoint_rewind, and the recursive flag governs whether directories are affected at all. It stops short of describing failure modes or snapshot limits.

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 tight sentences with the primary action front-loaded and the recovery mechanism stated second. Nothing is wasted and no clause is self-evident 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 destructive mutation with no output schema, the description covers undo and recursive scope, which is the essentials. It omits edge cases an agent needs: behavior on non-empty directories, permission requirements, and whether path must exist or can be relative.

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 67% and the description adds real meaning for 'recursive' (controls directory deletion) and echoes partial-undo semantics for allowPartialUndo. But 'path' remains an uninformative 'Path' string in the schema with no format guidance (relative vs absolute), so the description does not fully compensate for the coverage gap.

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?

States a specific verb and resource ('Delete a file') and explicitly handles the directory case via the recursive flag, so the scope is unambiguous. There is no sibling delete tool to differentiate from, so it earns a 4 rather than a 5.

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?

It gives the branch condition for recursive (directories) and points at checkpoint_rewind for recovery, which is useful implicit guidance. However, it never says when to prefer this tool over alternatives such as moving to trash, nor what happens when a non-empty directory is deleted without recursive.

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?

Adds substantial context beyond the annotations: unique-match semantics for oldText, replaceAll override, atomic in-order application of edits, and reporting of diagnostics plus a checkpoint id. Annotations cover destructive/idempotent flags; the description enriches with matching and atomicity rules the annotations do not convey.

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 compact sentences, front-loaded with the core action, then input modes, then matching/atomicity rules, then return info. Every clause carries information; no 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 destructive mutation with no output schema, the description gives matching rules, atomicity, diagnostics, and checkpoint id – the essentials an agent needs. It omits how to recover via checkpoint_rewind and leaves expectedSha256 unexplained, so it stops short of fully 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 only 43%, and the description compensates by explaining the exact-match requirement (once unless replaceAll), the dual mode (oldText/newText or edits array), and atomic sequencing. It leaves path, check, and expectedSha256 without added meaning, but covers the highest-risk parameters well.

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?

States a specific verb (Replace) and resource (exact text in one file), and distinguishes itself from write_file and apply_patch by restricting to exact-text replacement. An agent can tell this apart from its sibling editing tools immediately.

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 the two mutually exclusive input modes (oldText/newText vs edits array), which is usage-relevant, but never states when to prefer this over write_file or apply_patch. No explicit when-to-use reasoning is given.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior: redirects are followed automatically and output is converted to readable text versus a raw body. It omits truncation behavior from maxChars, error/timeout handling, and auth requirements, which matters for open-world fetching.

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 tight sentences with no filler; the core behavior is front-loaded and the mode flag is explained immediately after. Every clause 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?

There is no output schema, so the description is the only source for return-value expectations; it hints at 'readable text' vs raw body but says nothing about truncation limits or failure modes. Adequate for a simple fetch, but leaves an important gap around maxChars given zero schema coverage.

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 0%, so the description must carry the semantic load. It explains 'raw' well, but leaves maxChars (default 40000) undocumented — an agent cannot tell whether exceeding it truncates, errors, or paginates — and says nothing about url beyond the obvious.

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?

States a specific verb (fetch) and resource (URL), plus a behavioral detail (follows redirects) and the output shape (readable text). It is clear what the tool does, though it does not explicitly differentiate itself from siblings like browser_navigate or browser_get_text that also retrieve page content.

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 'raw: true' note gives a concrete use case (JSON/APIs) for one mode, which is real usage guidance. However, there is no guidance on when to prefer this over browser_get_text, browser_navigate, or web_search in a large sibling set, leaving the primary routing decision to inference.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description usefully discloses the concrete return fields (type, size, modification time), which is the main value it adds and which matters since there is no output schema. It does not state behavior on missing paths (error vs. false) or permission requirements.

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 front-loaded sentence that conveys purpose and return values with zero waste. Size is well matched to a simple one-parameter 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 probe with full annotation coverage and no output schema, the description adequately conveys both the operation and the returned fields. It only falls short on edge-case behavior for non-existent paths and routing away from check_files.

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?

Single parameter with 100% schema coverage, so the schema already documents 'path' (albeit minimally as 'Path'). The description adds no format or meaning beyond what the schema provides, making baseline 3 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?

States a specific verb and resource (check path existence) plus the returned attributes (type, size, mtime), so the purpose is unambiguous. It does not distinguish itself from the overlapping sibling check_files, leaving some ambiguity about which to pick.

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 when-to-use or when-not-to-use guidance, and no mention of the natural alternative check_files or the broader list_directory. The agent must infer usage context on its own.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the glob semantics that make the operation predictable, but it omits the maxResults default cap (500) that bounds results, which is relevant behavior for a finder.

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 tight sentence with the purpose front-loaded and examples doing useful work. No filler, though the brevity contributes to the coverage gaps elsewhere.

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 file finder with annotations covering safety and no output schema, this is nearly complete, but gaps remain: the maxResults default/cap, the meaning of path, and any routing versus list_directory or search_code.

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 33%, so the description must compensate, and it partly does by illustrating valid pattern syntax ('**/*.test.js'). However it says nothing about path (root directory) or the maxResults cap, leaving two of three parameters to the bare 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?

States a specific verb and resource ('Find files') and adds glob-pattern examples that clarify the mechanism. It does not explicitly distinguish itself from siblings like list_directory or search_code, but the glob framing gives it a recognizable identity.

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 offers no when-to-use guidance and names no alternatives. It never says when to prefer globbing here versus search_code or list_directory, so the agent must infer selection from the name alone.

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?

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds that references are matched as whole words, which is useful behavioral detail, but it says nothing about reference truncation despite the maxReferences default of 80.

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 tight sentence that front-loads the primary action (finding definitions) before the secondary one (finding usages). No waste.

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 6-parameter tool with no output schema, the description omits what results look like and how maxReferences truncates them. It covers the core intent but leaves the agent guessing about result shape and truncation 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 only 50%, so half the parameters (name, references, maxReferences) are undocumented in the schema. The description partly compensates by clarifying the name format and whole-word reference semantics, but leaves the references toggle and the 80-reference cap unexplained.

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?

States a specific verb (find) and resource (symbol definitions and usages), and names the accepted input formats (name or Container.name). It is distinguishable from generic siblings like search_code, though it never distinguishes itself from the very similar lsp_definition/lsp_references/vscode_find_references.

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 statement of when to use this versus the closely related lsp_definition, lsp_references, vscode_find_references, or search_code siblings. Usage is only implied by the description of what it searches.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the 'call first' behavioral cue, which is useful context. It doesn't disclose return format or any other behavioral traits, but with annotations doing the heavy lifting, a 3 is appropriate.

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: the first lists the returned information, the second gives the usage directive. It is front-loaded with purpose and wastes no 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 zero-parameter, read-only discovery tool with no output schema, the description covers what the tool returns and when to call it. It is nearly complete, though it could briefly mention if the result is cached or if it reflects live state, but that's minor given the simplicity of the 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?

The tool takes zero parameters, so there are no parameters for the description to explain. The description's enumeration of returned data gives some sense of scope, but parameter semantics is not applicable. Baseline 4 is correct for zero 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 the resource: host info, workspaces, default workspace, and available integrations. It's not a tautology like the name 'get_system_info', and it enumerates what is returned. However, it doesn't distinguish this from sibling tools like list_workspaces or capability_list, which may overlap 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?

Explicitly states when to use it: 'Call this first in a new conversation.' This is a clear, actionable directive that tells the agent exactly when to invoke the tool, with no ambiguity or exclusions needed.

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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this mutates repository state. The description usefully adds the default staging behavior ('all changes by default'), but says nothing about failure modes, empty-commit handling, or what happens to unstaged/untracked files.

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?

One tight sentence with the staging behavior front-loaded before the commit action. Nothing wasted, though it is arguably too terse given the mutation's risk profile.

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 3-parameter destructive mutation with no output schema and no annotations covering commit semantics, the description covers the core operation but omits commit-failure behavior, partial-staging implications, and the interaction with the required message parameter.

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 67%: path and files are documented in the schema, message is not (though it is self-evident and required). The description adds the meaningful default for the files parameter ('all changes by default'), which reinforces rather than merely repeats 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?

States a specific compound verb+resource: stage files and create a commit, with the default staging scope ('all changes by default') made explicit. It is clearly distinguishable from read-oriented siblings like git_status, git_diff, and git_log, though it never names 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?

No when-to-use, when-not-to-use, or prerequisite guidance. It doesn't say a commit requires staged changes, that a message is mandatory, or how it relates to git_diff/git_status as the recommended pre-step.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the output is a full unified diff, but does not disclose output size, error behavior, or pagination details.

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 sentence, front-loaded with the core purpose and parenthetically listing the supported modes. Every phrase carries information and no words are wasted.

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, the description still communicates that the return value is a full unified diff, and annotations cover the read-only safety profile. The low schema coverage and lack of ref/file syntax details leave minor gaps, but the definition is nearly complete for a simple read-only git inspection 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 description coverage is only 25%, so the description must compensate for three undocumented parameters. It maps to 'staged changes' (staged), 'against a ref' (ref), and 'optionally for one file' (file), adding meaningful semantics, but does not explain ref syntax or how staged and ref 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 states a specific verb and resource: 'Full unified diff of the working tree (or staged changes, or against a ref), optionally for one file.' It clearly distinguishes the tool from siblings like git_status and git_log by naming the exact output type and 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?

The description indicates modes of use: working tree, staged changes, against a ref, optionally one file. However, it does not explicitly compare this tool to alternatives such as git_status or git_log, nor does it state 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that — no ordering (newest-first?), no pagination semantics for the limit, no indication of what a truncated history means.

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?

It is a single four-word fragment with zero filler, so it is maximally brief, but brevity here comes from under-specification rather than disciplined editing.

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 this could be adequate, but with no output schema and one undocumented parameter, the description leaves the return shape, ordering, and limit behavior entirely unspecified.

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 50% schema description coverage, the description is expected to compensate, but it mentions neither parameter. The 'path' parameter is documented in the schema, while 'limit' has no description anywhere, so an agent cannot tell what it caps or how it interacts with the default of 15.

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 is a bare noun phrase, 'Recent commit history,' that essentially restates the tool name git_log. It gives no verb, no scope (which repo, which branch, whole history vs. HEAD), and does nothing to distinguish it from siblings like git_status, git_diff, or git_commit.

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 call this versus git_diff, git_status, or git_commit. The agent must infer that this returns a listing of past commits rather than diffs or working-tree state, with no stated conditions or alternatives.

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?

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered by structured data. The description adds useful behavioral content in that it reveals output composition (short status format plus a diffstat against HEAD), but says nothing about untracked files, staging areas, or what happens in a non-repo directory.

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 with zero waste and the key output qualifiers ('short', 'against HEAD') front-loaded. It is arguably under-specified rather than over-long, but it is efficiently structured.

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, the description must convey what is returned; it does partially by naming status-short plus diffstat. However, it omits whether untracked/ignored files appear, staged vs unstaged separation, and failure behavior outside a repository, leaving meaningful gaps for a tool an agent will use to decide next steps.

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