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

The description discloses return format {ok, got} and lists all assertion kinds with their parameter dependencies. However, it does not mention timeouts, error handling, or whether assertions are soft or hard. Given no annotations, this is adequate but not 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?

Two sentences efficiently convey purpose and key details without redundancy. Every sentence adds value.

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

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

The description covers all assertion kinds and return format, which is sufficient for a read-only tool. No output schema exists, so return format disclosure is helpful. Could mention retry or polling behavior, but not essential.

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 60% description coverage; the description adds meaning by explaining which kinds require a target selector and how the 'value' parameter is used (URL fragment, text). This compensates for schema gaps.

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

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

The description clearly states the tool asserts a condition on the page, listing specific kinds (url-contains, url-equals, etc.) and noting requirements for some kinds. This distinguishes it from sibling tools like browser_navigate or browser_click.

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

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

The description implies use for checking page state but does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives. No exclusions or comparisons with sibling tools 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?

No annotations provided, so the description must carry full burden. It states the action but does not disclose any behavioral traits such as whether it reverts to defaults, requires an active tab, or has side effects.

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

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

The description is extremely concise with one sentence. However, it lacks structure (e.g., no separation of purpose and usage). It is efficient but could be better organized.

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

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

Given no output schema, no annotations, and a single parameter, the description should provide more context about parameter usage and behavioral details. It is insufficient for an agent to reliably invoke 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 input schema has one parameter (tabId) with no description, and the tool description does not explain what tabId is for. With 0% schema description coverage, the description adds no value for parameter understanding.

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

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

The description clearly states the action ('Clear') and the resources ('viewport / UA / touch emulation overrides'). It uniquely identifies what the tool does, distinguishing it from sibling tools like browser_emulate_viewport.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description is simply a statement of function without context for 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?

Discloses use of 'real CDP mouse events' and caching that survives restarts, adding transparency beyond the schema. However, lacks details on whether the tool scrolls into view, waits for element interactability, or behaviors on errors (e.g., element not found).

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 concise sentences that front-load the main purpose and then explain the caching feature. No wasted words.

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

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

Covers main action and caching, but does not describe return value (e.g., success indicator or error) or error handling. Given no output schema and no annotations, more detail on expected outcomes would be beneficial for completeness.

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

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

Adds value by explaining the caching mechanism for intent parameter and emphasizing that refs come from browser_snapshot. Schema already has decent parameter descriptions, but the description clarifies the intent caching behavior which is not obvious from the schema 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?

Clear verb ('Click') and resource ('element by CSS selector via real CDP mouse events'). Distinguishes from siblings like browser_click_at (coordinate-based) by emphasizing CSS selector and CDP mouse events. Caching mechanism via intent further differentiates.

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

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

Description implies caching use case but does not explicitly state when to use this tool versus alternatives like browser_click_at or browser_snapshot for retrieving refs. No guidance on prerequisites (e.g., snapshot needed) or 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?

Description only mentions coordinate-based clicking with viewport relativity. No annotations provided, so description must cover behavioral aspects but omits details like event simulation, scrolling, or out-of-bounds handling. Adequate for a simple action but minimal.

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

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

Single sentence, 14 words, front-loaded with key information. Could include brief parameter notes without losing conciseness.

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

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

With 5 parameters, no output schema, and no parameter descriptions, the description is incomplete. It provides usage context but fails to document parameters or return behavior, leaving significant gaps for the agent.

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

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

Schema description coverage is 0%, yet the description does not explain any parameters beyond hinting at x and y. It misses button, clickCount, and tabId, leaving the agent to infer their meanings from the schema 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?

Clearly states it clicks at exact CSS pixel coordinates relative to the viewport. Differentiates from sibling tools like browser_click by specifying it's for use when no good selector exists.

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 says 'Useful with screenshots when no good selector exists', guiding the agent to use this tool over selector-based 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?

Without annotations, the description discloses that this is a destructive action (closing a tab) and includes a constraint, but it does not specify error behavior (e.g., if tabId is invalid or if it is the primary tab) or any side effects. Additional transparency would improve this.

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, straightforward sentence with no unnecessary words. It is efficiently front-loaded with the main action and constraint.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the core purpose and a constraint, but it lacks parameter explanation and return/error information, making it only partially complete for reliable agent use.

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

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

The schema has no description for the 'tabId' parameter, and the description does not clarify what the number represents (e.g., index, ID from list_tabs?). With 0% schema coverage, the description fails to add meaning; the agent has no guidance on how to obtain or use tabId.

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 (close a specific session tab) and includes a key constraint (cannot close the primary tab), which distinguishes it from sibling tools like browser_open_tab or browser_list_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?

The mention that the primary tab cannot be closed provides some guidance on when this tool is usable, but it does not explicitly state when to use it versus alternatives or provide prerequisites or context about tab state.

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

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

With no annotations provided, the description carries full burden. It discloses eager capture on CDP attach, limit to last N messages, and the clear behavior. This is sufficient for a read-focused tool, though rate limits or return format are not mentioned.

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

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

The description is two sentences, front-loaded with purpose, and every clause adds value. No wasted words.

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

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

Given 5 parameters, no output schema, and no annotations, the description covers the tool's behavior well (capture timing, filtering, clearing). It does not describe return structure, but that is acceptable without output schema.

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 high (80%), so baseline is 3. The description adds minimal value beyond schema: e.g., 'filter by level or timestamp' mirrors schema. The 'clear=true to drain' is already in schema. The description does not significantly enhance parameter understanding.

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

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

The description clearly states it retrieves recent browser console messages and uncaught exceptions for the active tab. This is a specific verb-resource pair, and since no sibling tool provides similar functionality, it is well-disambiguated.

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 that capture starts eagerly on session start, implying usage after session attachment. It mentions optional filters and the clear parameter. However, it does not explicitly contrast with alternatives, though no sibling covers console messages.

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

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

No annotations are provided. The description lacks behavioral details such as persistence across tabs, side effects, or relationship to other emulation states. It only states 'Programmatic Device Mode via CDP' without deeper transparency.

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

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

The description is very concise with two sentences, front-loading the key purpose and options. No wasted words.

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

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

Given 7 parameters and no output schema or annotations, the description is far too brief. It omits critical context like parameter meanings (e.g., tabId, deviceScaleFactor) and does not specify return 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?

The description briefly mentions 'Preset or width/height' but does not explain the other 5 parameters (deviceScaleFactor, mobile, userAgent, tabId). With 0% schema description coverage, the description should compensate 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 clearly states the tool's function: programmatic device mode via CDP, covering viewport, DPR, mobile, and user-agent. It mentions presets and custom width/height, which distinguishes it from siblings like browser_clear_emulation and browser_window_resize.

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 viewport emulation but does not explicitly guide when to use this vs alternatives (e.g., browser_window_resize for actual window resizing) or when not to use it.

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

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

Discloses return format (serialized value or error object), mentions execution context ('run in the page context as a real user gesture'), and notes exception handling. With no annotations provided, this adequately conveys behavioral traits.

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

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

Three concise sentences with no redundant information. The most important action ('Execute JavaScript...') is front-loaded, and each sentence adds value without 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?

Covers key aspects like purpose, use cases, and return format, but leaves gaps: no information on timeoutMs, tabId, or limitations (e.g., CSP, permissions). With no output schema or annotations, these omissions reduce completeness.

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

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

Schema description coverage is 60% (low), but the description does not add details for undocumented parameters like timeoutMs and tabId. While it gives usage examples, it fails to compensate for the missing parameter 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?

Clearly states 'Execute JavaScript in the active tab via CDP Runtime.evaluate', which specifies the verb (execute) and resource (JavaScript in active tab). Distinguishes from sibling tools like browser_click or browser_navigate by focusing on arbitrary code execution.

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 concrete use cases: 'shadow-DOM traversal, reading window state, or programmatic clicks when extensions intercept the synthetic mouse events.' Implies when to use over alternatives like browser_click, though does not explicitly list when not to 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?

No annotations provided, so the description must fully disclose behavioral traits. It only hints at mutability (dropping) and a default, but does not explain side effects, errors, or what happens if the selector is not cached.

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

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

The description is extremely concise (one sentence) and front-loaded with the action, but it sacrifices completeness. It is appropriately short for a simple tool but could be more informative without significant bloat.

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 simplicity of the tool (2 params, no output schema), the description is incomplete. It does not explain the 'intent' parameter or what constitutes a 'cached selector', leaving 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 coverage is 0%, yet the description only adds partial meaning for the 'origin' parameter (defaults to current) and nothing for 'intent', leaving the agent without sufficient parameter understanding.

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

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

The description clearly states the verb 'Drop' and the resource 'cached selector', and includes a default behavior for origin, distinguishing it from sibling 'browser_recall_selector'.

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. There is no mention of prerequisites, when-to-use, or when-not-to-use, leaving the agent to infer 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?

With no annotations, the description carries full burden for behavioral disclosure. It fails to state any side effects, such as whether the page reloads, waits for navigation, or affects browser state. The description is completely devoid of behavioral traits beyond the implied action.

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

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

The description is extremely terse at two words, but this is under-specification rather than conciseness. It lacks structure and fails to convey essential information. Every sentence should add value; these words add almost none beyond the name.

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

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

Given the tool's simplicity (one parameter, no output schema), the description should at least explain the purpose and parameter clearly. It does neither, making it completely inadequate for an agent to use 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?

The input schema has one parameter (tabId) with schema description coverage at 0%. The description provides no information about tabId's meaning, constraints, or usage. This is a critical gap for a tool with a 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 'History back' is a near-tautology of the tool name, providing minimal clarification. It vaguely indicates navigation backward in browser history but lacks specificity about what resource or action is involved, and does not distinguish it from sibling tools like browser_go_forward.

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. There is no mention of prerequisites, context, or scenarios where this tool is appropriate, leaving the agent without decision support.

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

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

No annotations are provided, so the description carries full burden. It merely states 'History forward' without disclosing side effects (e.g., changes to current URL), error conditions (e.g., no forward history), or safety traits. The agent is left to infer behavior from the name alone.

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

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

The description is extremely concise at two words, but it omits essential information about the tool's operation and parameters. This is under-specification rather than effective conciseness.

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

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

Given no output schema, no annotations, and one undocumented parameter, the description is grossly incomplete. An agent cannot correctly invoke this tool without additional context about its behavior and requirements.

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 provides no information about the 'tabId' parameter. The agent cannot understand what the parameter represents or how to use it from 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?

The description states 'History forward' which implies navigating forward in browser history, analogous to a browser forward button. It is specific enough to distinguish from siblings like browser_go_back, but it does not explicitly mention that it operates on a tab or requires a tabId parameter.

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

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

No usage guidelines are provided. There is no indication of when to use this tool versus alternatives like browser_go_back or browser_navigate, nor any prerequisites or context for its 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?

With no annotations, the description carries the full burden. It mentions 'best-effort selector refs,' hinting at limitations, but does not disclose that it operates on the current tab, possible incompleteness due to dynamic content, or performance characteristics. Adequate but could be richer.

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

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

Two sentences, no redundant information. Every word earns its place. The description is front-loaded with the core purpose followed by usage hint.

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

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

Without output schema, the description mentions return fields (text, href, selector refs) adequately. However, it does not clarify that the tool requires an active tab (tabId usage) or error handling. The phrase 'best-effort selector refs' could be elaborated. Adequate for a simple tool but incomplete regarding parameters and edge cases.

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

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

Schema description coverage is 67% (two of three parameters described). The tabId parameter has no schema description, and the tool description does not explain its purpose. The query and limit parameters are adequately described in the schema. The description adds no extra meaning beyond the schema.

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

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

The description clearly states the tool returns 'compact visible links from the page with text, href, and best-effort selector refs.' The verb 'Return' combined with the specific resource (compact visible links) precisely defines the action, distinguishing it from siblings like browser_snapshot (full page snapshot) and browser_click (action).

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 includes 'Useful for navigation choices without a full snapshot,' which gives context on when to use it instead of a full snapshot tool. However, it does not explicitly state when not to use it or mention alternatives beyond the implicit comparison.

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

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

No annotations are provided, so the description must disclose all behavioral traits. It only states that it lists cached selectors, with no mention of side effects, read-only nature, output format, or whether it mutates state. This leaves significant gaps for an agent to predict 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 very short (one sentence), making it concise but potentially too sparse. It front-loads the purpose but omits necessary details. It is not verbose, but the brevity limits its 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?

Given no output schema and numerous sibling tools, the description lacks details about return values, pagination, or how to use the results. It does not explain the concept of 'cached selectors' or how this tool fits into the broader workflow. Significant gaps remain for effective tool 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 description explains the 'origin' parameter with a note that it defaults to current, adding meaning beyond the schema. However, the 'all' parameter is not mentioned at all. With 0% schema description coverage, the description should compensate but fails to fully explain 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 it lists cached selectors, which is a specific action. It also mentions filtering by origin. However, it doesn't elaborate on what qualifies as a cached selector, leaving some ambiguity. The tool's name and description differentiate it from siblings like browser_forget_selector and browser_recall_selector.

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 (list selectors, optionally filtered by origin) but does not explicitly state when to use this tool versus alternatives like browser_recall_selector for retrieving a single selector. It provides filtering guidance but lacks when-not or alternative recommendations.

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

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

With no annotations, the description carries the full burden. It only states 'List tabs', which implies a read-only operation, but does not confirm side effects, safety, or what 'current session group' means. Minimal 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, very concise and front-loaded. It could be slightly expanded to add context without becoming verbose.

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

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

Given the lack of output schema and annotations, the description is too minimal. It does not explain what 'current session group' means or what information is returned (e.g., tab titles, URLs). Incomplete for practical use.

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

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

There are no parameters, so the input schema is fully covered. The description adds no extra meaning beyond the schema, but this is acceptable given zero parameters. However, it could mention what tabs are included (e.g., all tabs in the group).

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 'list' and resource 'tabs in the current session group', making the purpose obvious. However, it does not differentiate from sibling tools like browser_open_tab or browser_close_tab, which is a minor 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?

No guidance is provided on when to use this tool versus alternatives. The description implies a simple query operation but lacks explicit usage context or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tab is made active within the window to prevent SPA throttling, that the window is not raised by default, and that bringToFront steals focus. No contradictions.

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

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

The description is two sentences, front-loaded with the main action, and every sentence adds value. No wasted words.

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

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

Given 3 parameters, no output schema, and numerous sibling tools, the description covers the main behavior, key parameter, and important nuance (focus behavior). It mentions waiting for load. Could be slightly more complete about error handling or return value, but 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 description coverage is low (33%). The description adds meaning for bringToFront (explains its effect and default), but does not add details for url or tabId beyond the schema types.

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 'Navigate' and the resource 'URL', and distinguishes from sibling tools like browser_open_tab and browser_go_back/forward through the context of an active session 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?

The description provides guidance on when to use bringToFront:true (when you want to watch), and clarifies the default behavior (does not steal focus). No explicit alternatives are mentioned, but the context is clear.

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 identifies the tool as a read operation returning network request data, with opt-in body capture. However, 'recent' is not quantified (time window unspecified), and there is no disclosure of permissions, rate limits, or whether only the active tab's requests are included (likely yes). No annotations exist to supplement.

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: the first front-loads the return data, the second adds filter and body capture options. Every sentence is informative and concise, with no wasted words. However, a more structured format (e.g., bullet points) could improve skimmability.

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 9 parameters and no output schema or annotations, the description is adequate but not comprehensive. It does not define 'recent,' specify request ordering, or explain the purpose of tabId. For a moderately complex tool, it leaves some gaps that an agent would need to infer.

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

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

The description adds meaning beyond the schema for several parameters: it explains filtering by URL substring, method, status range, or failedOnly, and clarifies that body capture requires optional flags. This is valuable given only 33% schema coverage, though tabId is not mentioned.

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

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

The description clearly states it returns recent XHR/fetch/document/asset requests for the active tab, listing attributes like method, URL, status, mime, duration, and success/failure. This verb+resource combination is distinct among sibling browser tools, which are primarily for navigation, clicking, and snapshotting.

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 what the tool does but provides no explicit guidance on when to use it versus alternatives (e.g., browser_console_messages for console logs, browser_snapshot for page state). Usage context is implied solely by the tool name and purpose, not explicitly stated.

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

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

With no annotations, the description should disclose behavioral traits like tab switching, focus, or failure conditions, but it only states the basic action. The parameters 'active' and 'makePrimary' hint at behavior not explained.

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, but it is too brief to convey necessary 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 tool with 0% schema coverage, no annotations, and no output schema, the description should provide more context about behavior and return values; it only offers a minimal action statement.

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 adds no information about the three parameters (url, active, makePrimary), leaving the agent without guidance on how to fill them.

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 (open), resource (a new tab), and context (inside the session's tab group), effectively distinguishing it from sibling tools like browser_close_tab and browser_list_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?

No guidance on when to use this tool versus alternatives such as browser_navigate or browser_list_tabs. No context on prerequisites or scenarios.

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

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

Lacking annotations, the description carries the full burden. It notes that open requires an active browser session, but does not disclose whether generation itself requires a browser, if it overwrites files, or any side effects.

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

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

The description is two concise sentences with no redundancy. Every word adds value.

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

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

Given the many sibling tools and lack of annotations/output schema, the description omits important details: dashboard content, output location default, error states, and interaction with the existing playbook library.

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 adds meaning for the open parameter (navigates to dashboard) but fails to describe outputPath (its format, default, or behavior). Only one of two parameters gains clarity.

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 ('Generate a self-contained HTML dashboard') and the resource ('the playbook library'), distinguishing it from sibling tools like browser_playbook_list or browser_playbook_run.

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 other playbook tools (e.g., browser_playbook_export). It only mentions the optional open parameter, but does not explain prerequisites 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?

No annotations provided, so the description must fully disclose behavior. It states the tool deletes data but omits critical details like irreversibility, whether it affects other playbooks, or if confirmation is needed.

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

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

Single sentence is concise and lists what is deleted. However, it could be more efficient by removing the parentheses or integrating the list more smoothly.

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 deletion tool with no output schema and one parameter, the description is incomplete. Missing details on errors, return values, and behavioral consequences. It meets the minimum but leaves 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 description coverage is 0%, and the description does not explain the single 'id' parameter (e.g., that it must be a playbook ID). The parameter's purpose is implied by the tool name but not specified.

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 'Delete' and the resource 'playbook', specifying the exact components deleted (markdown, workflow JSON, and screenshots). This distinguishes it from sibling tools like browser_playbook_get or browser_playbook_list.

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

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

No guidance on when to use this tool versus alternatives (e.g., browser_workflow_delete). No mention of prerequisites, required permissions, or conditions for safe deletion.

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?

Discloses the write/update nature (updates hashes, bumps version) but, with no annotations, could elaborate further on side effects (e.g., old references become obsolete), reversibility, or required permissions. Adequate 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?

Two efficient sentences: first states the action, second details the effects. No redundant words. Front-loaded with key verb 'bless'.

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

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

Despite clear purpose and effects, the description lacks parameter explanations, preconditions, and return value. With 3 parameters (2 required) and no output schema, the agent lacks sufficient context to use 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?

Description does not explain any of the three parameters (id, runId, steps). Schema description coverage is 0%, so the agent must guess the meaning and roles. No clarification on which parameters are required or optional.

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

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

Description clearly states the tool's purpose: bless screenshots as new reference for a playbook, with specific verbs (bless, updates, bumps) and resources (visual_refs[], playbook_version). It is distinct from siblings like browser_playbook_propose_update and browser_playbook_match.

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

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

No explicit guidance on when to use this tool vs alternatives. The description implies it is used after a run to accept screenshots, but does not mention prerequisites or when not to use it (e.g., if only reviewing diff). No exclusions or alternative tools referenced.

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

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

No annotations are provided, so the description carries full burden. It does not disclose side effects (e.g., whether export deletes playbooks), permissions required, or the effect of the `stripSecrets` parameter. The description is too brief to convey behavioral traits.

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

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

The description consists of two concise sentences. The first defines the action and output; the second adds context. It is front-loaded and contains no redundant words, though it could be slightly expanded without losing conciseness.

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

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

With 5 parameters (none documented), no output schema, and no parameter descriptions, the description is insufficient for correct invocation. An agent would not know how to use parameters like `origin` or `stripSecrets` or what the output bundle contains.

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 adds no information about any of the 5 parameters (ids, origin, tag, outputPath, stripSecrets). It only hints at 'one or more playbooks' but does not explain which parameter controls selection or how to specify paths.

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 'Export', the resource 'one or more playbooks (and their screenshots)', and the output format 'single JSON bundle file'. It distinguishes from sibling tools like browser_playbook_list or browser_playbook_get by specifying bundling and screenshots.

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 mentions 'Useful for sharing across projects or teams', giving a use case. However, it does not explicitly state when not to use it or suggest alternative tools (e.g., browser_playbook_get for a single playbook, or browser_playbook_import for the reverse).

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

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

No annotations are provided, so the description carries the full burden. It indicates a read operation returning comprehensive data, but does not discuss behavior on missing IDs, rate limits, or any side effects. Adequate but minimal.

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 is front-loaded with the action and resource. No redundancy or extra words.

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

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

For a simple get operation with one parameter and no output schema, the description sufficiently specifies what is returned. Could optionally mention error behavior, but not essential.

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% (the 'id' parameter has a description 'origin/feature'). The tool description adds no further detail beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states 'Return one playbook' and specifies the full contents (meta, body sections, workflow JSON). It uses a specific verb and resource, distinguishing it from sibling tools like browser_playbook_list which lists playbooks.

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_playbook_list or browser_playbook_dashboard. The description does not mention prerequisites or exclusions.

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

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

With no annotations provided, the description must bear the full burden of behavioral disclosure. It mentions overwriting and rewriting origins, but fails to explain side effects (e.g., whether existing playbooks are replaced without confirmation), validation behavior, permission requirements, or error handling for invalid inputs.

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 consists of two short sentences that efficiently convey the core action and optional behaviors with no redundant words. It is front-loaded with the primary purpose.

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

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

Given the tool has 5 parameters, no annotations, no output schema, and involves a complex import operation, the description is insufficient. It lacks details on return values, error states, prerequisite conditions (e.g., file format, URL accessibility), and the exact impact of the overwrite and rewrite flags.

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

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

The description adds meaning to all five parameters by mapping source names to param keys (bundlePath for local file, bundleJson for inline JSON, url for URL) and explaining overwrite and rewriteOrigin with an example. However, it does not clarify that the three source parameters are mutually exclusive.

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 ('Import a playbook bundle') and lists three source options (local file, inline JSON, or https URL), distinguishing it from sibling export tools. However, the term 'playbook bundle' is not defined, leaving some ambiguity about the expected format.

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

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

The description does not provide guidance on when to use this tool versus alternatives like browser_playbook_save or browser_playbook_propose_update. It mentions optional overwrite and rewrite but gives no context on prerequisites or exclusions.

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

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

No annotations provided, so description must disclose behavior. States it returns 'compact metadata only', implying read-only and limited data. Mentions filtering by multiple criteria. Lacks details on pagination or limits, but adequate for a list tool.

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

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

Two sentences, no unnecessary words. Action verb ('List') leads, followed by filter list and comparison with sibling. 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?

Explains output nature ('compact metadata') and link to detailed tool. Mentions all 4 parameters as filters. Lacks details on default behavior, sort order, or maximum results, but these are acceptable gaps for a simple list operation.

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 description must add semantic meaning. Explicitly names each filter parameter (origin, feature slug, tag, verifiable) as filters. Does not specify formats or allowed values, but provides sufficient context for parameter roles.

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 specifies verb 'List', resource 'per-feature playbooks', and distinguishes from sibling 'browser_playbook_get' by noting compact metadata vs full body.

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 directs to 'call browser_playbook_get for the full body', providing a clear alternative. Lists filter parameters, implying when to use filters, but does not explicitly state when not to use the tool.

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

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

The description discloses key behaviors (scoring, threshold filtering) but lacks details on side effects, read-only nature, or what happens when no matches exist. Without annotations, this is moderate 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?

Two concise sentences front-load the key action and outcome. No redundant information; every word adds value.

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

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

The description lacks details about output format, scoring algorithm, threshold value or configuration, and how to interpret results. For a matching tool without output schema, more context is needed to use it effectively.

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 description only maps parameter names to their real-world meanings (url, intent, taskText). It does not explain how they interact (e.g., logical AND/OR), formatting requirements, or provide examples. This is insufficient for a tool with 3 string 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?

Clearly states the tool finds playbooks matching a URL, intent, or task description and returns scored matches above a threshold. This differentiates it from other browser playbook tools like list, get, or run.

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

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

No explicit guidance on when to use this tool over alternatives such as browser_playbook_list or browser_playbook_get. The description implies it is for matching, but does not specify when to prefer matching over other operations.

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

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

No annotations exist, so description bears full burden. It discloses that the tool creates or updates (mutation), infers inputs and steps from the trace, and tracks selectors via cache. This adds meaningful behavioral context, though lacks details on side effects or permissions.

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

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

Two concise sentences front-load the main action (create/update from trace) and essential details. No extraneous information.

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

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

Despite good conciseness, description omits return value (no output schema) and error conditions. For an 8-param mutation tool, more detail on results and edge cases is needed.

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 high (63% per context, but actually most params have descriptions). Description adds that inputs are inferred and selectors tracked, but doesn't elaborate on parameters like title or verifiable. Baseline of 3 is appropriate as schema does most work.

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

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

Description clearly states the tool creates or updates a playbook from a successful trace, distinguishing it from siblings by specifying the inference of inputs/steps and use of selector cache. It uses a specific verb-resource pair and adds unique 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?

Description implies usage after a successful trace but provides no explicit when-to-use or when-not-to-use guidance compared to siblings like browser_playbook_save or browser_playbook_seed_from_codebase. Only minimal context 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions recursive execution and self-healing, which are key behavioral traits. However, it does not disclose potential side effects, idempotency, or error handling. Still, it adds significant context beyond 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?

The description is two concise sentences, front-loaded with the primary purpose. Every sentence adds value: 'Replay a playbook (with self-heal) using the provided inputs' is the core function, followed by two key details (recursive execution and return value). No wasted words.

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

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

For a tool with moderate complexity (recursive execution, self-heal), the description covers the main actions and output. It lacks details on error handling, prerequisites, or performance implications, but given the simple input schema, it is fairly complete. An output schema does not exist, but the description mentions the return value (verdict + evidence).

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%, with only the 'inputs' parameter described in the schema. The description does not add any explanation for the 'id' parameter or clarify the input structure beyond what the schema provides. 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 clearly states the tool replays a playbook with self-healing, executing composes/next chains recursively, and returning a verdict and evidence. It uses a specific verb ('replay') and resource ('playbook'), and distinguishes itself from sibling tools like browser_playbook_list or browser_playbook_save by focusing on execution.

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 running a saved playbook but does not explicitly state when to use this tool versus alternatives like browser_workflow_run. It lacks guidance on prerequisites or when not to use it. Given many siblings, more explicit guidelines would be beneficial.

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 mentions validation of frontmatter and required sections, which is a behavioral trait not implied by the tool name alone. Since no annotations are provided, the description carries the full burden. But it lacks details on error handling, idempotency, or side effects.

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

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

The description consists of two concise sentences with no redundant information. The first sentence states the action, and the second provides a key usage guideline. Every sentence is necessary.

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 complexity of a playbook save tool with nested objects and no output schema, the description is brief. It does not explain the structure of frontmatter or required sections, nor does it describe the optional workflow parameter. More detail would be beneficial.

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

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

Schema coverage is 100%, so each parameter's description is already given. The description adds value by stating that frontmatter and required sections are validated, which is not in the schema. This provides context beyond the schema's field 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's verb (create or update) and resource (playbook). It also distinguishes it from the sibling tool browser_playbook_propose_update by specifying its purpose for trace-driven authoring.

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

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

The description explicitly directs the agent to use browser_playbook_propose_update for trace-driven authoring, providing a clear alternative. However, it does not elaborate on when to avoid using this tool or prerequisites.

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

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

No annotations are provided, so the description carries full burden. It states 'never returns values' which is a key security trait, but it does not disclose other behaviors like whether the tool is read-only, requires authentication, or error conditions.

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

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

The description is two sentences, no redundant words, and front-loaded with the core purpose. Every sentence adds value.

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

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

For a simple one-parameter tool without output schema or annotations, the description covers purpose and return behavior adequately. However, it lacks error scenarios and return format details, which would improve completeness.

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

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

Schema description coverage is 0%, so the description must add meaning. The only parameter 'id' is implicitly a playbook ID but its format or source is not clarified. The description adds minimal value beyond the schema.

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

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

The description explicitly states the verb 'validate', the resource 'playbook secret inputs', and the action 'check resolvability'. It clearly distinguishes from sibling tools like browser_playbook_run by focusing on secret validation.

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 as a pre-run validation step but does not explicitly state when to use this tool versus alternatives. No exclusions or when-not scenarios 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?

The description explains the output state (draft version and verifiability) but lacks details on whether the tool writes to disk, requires specific project structure, or has any side effects. Without annotations, more behavioral context would be beneficial.

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 succinct sentences efficiently convey purpose and post-creation state. No wasted words.

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

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

The description explains the input (project root, domain), action (static analysis), output (draft playbooks with version and verifiability status). It covers the main workflow. However, it does not specify the expected project structure or error conditions, which would enhance completeness 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?

With only 33% schema parameter descriptions, the description should clarify the missing parameters. It implies projectRoot is the project path but does not explain dryRun or provide detailed syntax for domain. The description adds little to parameter understanding beyond the schema.

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

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

The description clearly states the tool performs static analysis on frontend codebases (Next.js, Vite/CRA) to generate draft playbooks for each route and form, distinguishing it from other playbook tools that manage existing playbooks.

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 generating initial playbooks from code, but does not provide explicit guidance on when to use this tool versus other playbook tools (e.g., manual creation, import). No exclusions or prerequisites 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?

Description mentions 'real keyboard event' implying OS-level behavior, but lacks details on focus requirements, side effects, or page navigation triggers. With no annotations, transparency is insufficient.

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

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

Single sentence, front-loaded with action. Efficient but could briefly add required 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?

Despite simplicity, description omits important context like accepted key values, return behavior, and prerequisites. With no annotations or output schema, more detail is needed.

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 has no descriptions for parameters (coverage 0%), and description adds no parameter-level information beyond the tool's purpose.

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

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

Description clearly states it dispatches a real keyboard event via CDP, distinguishing it from typing or clicking operations among 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?

No guidance on when to use press_key instead of browser_type or other input tools; lacks context for appropriate scenarios.

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

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

No annotations are provided, so the description carries the full burden. It mentions the return value (null if unknown) and implies no side effects, but does not explicitly state read-only or discuss error conditions. Adequate but could be more transparent.

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

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

Three sentences with no filler. First sentence is the action, second explains return, third provides usage context. 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 simple query tool with two parameters and no output schema, the description covers purpose, parameters, return behavior, and usage hint. Complete given the tool's complexity.

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

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

Schema describes origin's default behavior; the description adds that 'intent' is a key for lookup and ties it to 'current origin'. This adds value beyond the schema, especially since intent lacks a schema description.

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

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

The description clearly states the action: query memory for a known selector based on intent and origin. It distinguishes itself from siblings like browser_snapshot and browser_forget_selector by explaining its role as a pre-discovery check.

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 advises using this tool BEFORE browser_snapshot to skip discovery, providing clear context. It does not explicitly exclude scenarios, but the guidance is sufficient for an agent to decide when to invoke 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?

No annotations are provided, so the description carries full burden. It mentions outputs (status, pass/fail counts, timings) but does not disclose whether the operation is read-only, whether it requires any prerequisites, or any side effects. The minimal description leaves significant behavioral ambiguity.

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 immediately conveys the tool's purpose. It is concise, though at the expense of missing parameter and behavioral details, earning a 4 rather than 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?

Given the tool has 3 parameters (one required), no output schema, and no annotations, the description is insufficient. It does not explain parameter semantics, return value structure, or how the tool behaves with different parameter values. Information is missing for an informed 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%, meaning the schema provides no parameter descriptions. The description adds no details about the parameters beyond the schema; for example, it does not clarify what 'origin' means or that 'limit' controls the number of runs returned. The phrase 'Last N runs' only indirectly relates to the limit 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 clearly states it retrieves 'Last N runs of a workflow' with details on status, counts, and timings. This distinguishes it from sibling tools like browser_workflow_run (execution) and browser_workflow_get (definition retrieval).

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

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

The description implies usage when workflow run history is needed, but lacks explicit guidance on when not to use it or alternatives. It does not differentiate from similar tools like browser_workflow_run or browser_workflow_list.

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

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

No annotations exist, so the description carries the burden. It reveals that the screenshot works even if the tab is in the background and that it uses CDP. However, it does not disclose if the operation is read-only, any side effects, authorization needs, or rate limits, which is a gap for a tool with no 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?

Two sentences cover the core purpose and modes. No fluff, front-loaded with the main action. Very efficient.

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

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

The tool has no output schema and 4 parameters. The description ignores the format and tabId parameters and does not mention what the return value is (e.g., base64 image). Completeness is adequate for a simple tool but gaps remain in parameter coverage and result format.

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 adds meaning for fullPage and elementRef by naming them as modes (viewport, fullPage, elementRef). But it fails to mention the format parameter (png/jpeg) or tabId (which tab to screenshot), leaving half the parameters 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 clearly states the tool takes a PNG/JPEG screenshot of the session tab, which is a specific verb and resource. It mentions CDP-based and works in background, but does not explicitly distinguish from sibling DOM capture tools like browser_snapshot, though the difference is implied.

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_snapshot or browser_emulate_viewport. The description lists modes but does not explain when to choose each mode, leaving the agent without 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?

No annotations are provided, so the description carries the full burden. It only states the scroll modes without disclosing details such as coordinate units, whether scrolling is smooth or instant, or if it affects the entire viewport or a specific element. This is minimal.

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

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

The description is a single sentence that is front-loaded and contains no wasted words. It efficiently conveys the core action and parameter options.

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

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

Given the lack of output schema and annotations, the description is too brief. It fails to explain coordinate units, the interplay between absolute and relative parameters, or the purpose of tabId. Important context 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?

With 0% schema description coverage, the description must compensate. It explains x,y,deltaX,deltaY but omits the tabId parameter entirely and does not specify coordinate units (pixels, etc.). Only partial parameter meaning is conveyed.

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

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

The description clearly states it scrolls the active session tab and distinguishes between absolute and relative scrolling, which differentiates it from sibling tools like browser_click or browser_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 provides clear guidance on when to pass {x,y} for absolute scroll and {deltaX,deltaY} for relative scroll, but does not mention when not to use the tool 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?

Describes key behavioral traits (detaches debugger, default ungroup vs close) beyond what annotations would provide. Given no annotations, carries the burden well, though missing details on reversibility or side effects.

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

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

One sentence, front-loaded with purpose, no wasted words. Efficiently conveys all necessary information.

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

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

Given the tool's simplicity and lack of output schema or annotations, the description is fairly complete. Could mention it's the inverse of browser_session_start, but not essential.

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?

Explains the effect of the single parameter 'closeTabs' (ungroups by default, closes if true) adding meaning beyond the schema, which has 0% description 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?

Clearly states it ends the current session and provides specific actions (detaches debugger, ungroups/closes tabs), distinguishing it from siblings like browser_close_tab or browser_session_start.

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 by naming the action, but no explicit guidance on when to use this versus alternatives like browser_close_tab or when not to 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?

No annotations provided, but the description fully discloses the read-only diagnostic nature. It lists what information is retrieved, implying no destructive effects. Could be more explicit about lack of side effects, but very clear overall.

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

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

Single sentence packed with all relevant information: tool purpose, data points, and usage guidance. No redundancy, front-loaded, highly 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?

For a diagnostic tool with no parameters and no output schema, the description provides complete context: what it retrieves, when to use it, and how it relates to sibling tools. No gaps.

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

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

No parameters in schema (0 params, 100% coverage). Description doesn't need to add parameter info, and baseline for 0 params is 4. No further context needed.

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 explicitly states it provides a diagnostic snapshot of the bridge and active session, listing specific data points (bridge mode, extension connectivity, etc.). Clearly distinguishes from other browser tools by focusing on health diagnostics.

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 says 'Use when something feels stuck before reaching for browser_session_end,' providing clear context and an alternative. This tells the agent when to invoke and when not to.

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

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

With no annotations provided, the description fully discloses behavioral traits: session scoping, new window vs. tab group, focus management (brings to front once, no focus steal on navigate), and idempotency. No contradictions.

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 (5-6 sentences), front-loaded with the core purpose, and each sentence adds distinct value (scoping, newWindow, focus, idempotency). No redundant or vague phrasing.

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

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

For a complex tool with 11 parameters, nested objects, and no output schema or annotations, the description covers key behavioral context (session management, focus, new window) but omits explanations for most parameters (e.g., dimensions, position, state, visuals). The agent would need to infer parameter meanings from schema defaults/enums 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 only 18% (9 of 11 parameters lack descriptions in schema). The tool description only explains newWindow and bringToFront behaviour, leaving parameters like title, color, width, height, left, top, state, and the entire visuals nested object unaddressed. This is insufficient for an 11-parameter tool.

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 'Start a new browser session' and specifies the resource ('Chrome tab group with an initial tab; all subsequent operations are scoped to that group'). It distinguishes itself from siblings like browser_open_tab by focusing on session initiation and scoping.

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

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

The description provides explicit guidance on when to use parameters like newWindow and bringToFront, and notes idempotent behavior (ends previous session). However, it does not explicitly compare to alternative tools or state when not to use it beyond the implied 'start a new session' context.

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

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

With no annotations, the description fully discloses key behaviors: compact defaults, depth limits, caps, redaction, and viewport scoping. It also notes that passing mode='full' skips compacting. It does not discuss performance or auth, but for a browser tool these are standard.

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 compact—only three sentences. The first defines the core purpose, the second lists compact defaults, and the third provides a key usage guideline. Every sentence is essential and 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 9 parameters, high schema coverage, and no output schema, the description provides sufficient context: it explains the output (accessibility tree with refs/boxes) and how to apply it. The lack of output schema is mitigated by the clear purpose and usage hints. Minor gaps exist (e.g., what happens when store=false), but overall completeness is good.

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 high (89%), so parameters are well-documented. The description adds value by summarizing defaults and advising on mode usage ('Pass mode='full' only when...'). It also clarifies output usage ('Use refs for browser_click/browser_type'), which goes beyond schema definitions.

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 captures an 'ARIA-flavored accessibility tree with stable refs and pixel boxes', distinguishing it from visual captures like browser_screenshot or text extraction. It also references sibling tools browser_snapshot_node and browser_snapshot_query for drilldown.

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 specifies default behavior (compact, viewport-only, redacted, depth-limited, 12KB cap) and advises when to use mode='full'. It also explains that refs in the snapshot are used for browser_click/browser_type, guiding post-capture actions. However, it does not explicitly contrast with alternative tools like browser_screenshot for visual needs.

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

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

No annotations are provided, so the description carries full burden. It states that the default snapshotId uses the latest stored snapshot but does not disclose side effects, return format, or constraints (e.g., maxDepth, maxBytes, redact 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 two concise sentences with no extraneous information. It front-loads the core action and usage context efficiently.

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 7 parameters, no output schema, and no annotations, the description is too brief. It lacks explanation of parameters like maxDepth, maxBytes, and redact, and does not describe the output format. It relies heavily on schema descriptions that have low 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 57% (low), yet the description adds minimal meaning beyond listing the selection methods. It does not explain parameter interactions or provide examples. The schema descriptions already cover many parameters, so the description's contribution is limited.

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 returns a compact subtree from a browser_snapshot and specifies the selection methods (ref, text, or path). It distinguishes from sibling tools like browser_snapshot (full snapshot) and browser_snapshot_query (query).

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 'Use for targeted drilldown,' implying a specific use case. However, it does not explicitly state when not to use it or provide alternatives beyond the implicit context of sibling tool names.

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

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

No annotations provided, so description must carry the burden. It describes a read-only search operation returning excerpts, with no mention of mutations or side effects. Does not explicitly state safety, but the description is consistent with a query tool.

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

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

Two well-structured sentences. First sentence conveys action and parameters; second provides use case. No unnecessary words.

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

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

Covers main purpose, search capabilities, and when to use. Lacks details on output format (no output schema), but mentions 'tiny matching excerpts plus paths' which suffices. Adequate for a query tool with 9 parameters.

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

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

Schema coverage is 67%; description adds value for text, role, tag, ref, and snapshotId (default behavior). Enhances understanding beyond schema for search criteria. For limit, maxDepth, maxBytes, redact, schema already provides 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?

Description clearly states searching a browser_snapshot tree by multiple criteria (text/name/role/ref/tag) and returning excerpts plus paths. It distinguishes from sibling tools like browser_snapshot and browser_snapshot_node.

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 says to use this for drilling into a compact snapshot instead of a full page tree, implying when to choose it over browser_snapshot. Could be clearer about when not to use (e.g., if full node details 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?

No annotations are provided, so the description carries full burden. It describes the output as 'compact visible text lines' and mentions caps, but does not disclose whether hidden text is excluded, how line breaks are handled, or the exact return format. This is adequate but lacks detail.

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

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

The description is two sentences, front-loaded with purpose, and every sentence adds value. No wasted words.

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

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

Given the absence of an output schema, the description does not explain the return structure (e.g., array of strings with line numbers). It mentions 'lines' but not format. The tool is simple, but the missing output format is a gap 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 coverage is 75% (tabId lacks description). The description adds value beyond schema: query is case-insensitive, limit is capped at 300, maxChars at 20000. These details are not in the schema and help the agent make informed choices.

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 returns 'compact visible text lines from the page', which is a specific verb and resource. It explicitly distinguishes this tool from its sibling 'browser_snapshot' by advising preference for reading/searching without flooding 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?

The description provides clear context: use when you need to read/search page content without flooding context, and prefer this before browser_snapshot. However, it does not explicitly state when not to use it (e.g., if full HTML is needed), leaving room for ambiguity.

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

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

The description discloses key behavioral traits: focus, clear (by default), insertText, optional submit that presses Enter, and caching of selectors via intent. Since no annotations are provided, the description carries the full burden and does so adequately, though it omits details like waiting behavior or error 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 extremely concise—just one sentence—yet conveys the core action and optional features. It front-loads the main operations (Focus, clear, insertText) and adds extras succinctly. No wasted words.

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

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

Given 6 parameters, no output schema, and no annotations, the description is too brief. It lacks explanation of what `ref` refers to (e.g., CSS selector), what happens if `clear` is false, whether the element needs to be interactable, and any error conditions. The agent would need additional context for reliable invocation.

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

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

Schema description coverage is low (17%), so the description must compensate. It explains the intent parameter's caching purpose and clarifies that `submit` is optional and presses Enter. However, it does not explain the `ref` (selector), `text`, or `tabId` parameters, leaving gaps.

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

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

The description clearly states the tool performs focus, clear, and insertText actions, which together mean typing text into an element. It uses specific verbs and resource (typing into a field) and distinguishes from other browser tools like click or navigate. However, it could be more explicit about 'type text into a form field'.

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

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

The description does not provide any guidance on when to use this tool versus siblings such as browser_click or browser_press_key. It lacks context about prerequisites or when not to use it, leaving the agent to infer based on the action 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It explains the multi-strategy approach and source/target flexibility but does not cover error handling, permissions, or side effects like page navigation. Adds significant context beyond schema but leaves 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?

Two sentences, first sentence states purpose concisely, second sentence details core options. No redundant words. Could be more structured but effective and 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?

Given the complexity (18 parameters, no output schema, no annotations), the description covers only the essentials. Lacks details on multi-file uploads, event dispatching, frame targeting, wait options, and success/failure behavior. Incomplete for a tool of this complexity.

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

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

Schema coverage is low (17%) with only 18 parameters. The description explains the high-level groupings (source: stashId/inline; target: selector/ref/trigger/auto) which adds meaning. However, many parameters like mime, name, dispatchEvents, waitFor are not elaborated, leaving significant meaning undiscovered.

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 'Attach a file to a target on the page.' with specific details about bypassing the native OS file picker via a strategy chain. This distinguishes it from other browser tools like browser_upload_stage and browser_click, providing a clear verb and resource.

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 strategy chain and source/target options, giving implicit context for when to use (automation scenarios). However, it does not provide explicit when-not-to-use guidance or direct comparisons to sibling tools like browser_upload_stage for staging files.

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

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

With no annotations, the description carries full transparency burden. It discloses idempotency, destination, return value, and maxBytes limit. Missing details on permission requirements or error handling, but adequate for typical staging 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?

The description is concise (4 sentences) with no redundancy. Key information is front-loaded: what it does, where, and what it returns.

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

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

Given 5 parameters, 1 required, nested objects, and no output schema, the description covers the essential: source types, return value, idempotency, and size limit. It could mention the 'keep' parameter's effect, but schema descriptions suffice for that.

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 description adds context beyond schema: grouping of source types, purpose of stashId, and idempotency. It also clarifies that stashId is reused across uploads, which is not explicit in schema.

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

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

The description clearly states the tool's function: staging files into a specific upload library. It specifies file types (image/video/document), destination path, and return value (stashId). It distinguishes itself from sibling tool browser_upload_file by noting that stashId can be passed to it.

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

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

The description lists the four accepted source types (path, url, dataUrl, base64) and explains idempotency and stashId reuse. It indirectly guides when to use this tool (before browser_upload_file) but lacks explicit 'when not to use' or alternative scenarios.

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

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

With no annotations, the description must disclose behavioral traits. It only says 'Sleep up to 60 seconds,' missing details like blocking behavior, interruptibility, or consequences of exceeding the limit.

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 terse at four words, which is under-specification rather than efficient conciseness. It lacks necessary details to be minimally viable.

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 low schema coverage, no output schema, and only one parameter, the description is incomplete. It does not explain the unit of measurement, the default, or any constraints, leaving the agent with insufficient information 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?

The schema has 0% description coverage, meaning the description does not explain the 'ms' parameter at all. It fails to add meaning beyond the schema, despite the low coverage needing compensation.

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 sleeps for a duration, which is a specific verb and resource. It distinguishes from sibling tools, which are all browser actions. However, it could be more precise about the unit (milliseconds) and the 'up to' limit.

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. While there is no other wait tool among siblings, the description does not provide any context for appropriate usage or when not to use it.

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

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

No annotations provided, so description carries full burden. It mentions the window-level effect but lacks details on side effects, permissions, or edge cases (e.g., constraints on width/height).

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

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

Single sentence, front-loaded with core actions, every word adds value. Could benefit from more structure but is efficiently concise.

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

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

With no output schema, annotations, or parameter explanations, the description is incomplete for a tool with 6 parameters. Does not cover return behavior or interaction with the session.

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 has 6 parameters with 0% description coverage. The description only implies roles (width/height for resize, left/top for move, state for maximize) without explaining each parameter's meaning, constraints, or defaults.

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 (resize/move/maximize) and resource (session's Chrome window), and adds context that it affects the whole window, distinguishing it from viewport-related siblings like browser_emulate_viewport.

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_emulate_viewport or when not to use it. Does not specify prerequisites or scenarios.

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

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

With no annotations, the description must fully disclose behavioral traits. It only states 'delete' but does not confirm if the action is permanent, irreversible, or if it requires specific permissions. The lack of detail leaves the AI uncertain about side effects or dependencies.

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

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

The description is extremely concise at four words. It front-loads the action and object. However, it sacrifices necessary detail; a few more words for parameter context would not harm conciseness.

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

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

Given two parameters (one optional) and no output schema, the description should at least explain the 'origin' parameter and confirm the deletion behavior. It lacks completeness for an AI to confidently invoke the tool 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%, and the description adds no information about the two parameters ('name' and 'origin'). The purpose of 'origin' is entirely unexplained, and 'name' is only inferred as the workflow identifier. The description fails to add meaning beyond the property names.

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

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

The description clearly states that the tool deletes a named workflow, using the verb 'Delete' and specifying the resource as 'named workflow'. This differentiates it from sibling tools that export, get, list, run, or save workflows. However, it does not elaborate on what 'named' means or if any identifier format is required.

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, such as whether there is an alternative delete mechanism or if the workflow must exist beforehand. The description does not mention prerequisites, consequences, or when not to delete.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the export is read-only, what permissions are needed, or if any state changes occur. The phrase 'portable JSON' suggests a non-destructive download, but this is not explicit.

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

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

The description is very concise (one sentence) but could include key parameter details without becoming verbose. It is appropriately front-loaded with the core action, but the brevity sacrifices completeness.

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

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

Given the simplicity of the tool (2 parameters, no output schema, no annotations), the description is incomplete. It covers the purpose and a hint about sharing via repo, but lacks parameter explanations and behavioral context. More details are needed for an agent to invoke it correctly.

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

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

The input schema has two parameters (name and origin) with 0% description coverage. The description does not explain what 'name' or 'origin' mean, nor does it provide any context beyond the tool's purpose. With schema coverage absent, the description should compensate 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 clearly states the action ('export a workflow') and the output format ('portable JSON'). It also provides a use case ('commit to your repo to share'), which distinguishes it from related tools like browser_workflow_get that may not export in a portable format.

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 hints at usage ('commit to your repo to share') but does not explicitly state when to use this tool versus alternatives like browser_workflow_import or browser_playbook_export. No when-not-to-use or exclusions are provided.

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