BrowserAgent

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

Annotations already indicate destructiveHint=true, so the description doesn't need to re-state destructiveness. It adds the behavioral detail of marking the closure in a registry, which is useful context beyond the annotation. However, it doesn't explain what the registry is, whether unsaved state is lost, or if there is any confirmation. The description provides some added context but not extensive behavioral disclosure.

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

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

The description is a single sentence of eight words, front-loaded with the action ('Close this MCP Chrome') and followed by a concise side effect. Every word contributes; there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter destructive tool with only a destructiveHint annotation, the description explains what it does and a side effect. It doesn't describe the return value, but no output schema exists, so that's not required. It could be slightly more explicit about the scope (e.g., that it closes all tabs), but the sibling tool browser_close_tab makes that distinction clear. Overall it's reasonably 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 tool has no parameters (schema coverage 100% with an empty properties object). Since there are no parameters, the description cannot add parameter meaning beyond the schema. Baseline of 4 for zero-parameter tools applies; the description's lack of parameter discussion is appropriate.

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

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

The description states a specific verb ('Close'), resource ('this MCP Chrome'), and a side effect ('mark it closed in the registry'). It clearly distinguishes from siblings like browser_close_tab (closing a tab) and browser_reap (reaping processes). The use of 'this' indicates the managed browser instance, making the intent unambiguous.

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

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

The description implies usage for shutting down the entire MCP browser instance, but does not explicitly contrast with browser_close_tab or other sibling tools. There is no 'when to use' or 'when not to use' guidance, leaving the agent to infer the distinction from the name and tool set.

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 destructiveHint annotation already marks this as destructive, and the description adds valuable behavioral context beyond it by stating "Refuses to close the last tab." This is a meaningful safety behavior that is not encoded in the schema or annotations, so the description earns credit for transparency.

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

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

The description is two short sentences with zero filler. The action and required id source are front-loaded, and the important safety refusal is stated second without redundancy or unnecessary detail.

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 destructive tool, the description covers the action, the id source, and the last-tab refusal, which is sufficient to invoke it correctly. It does not explicitly route to sibling tools or describe the result, but the output schema is absent and the tool is simple enough that this is only a minor 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?

The schema only defines id as a string with no description, and schema description coverage is 0%. The description compensates by specifying that the id comes from browser_status and is used to select the tab to close, giving the single parameter enough semantic grounding for correct invocation.

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

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

The description clearly states the verb and resource: "Close a tab by id from browser_status." It is specific enough to understand the tool's role, but it does not explicitly distinguish itself from the sibling browser_close, so the differentiation relies on the tool name and context rather than the description.

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

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

The description gives clear usage context: use an id obtained from browser_status, and the tool refuses to close the last tab. However, it does not explicitly state when to prefer this tool over alternatives like browser_close or browser_switch_tab, so no exclusions or alternative routing are provided.

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

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

Adds context that it opens Chrome if needed, which is useful. However, it does not explain the destructiveHint annotation, nor does it disclose whether the new tab is focused or how success is indicated. The description partially carries the burden beyond the annotation.

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

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

Two sentences with no filler. The core action is front-loaded, and the parameter explanation is succinct. Perfectly sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema, it covers the basic invocation, but omits important behavioral details like whether the tab becomes active, how to verify success, or why the tool is marked destructive. It is not fully complete for an agent.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly explains that the url parameter is the URL to navigate, providing meaning beyond the schema's 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: 'Open a new tab.' The description clearly distinguishes it from browser_close_tab and browser_switch_tab, but does not explicitly differentiate from browser_open. The name itself is self-explanatory.

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

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

No guidance on when to use this tool versus alternatives like browser_open or browser_switch_tab. It only instructs to pass a URL, leaving the selection 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 set destructiveHint=true, and the description adds the conditional safety note 'Safe when already open,' which is useful context. However, it does not disclose what destructive behavior occurs when the browser is not already open, leaving the risk unclear.

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

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

The description is extremely brief with no filler; the safety qualifier is a meaningful addition. The wording 'this MCP Chrome' is slightly jargon-heavy but does not harm usefulness.

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 tool, the description is minimal, but it omits the implications of the destructive hint and any expected return/behavior after opening. Given the destructiveHint annotation, an agent needs more context about the risk when the browser is closed.

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

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

The tool has zero parameters and 100% schema coverage, so the description need not add parameter details. The baseline of 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?

The description clearly states the action ('Open') and the resource ('this MCP Chrome'), distinguishing it from browser_close and browser_status. It does not elaborate on what 'open' entails (launching a new process vs. focusing an existing one), so it is clear but not fully differentiated.

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 browser_open versus sibling tools like browser_new_tab or navigate. The phrase 'Safe when already open' is a safety qualifier, not a selection criterion, and no exclusions or alternatives are mentioned.

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

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

Annotations already declare destructiveHint=true, so the description's 'Kill' aligns. The description adds context that it targets orphaned processes, which is useful beyond the annotation. However, it does not disclose potential side effects (e.g., unsaved work loss) or whether it force-kills, which would be relevant given the destructive nature.

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

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

A single, well-formed sentence that immediately states the action and target. No wasted words, and the key qualifier ('leftover... MCP agent is gone') is front-loaded. Perfectly sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless tool with no output schema and a clear destructive annotation, the description fully explains what it does and when to use it. A brief note on irreversibility or confirmation might be extra, but it is not strictly necessary given the destructiveHint annotation. The description is complete 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?

The tool has zero parameters, and the schema coverage is trivially 100% (empty properties). With no parameters to document, the description is not required to explain any. Baseline for zero parameters is 4, and no further semantic burden exists.

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 ('Kill'), a resource ('leftover Chrome'), and a condition ('whose MCP agent is gone'). It clearly differentiates this from browser_close, which would target an active session, making the tool's purpose unambiguous.

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

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

The description implies the tool is for orphaned Chrome processes after the MCP agent has terminated. It does not explicitly contrast with browser_close, but the 'leftover' and 'MCP agent is gone' conditions provide clear contextual guidance for when this is appropriate.

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 readOnlyHint annotation already establishes the non-mutating nature. The description adds value by detailing what gets listed (peers, orphans, closed instances) and explicitly confirming it does not open Chrome. This is meaningful behavioral context beyond the annotation.

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

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

Two short sentences with no filler. The core action and scope are front-loaded, and the 'does not open Chrome' caveat is immediately useful. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only status tool with no output schema, the description is sufficient. It tells the agent exactly what will be listed and what will not happen. Nothing about invocation is left ambiguous.

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

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

The tool has zero parameters, and the schema description coverage is 100%. The description correctly adds no parameter details because none exist, satisfying the baseline for parameter-free tools.

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

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

The description uses a specific verb ('List') and identifies the exact resource ('this MCP Chrome, peers, orphans, and closed instances'). The explicit negative statement 'Does not open Chrome' distinguishes it from the sibling browser_open and makes its purpose unmistakable.

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 clearly signals that this is a status-listing tool and should not be used to open Chrome. It does not name sibling tools explicitly or give a 'use when' rule, but the context of the sibling list and the negative constraint provide strong practical guidance.

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

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

The destructiveHint annotation already flags the operation as destructive, and the description does not contradict it. It adds little beyond stating the state change of switching tabs; there is no detail on side effects, permissions, or failure behavior, but the annotation lowers the burden.

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 whole description is one short sentence that immediately states the action and the source of the id. There is no filler, and the essential instruction is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a single required string parameter, no output schema, and a destructiveHint annotation, the description is mostly sufficient: it names the operation and where the id comes from. It does not cover invalid-id behavior or the prerequisite that a browser session exists, but those are minor gaps at this complexity.

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

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

With schema description coverage at 0%, the description is the only place that explains the id parameter. It states the id is a tab id and that it comes from browser_status, which is meaningful and actionable, though it does not spell out format or existence requirements.

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

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

The description uses a specific verb ('Switch') and identifies the resource ('this MCP Chrome') and the id source ('from browser_status'). It clearly describes selecting an existing tab, which differentiates it from sibling tools like browser_new_tab and browser_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?

It implies the workflow of calling browser_status first to obtain the tab id, but it never says when to prefer this over browser_new_tab or browser_close_tab, nor does it provide exclusions. The usage context is present only implicitly, not 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?

The annotations already declare destructiveHint=true, covering the destructive nature. The description adds the constraint that it applies to a 'working task', suggesting it may only affect in-progress tasks, which is useful but not elaborated. It does not contradict the annotations and provides minimal extra behavioral context beyond what is already structured.

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, compact sentence with no wasted words. It is front-loaded with the primary action, though the parenthetical '(Tasks extension fallback)' is slightly cryptic and could be more transparent. Overall it is concise and structurally sound.

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 destructiveHint annotation, the description still leaves significant gaps: the parameter is undocumented, there is no mention of what happens to the task after cancellation (e.g., status change, irreversibility), and no behavior for edge cases (e.g., task not found or already completed). The description does not fully enable 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 explain the 'id' parameter at all. The tool has one required parameter, but neither the schema nor the description provides any meaning (e.g., what id refers to, how to obtain it). The description must compensate for the low schema coverage but fails to do so.

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 'Cancel a working task' states a specific verb and resource, clearly distinguishing it from sibling tools like get_task, list_tasks, and wait_task which read or monitor tasks. The parenthetical '(Tasks extension fallback)' adds useful context about its role. This is specific and unambiguous.

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

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

The description offers no explicit guidance on when to use this tool versus alternatives. It implies it is for tasks that are 'working', but there is no mention of when canceling is appropriate (e.g., task stuck, no longer needed) or when to prefer waiting or checking status instead. No exclusions or alternative pointers are provided.

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

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

Annotations provide destructiveHint=true but the description adds no behavioral context beyond the bare verb. It does not disclose possible side effects such as navigation, form submission, or state changes, nor any confirmation behavior. The description neither contradicts nor meaningfully supplements the annotation; with a destructive hint present, some elaboration would add value.

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 is maximally concise for what it conveys, though the brevity comes at the cost of missing valuable context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, no-output-schema tool, the description is minimally adequate - an agent can infer the basic action. However, given destructiveHint=true and an unexplained uid provenance, an agent acting on this description alone could click the wrong element or trigger an unintended side effect without warning.

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 schema only defines uid as a plain string. The description adds minimal meaning by tying uid to 'the element identified by,' but it does not explain what a uid is, where it originates (e.g., from an observe call), or how to obtain a valid one - information an agent needs since the schema provides no detail.

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 ('Click') and resource ('the element identified by uid'), which is clear and unambiguous. The verb itself distinguishes it from sibling interaction tools like type, hover, scroll, select, and press, even without explicit differentiation wording.

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 press, hover, or select, nor any exclusions or prerequisites. The implied usage is only that clicking is needed for an element, but no context is provided about when clicking is appropriate versus other interactions.

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 only declare readOnlyHint=true; the description adds genuine behavior: it populates uids in the flow and, when a name fails to bind uniquely, returns candidate matches instead of erroring. 'Does not act' reaffirms the read-only safety profile and is consistent with the annotation. No contradiction present.

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 short sentences with zero waste: the core operation first, the mechanism second, the constraint third, and the negative scope last. Every sentence earns its place and the most decision-relevant information is front-loaded.

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 essentials for a read-only compile tool are present: input (a run_flow), purpose (fill uids against the live outline), failure mode (candidates on ambiguous names), and absence of side effects. The gap is that the success return value is only implied by 'fills uids' with no output schema to fill the void, and requireExpect remains 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?

The schema has 0% description coverage and its parameter names (steps, requireExpect) carry little meaning on their own. The description adds domain context — that steps is a run_flow whose names must bind against the live outline — which clarifies the main parameter. But requireExpect is left entirely unexplained, so compensation for the schema gap is only partial.

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 ('Compile'), a resource ('a run_flow against the live outline'), and the operation's effect ('Fills uids'). The closing 'Does not act' draws a clear line against the sibling run_flow, which exists to execute. The purpose is immediately identifiable.

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?

'Does not act' communicates the boundary to run_flow, the obvious execution sibling, telling the agent this tool prepares a flow rather than runs it. The unique-binding condition also tells the agent what input state is required for a clean compile. However, it never names run_flow or states explicitly 'use run_flow when you want execution,' so the routing is implied rather than spelled out.

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, and the description adds the behavioral trait that it asks the user for confirmation. This is useful but minimal; it does not disclose whether the tool blocks execution, what happens on user refusal, or any side effects beyond the confirmation interaction.

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

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

The description is a single clear sentence with no wasted words and front-loads the primary behavior. However, it is slightly too sparse to be an excellent description given the parameter richness, so it loses a point for lack of structural detail.

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 parameters, no output schema, and only a destructive hint annotation, a one-line description is insufficient. The description leaves the semantics of 'responses' and 'requestState' unexplained, and does not clarify what the user is being asked to confirm or how the confirmation result is communicated back.

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 explain any of the three parameters (message, responses, requestState). The required 'message' is only implicitly referenced by 'Ask the user', while 'responses' and 'requestState' are entirely undocumented. The description fails to compensate for the absent 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 clearly states the tool asks the user to confirm a potentially destructive action, which is a specific verb-resource pair and unique among the siblings. It lacks detail about what 'action' refers to, 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?

The description implies this tool should be used when an action is potentially destructive, but it does not explicitly state when to use it versus alternatives or provide exclusions. The context is enough for a competent agent to infer the general trigger condition, but explicit guidance is missing.

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 readOnlyHint annotation already covers the safety profile, and the description adds that the tool produces a summary and annotation. It does not clarify what 'annotation' means or describe any further behavioral context, but it does not contradict the annotation either.

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

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

The description is a single sentence that front-loads the action and the main input categories. It is appropriately concise and contains no filler, though its brevity contributes to the lack of parameter detail.

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 seven-parameter tool with no output schema, the description is under-specified: it does not explain the conditional parameter groups, the expected shape of 'diff', or what exactly the tool returns. The available annotation covers only read-only safety, not the invocation details an agent needs.

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 0% schema description coverage, the description must compensate by explaining parameter meaning, but it only lists the conceptual kinds. It does not map 'uid', 'region', or 'diff' to the relevant parameters (uid vs. x/y/width/height vs. diff), leaving an agent to infer which optional parameters apply for each kind.

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

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

The description uses a specific verb ('Explain') and names the three distinct resources it handles ('uid, region, or diff'), with a clear output hint ('summary and annotation'). It distinguishes itself from the browser and task sibling tools because none of them overlap with this explanation function.

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

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

The description implies when the tool applies by enumerating the valid input kinds, but it does not explicitly state when to prefer this tool over an alternative or when not to use it. Since no sibling tool fills a similar role, this omission is noticeable but not severely damaging.

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?

readOnlyHint=true already reveals the read-only nature, and the description adds little beyond that. 'Tasks extension fallback' hints at an execution context but does not describe response behavior or edge cases such as missing ids.

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

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

The description is a single, front-loaded sentence with no filler. Every word earns its place, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read-only lookup, the description is nearly sufficient: it names the resource, the lookup key, and the read-only nature via annotations. A brief note about the return value or failure behavior would complete it, but nothing essential is missing for selecting and invoking 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?

With 0% schema description coverage, the description needed to fully explain the id parameter, but it only repeats that lookup is 'by id'. No id format, examples, or semantics are provided, so an agent must infer the expected value from the parameter name 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 action and resource: retrieving a task by its id. This differentiates it from list_tasks, cancel_task, and wait_task, though the phrase 'Tasks extension fallback' adds context that is somewhat ambiguous without further explanation.

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 'fallback' wording implies this tool is used under a particular extension condition, but it never explicitly states when to choose get_task over alternatives like list_tasks or wait_task. No exclusions or comparison to sibling tools are provided.

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

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

The annotations already mark destructiveHint=true, but the description adds no behavioral context beyond the verb itself. It does not disclose side effects, timing, or conditions under which hovering may be destructive, so it provides little transparency beyond what annotations already 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 one concise, front-loaded sentence with no filler. Every word carries meaning and the action/resource are stated directly.

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 single-parameter action with no output schema, the basic call is covered, but the description omits usage context, how uid is obtained, and why destructiveHint=true applies. It is minimally viable but not 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?

With 0% schema description coverage, the description partially compensates by indicating that uid identifies the element. However, it does not explain the uid's format, source, or validity, leaving meaningful semantic gaps for the single 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?

The description uses a specific verb ('hover') and resource ('the element identified by uid'), making the action unambiguous and distinguishable from siblings like click, type, and scroll. It clearly communicates what the tool does.

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

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

The description gives no guidance on when to use hover versus alternatives such as click or watch_until, and does not mention prerequisites or conditions where hovering would be inappropriate. The statement is essentially the action itself, not usage counsel.

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 annotation readOnlyHint=true already covers the side-effect profile. The description adds that it lists recent calls and includes durationMs/resultBytes, but it does not disclose behavioral details such as ordering, pagination, time window, or any limits. With annotations present, the bar is lower, but the description still misses easily communicated behavior.

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

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

The description is a single, front-loaded sentence with no redundant words. It states the verb, resource, and included fields in an efficient structure that is immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter tool with no output schema, the description provides the core purpose but leaves ambiguity around what 'recent' means (time window), the maximum number returned, ordering, and return format (array vs object). These gaps are not filled by the schema or annotations, so the description is minimally viable but not 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?

There are zero parameters, so the baseline is 4. The description correctly omits parameter information, and no parameter semantics are needed since the schema is empty. No deduction is warranted.

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

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

The description uses a specific verb ('List') and resource ('recent MCP tool calls') and names the returned fields (durationMs, resultBytes). This clearly differentiates it from sibling tools like list_tasks or browser operations, so an agent can identify its exact 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?

Usage is implied: when you need to inspect recent tool call performance. However, it does not explicitly state when to use this tool versus alternatives, nor any temporal or scope conditions. The absence of similar siblings reduces the need, but the guidance remains implicit rather than explicit.

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=true, so the description does not need to repeat that listing is safe. It adds scope ('every task in the store') and a fallback qualifier, but it does not disclose return format, ordering, empty-store behavior, or any side effects; with annotations present this is acceptable but 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?

The description is a single compact sentence with the main action front-loaded. The parenthetical is somewhat cryptic, which prevents a perfect score, but there is no filler or redundant schema repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only list operation the description is mostly sufficient, but it omits any hint about what the returned data looks like and does not clarify the 'fallback' scenario. Since there is no output schema, a bit more return-value or usage context would make it 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 tool has zero parameters and the schema is therefore fully self-describing. No parameter explanations are required, so the baseline of 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?

The description uses a specific verb ('List') and a clear resource scope ('every task in the store'), which distinguishes it from single-task tools like get_task. The parenthetical 'Tasks extension fallback' adds context but is vague and does not clearly differentiate from siblings such as list_calls.

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 list_tasks versus alternatives. The word 'fallback' hints at a particular context, but the description never names sibling tools or states conditions that would make this the correct choice, leaving the agent to infer usage.

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

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

The description simply says 'Navigate the page to a URL' and adds no behavioral detail beyond the destructiveHint annotation. It does not mention whether the tool waits for page load, resets state, or how it affects the current page, so it provides no additional transparency.

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

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

The description is a single, concise sentence that is easy to parse. It is appropriately front-loaded with the action and target, though it is arguably too minimal to earn a 5.

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, this might seem sufficient, but the presence of sibling tools like browser_new_tab and browser_open creates ambiguity about the scope (current tab vs. new tab). The description does not resolve this, leaving the definition incomplete for correct tool selection.

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 'url' parameter has 0% schema description coverage, and the description only says 'to a URL' without adding any format, constraints, or meaning beyond the schema. The description fails to compensate for the lack of schema documentation.

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 ('page') with a clear target (URL). It is unambiguous about the action, but it does not differentiate from sibling tools like browser_open or browser_new_tab, so it misses the 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_open or browser_new_tab. The description gives no context about the current tab vs. a new tab, leaving the agent to infer the intended use.

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

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

With readOnlyHint=true, the safety profile is already established. The description adds meaningful behavioral context by explaining that outline yields labels and full yields a screenshot, which clarifies what the tool actually returns beyond the annotation.

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, purposeful sentences. The core purpose is front-loaded, the sibling routing is immediate, and the parameter guidance is compressed without losing meaning. Every sentence 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 tool with one optional parameter and no output schema, the description is complete: it states the action, explains the only parameter values, and routes to the relevant sibling. Nothing essential is missing for an agent to call it correctly.

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

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

Schema coverage is 0%, so the description carries the full burden for the detail parameter. It completely maps both enum values to concrete behavior, leaving no ambiguity about what detail=outline and detail=full produce.

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

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

The description opens with 'Read the page,' a specific verb and resource that clearly identifies the tool's core function. It distinguishes itself from siblings by explicitly naming run_flow as the alternative for name/role/near-based interactions, so an agent can separate observe from other browser 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 gives concrete direction: prefer run_flow when selecting by name/role/near, and choose detail=outline for labels versus detail=full for a screenshot. It does not enumerate all alternatives, but it covers the most likely confusion point and gives a clear branch for the parameter.

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

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

The destructiveHint annotation is present, but the description adds no behavioral detail beyond 'press a key' — it does not say what side effects can occur (e.g., navigation, shortcut triggering, form submission) or what exactly is destroyed. With the annotation carrying the only risk signal, the description contributes little transparency.

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

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

The description is short and front-loaded with no filler, but it is terse to the point of underspecification: 'on the page' is vague and the keyboard semantics are implicit. It is concise but not optimally structured to support correct invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and a required key parameter, the description does not explain how to format key values, whether modifiers are supported, or what the tool does after the key press. The destructiveHint marks risk without explaining when or why, leaving the agent to guess at invocation details.

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 is a single key parameter with 0% schema description coverage, and the description does not compensate: it never specifies accepted key names, casing, modifier syntax, or examples. 'Press a key' essentially restates the parameter name and tool purpose rather than adding usable parameter semantics.

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

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

The description uses a specific verb ('Press') with a clear resource ('a key'), which is enough to distinguish it from siblings like type, click, hover, and scroll. It is slightly ambiguous whether 'key' means a keyboard key or an on-page button, 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 about when to choose press over type, click, or other sibling tools, and no mention of prerequisites such as focus or element state. The one-line description implies only the obvious use case and provides no exclusions or 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, so the description does not need to repeat destructiveness. The description adds behavioral details such as 'Re-resolves after click/navigate' and 'Optional expectUrl/expectText poll,' which go beyond the schema. However, it does not explain the implications of destructiveness, failure behavior, or return format, so it only partially discloses behavior.

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

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

The description is concise, with five short sentences each carrying a distinct piece of information. It front-loads the purpose ('Run a named sequence') and avoids redundancy. There is no fluff, making it 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?

The tool is complex (runs a sequence) with a minimal schema and no output schema. The description does not explain the format of steps, available actions, or return values. It mentions expectations but not how to specify them, and it lacks error-handling or timeout information. This is insufficient for an agent to call the tool correctly without additional context.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining the preference for name over uid and the uniqueness requirement, which are not in the schema. It also hints at step behavior (re-resolving, polling). However, it does not fully describe the structure of the 'steps' array or the available actions, so it only partially compensates 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 clear verb and resource: 'Run a named sequence.' It distinguishes from alternatives by saying 'Call once instead of observe-per-page,' and clarifies that it executes a pre-defined flow with naming preferences. This is not a tautology and provides specific, actionable information.

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 explicit usage guidance: 'Prefer name (role/near) over uid' and 'A name must bind uniquely,' which directs parameter construction. It also advises 'Call once instead of observe-per-page,' indicating when this tool is preferable. However, it does not explicitly state when not to use it or compare to other sibling tools like click/type, so it lacks full exclusion guidance.

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

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

The description adds no behavioral context beyond what the name and schema imply. It does not explain units, sign conventions, whether the scroll is relative, or any side effects. The destructiveHint annotation is present but not elaborated, and scrolling is not inherently destructive.

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

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

The description is a single, front-loaded sentence with no filler. It is concise and easy to parse, though the brevity leaves important behavioral details unstated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and only a destructiveHint annotation, the description is too sparse. An agent cannot determine what dx/dy mean operationally, how scrolling behaves at boundaries, or what side effects to expect.

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 identifies dx/dy as scroll deltas and uid as the element identifier, but it does not specify units, direction semantics, or whether values are relative/absolute.

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

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

The description uses a specific verb ('Scroll') and a precise resource ('the element identified by uid'), and it names the operation's inputs (dx/dy). It is clearly distinguishable from sibling tools like click, type, and navigate.

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 clearly implies when to use it: when you need to scroll an element by a delta. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for a simple scroll operation.

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 annotation declares destructiveHint=true, and the description says 'select a value' without elaborating on side effects such as triggering change events, altering element state, or whether the change is permanent. Since annotations exist, the bar is lower, but the description adds no behavioral context beyond the annotation's destructive hint.

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

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

The description is a single concise sentence, front-loading the action. It's not verbose, but the brevity comes at the cost of missing important context. It earns a 4 because it's efficient and to the point, though not optimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two required parameters, no parameter descriptions, no output schema, and no usage guidance, the description is inadequate. It doesn't explain what types of elements support selection, what the value should be, or any side effects, leaving an agent with insufficient information 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 only implies that uid identifies the element, but the 'value' parameter is entirely unexplained—what format, allowed values, or semantics. The description adds minimal meaning beyond the parameter names themselves.

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 a specific verb (select) and resource (element identified by uid), which distinguishes it from siblings like click or type. However, it doesn't specify the type of element (e.g., dropdown, list) or the nature of the value, so it's clear but not maximally specific.

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

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

No guidance is given on when to use this tool versus alternatives. Among many browser automation siblings, there is no mention of scenarios where 'select' is appropriate or when other tools like 'click' or 'type' should be used instead. The context is entirely absent.

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 annotation destructiveHint=true already signals that this operation modifies state, so the description does not need to repeat that. However, the description adds no behavioral context beyond the annotation, such as whether typing overwrites existing content, appends, or triggers events. It neither contradicts the annotation nor enriches it.

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

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

The description is a single sentence with zero filler. Every word contributes to the meaning, and it is immediately front-loaded with the verb and resource. This is an exemplary model of 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 simple two-parameter tool, the description covers the basic action but lacks usage context and any details on return values or side effects beyond the annotation. Given the presence of sibling tools and the absence of an output schema, more could be said about when to use it or what happens after typing, but the minimal description is sufficient for a straightforward action.

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 semantics. The sentence implicitly defines 'uid' as the element identifier and 'text' as the content to type, which is helpful given the property names. However, it does not explain formats, lengths, or any constraints, leaving gaps that an agent might need to know.

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 verb ('Type') and resource ('text into the element identified by uid'). It distinguishes the tool's action from siblings like click, hover, or select, but does not explicitly name any alternatives. The purpose is unambiguous and directly maps to the tool's function.

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

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

No guidance is provided on when to use this tool versus alternatives like 'press' or 'select'. There is no mention of context such as text input fields, event triggering, or when not to use it. An agent must infer usage from the tool name and description 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?

The annotation readOnlyHint=true already signals the tool is non-mutating, and the description aligns with that. The phrase 'return evidence' adds a small behavioral detail about the output, but the description does not explain what happens on failure (e.g., throw vs. return false) or what the evidence structure looks like, especially with no output 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?

The description is a single, front-loaded sentence with no filler. It quickly communicates the core action and outcome without redundancies, achieving maximum conciseness while still being grammatical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, an enum of five condition kinds, and no output schema, this description is far too sparse. It fails to define what a 'snapshot' refers to, what kinds of conditions are supported, how expected is interpreted, or what evidence is returned. An agent would struggle to construct a correct invocation without seeing additional schemas or examples.

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 for parameter meaning. It does not mention uid, kind, or expected at all, nor explain how they combine for an assertion. The enum values are self-descriptive to some degree, but without guidance on the relationship between parameters, an agent cannot reliably know how to set expected or understand the role of uid.

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 specifies a verb ('assert') and resource ('condition against the current snapshot') and mentions returning evidence. It gives a general sense of a verification tool but does not enumerate what kinds of conditions can be asserted beyond what is hinted in the enum, nor does it explicitly differentiate from siblings like observe or watch_until.

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

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

No guidance is given on when to use verify versus alternatives. There is no mention of when an assertion is preferred over observe or watch_until, nor any conditions or prerequisites (e.g., requiring a page to be open). The agent is left to infer usage from the tool 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 provide readOnlyHint=true, which covers the safety profile. The description adds that the tool blocks until a terminal state or timeout, which is useful context. However, it does not disclose what happens on timeout, whether it returns or throws, or how terminal states are defined.

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 verb and resource, and contains no filler. Every word carries meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is too sparse for a tool with two required parameters, no output schema, and no parameter descriptions. An agent cannot reliably call it without knowing timeout units or the result/error behavior on timeout.

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 0% schema description coverage, the description must explain both parameters. It implicitly links id to the task and timeout to a duration, but it does not specify the unit of timeout (e.g., seconds vs milliseconds), id format, or behavior when the timeout value is zero or negative.

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

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

Description states a specific operation (block), a specific resource (task), and a precise condition (terminal state or timeout). It is immediately distinguishable from siblings like get_task, list_tasks, and cancel_task, which do not block.

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

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

No guidance is given on when to choose wait_task over alternatives such as get_task, list_tasks, or watch_until. The description implies a use case but provides no explicit when-to-use, when-not-to-use, 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?

The description adds behavioral context beyond the destructiveHint annotation by stating that the tool polls and is bounded by a timeout. It does not, however, explain any destructive side effects implied by the annotation, nor what happens after the timeout elapses, leaving the behavioral profile only partially transparent.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the action and termination behavior, making it 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 three required parameters with no schema-level descriptions, no output schema, and a destructiveHint annotation, yet the description does not explain parameter semantics, timeout outcomes, or return behavior. An agent would lack essential details needed to invoke the tool 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?

With 0% schema description coverage, the description needed to explain the parameters, but it only mentions a generic 'condition' and 'timeout.' It does not clarify the meaning of the kind enum values (text, uid, role, event), the format of value, or the units for timeout.

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

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

The description clearly identifies the action ('poll the page') and the termination condition ('condition matches or the timeout elapses'). It is specific enough to convey the tool's core purpose, but it does not explicitly distinguish itself from siblings like observe or wait_task.

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 a usage context: use this when you need to wait for a page condition. However, it gives no explicit guidance about when to prefer this tool over alternatives, nor any when-not-to-use conditions or exclusions.

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