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

Details execution order (sequential, never parallel), failure behavior (halts at first failure, returns partial output, error, and skipped count), pre-validation (rejects unknown tools and nested batches before touching the page), stale reference caveats, mandatory tabId requirement, and differences from the Chrome extension. With no annotations provided, this description carries the full transparency burden and exceeds it.

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

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

The description is long but every sentence contributes essential operational detail—no filler or repetition. It is organized into a clear flow: general behavior, validation, then two specific 'bites' and an extension difference. The structure aids comprehension despite the density.

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 batching tool with multiple failure modes and safety caveats, the description covers everything an agent needs: how to structure entries, what happens on failure, how validation works, tabId requirements, stale reference hazards, permission differences, and modal dialog handling. Despite no output schema, the return behavior is described sufficiently.

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

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

The schema already defines the actions array and its items, but the description adds real meaning: it explains the exact shape of each entry, provides a concrete example, clarifies that tabId must be repeated, and notes that browser_batch cannot be nested. This goes well beyond the schema's field 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 states a specific verb ('push a whole run... through one request') and resource ('browser tool calls'), and distinguishes it from spending a turn on each call. It is immediately clear what the tool accomplishes.

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 tells when to use it ('whenever you can see two or more moves ahead') and contrasts with alternatives ('rather than spending a turn on each'). It also specifies when not to use it (nesting a batch, after navigation, when a modal dialog appears), leaving no 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?

With no annotations provided, the description takes on the full burden of behavioral disclosure. It is remarkably transparent: it explains that hidden elements return errors, that certain chords are refused to avoid creating an invisible zoom, that screen captures are returned and optionally saved to disk, and that actions fail while a dialog is open. These details leave very little to discover at runtime.

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 long but every sentence earns its place. It is well-structured with a clear summary, a bulleted list of actions, and detailed per-parameter explanations that are logically grouped and easy to scan. There is no redundancy or fluff, and the content is densely packed with useful 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 complexity of the tool (13 parameters, 13 enum values, and interactions with sibling tools), the description is exceptionally complete. It explains all actions, parameter dependencies, return values (screenshots, file paths), and cross-tool prerequisites (e.g., asking tabs_context_mcp for a tab ID). Without an output schema, the description adequately covers what the agent can expect back.

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

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

The schema has 13 parameters and the description covers 100% of them with rich context. For example, it explains the lifecycle of `ref` handles, the pixel mapping of `coordinate` (CSS pixels, devicePixelRatio 1), the exact behavior of `text` under `type` vs `key`, and the semantics of `scroll_direction`. This goes far beyond the raw schema and gives the agent everything it needs to use each parameter correctly.

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

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

The description states a specific action ('Drive one Firefox tab with synthetic pointer, wheel and keyboard input, and capture what it looks like') and clearly distinguishes this tool from siblings like tabs_close_mcp, navigate, and read_page. It also hints at the screenshot capability, leaving no ambiguity about the tool's core function.

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

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

The description provides extensive, actionable guidance: how to choose actions, when to use `ref` vs `coordinate`, how to obtain a valid tab ID via tabs_context_mcp, how to interpret results, and what to do when actions fail (e.g., take a fresh screenshot). It also explains which parameters are required for which actions and gives practical tips like avoiding stale coordinates.

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 responsibility and does an excellent job. It discloses critical behaviors: path restrictions based on upload roots, symlink resolution, total size limit of 10 MB, read-back verification, and the lack of per-site approval (unlike Chrome). It also warns about Firefox's native picker opening on click. This is exceptionally transparent.

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

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

The description is long but information-dense. Every sentence carries a distinct operational point—caveats, prerequisites, constraints, verification—so the length is justified. It is structured as flowing prose rather than bullet points, which is acceptable given the density of important behavioral warnings. A slight trim could make it more scannable, but it is not redundant.

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

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

The tool is complex—file path restrictions, symlink behavior, size limits, ref lifecycle, and cross-browser differences—and the description covers all of it. It even explains the output (the input is read back and the result states file count) despite having no output schema. It provides enough context for an agent to use the tool correctly without needing additional external documentation.

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

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

The schema already covers all three parameters with detailed descriptions (100% coverage), so the baseline is 3. The tool description goes beyond the schema by explaining the semantic implications: ref belongs to a snapshot and becomes stale after navigation, paths cannot be folders and must resolve to upload roots, and tabId requires a live tab with no approval step. This adds meaningful context beyond the 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?

The description clearly states the tool's purpose: putting files from the machine into a file input on the page. It distinguishes itself from sibling tools by explicitly directing users away from clicking and toward read_page/find for locating the input, and by contrasting with Chrome's file-sharing model.

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

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

It provides explicit when-to-use guidance: never click the input, use read_page or find to get the ref, and call this tool with all three required arguments. It also explains when to use tabs_context_mcp for tabId and how to verify success by reading back the input's file count. It names alternatives (read_page, find, tabs_context_mcp) and conditions, leaving no 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?

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the search ranking approach, the 20-result limit, the 30-level and 5000-element traversal bounds, handle expiration, and the behavior around alerts and approval prompts. This gives the agent a solid model of side effects and limitations.

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

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

The description is dense but mostly purposeful. It front-loads the core purpose and then covers algorithm details, limits, and usage edge cases. A few points about tabId are repeated between the main description and the schema, but overall it is efficiently organized and each clause adds operational 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 tool's complexity and lack of an output schema, the description is remarkably complete. It explains what results look like (ranked list with ref_N handles), how many can be returned, what happens when limits are exceeded, when results become stale, and how alerts affect execution. This gives the agent enough context to use the tool reliably without hidden surprises.

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?

Although schema coverage is 100%, the description adds substantial semantic detail beyond the schema: it explains how to formulate the query, that filler words are dropped, that only session-owned tabs are addressable, and how to obtain valid tab IDs. This helps the agent invoke the tool correctly in real workflows.

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

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

The description clearly states the tool's purpose: looking up elements by natural language description rather than by selector. It gives concrete examples and distinguishes itself from read_page by referencing the same tree, making the tool's role unambiguous.

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

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

The description provides practical usage guidance: how to phrase queries, what to do when too many results are returned, and when to fall back to read_page on an empty result. It also notes that handles expire after navigation and that browser_batch must spell out tabId. It does not explicitly contrast with every sibling tool, but the main alternative is covered.

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

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

No annotations are present, so the description carries the burden. It mentions that the dialog is blocking the page and can be cleared, but does not detail side effects such as navigation consequences after accepting or dismissing, or behavior when no dialog exists.

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

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

The description is concise, using two sentences to convey purpose and platform-specific context. No redundant or irrelevant information is included.

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

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

The description is adequate for an agent to understand when the tool applies (blocking native dialogs in Firefox). Given there is no output schema and the tool's scope is narrow, the provided context is mostly sufficient, though a note about required action (accept vs dismiss) being mandatory would improve completeness.

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

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

The input schema covers all three parameters with descriptions, giving 100% coverage. However, the descriptions are minimal (e.g., 'Default accept' for action) and do not add deeper meaning beyond the schema itself. The description text adds no additional parameter context.

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 (accept or dismiss) and the target (native dialog such as alert, confirm, prompt, beforeunload). It also distinguishes the Firefox-specific behavior from Chrome, making the purpose unambiguous.

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

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

The description provides context about Firefox-only behavior but does not explicitly state when to use this tool versus alternatives like javascript_tool or navigate. No clear conditions or scenarios are given for choosing this tool over others.

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

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

No annotations are present, so the description must carry the full burden. It states that the tool restarts Firefox, which implies termination and restart, but it does not disclose potential side effects like losing open tabs, clearing session state, or whether the action is destructive. Given the nature of a restart, some behavior is implied, but explicit disclosure of consequences is missing.

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

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

The description is a single, efficient sentence that front-loads the action ('Restart Firefox') and then adds the usage condition. There is no fluff, and every word serves a purpose.

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

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

For a simple, parameterless tool with no output schema, the description provides enough context: what it does, when to use it, and its scope. It does not describe the return value, but that is likely irrelevant for a restart operation. The only minor gap is the lack of explicit side-effect disclosure, which is already penalized under behavioral transparency.

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

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

The tool has zero parameters, and the schema is empty. According to the rubric, a baseline of 4 is appropriate when no parameters exist. The description adds no parameter information, which is fine since there are none to explain.

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

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

The description states a clear, specific action: 'Restart Firefox.' It identifies the resource (Firefox) and the operation, and distinguishes it from siblings like firefox_status by specifying the action and context. It also notes 'Firefox-only,' which sets scope.

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

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

Explicit usage conditions are provided: 'Use this when the browser stops responding or reports a stale automation session.' This tells the agent exactly when to invoke it, and the 'Firefox-only' qualifier warns against use on other browsers. No alternative tools are named, but the condition is clear and actionable.

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. It conveys a read-only operation via the verb 'Report' and specifies the exact information returned, which implicitly signals no side effects. It does not detail potential authentication or environment constraints, but for a status tool this is adequate.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and appends the Firefox-only caveat. There is no filler or redundancy.

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

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

For a zero-parameter, no-output-schema tool, the description covers the essential behavior and scope. It could mention the output format, but since the tool is a straightforward status report and the description lists what it reports, it is sufficiently complete for an agent to invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter-specific details (none are needed), and the empty schema requires no 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 uses a specific verb ('Report') and a specific resource (Firefox status), and enumerates the exact data points: running status, profile, port, viewport, and session tabs. It also explicitly distinguishes itself from the Chrome integration, making it clearly unique 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?

The description clearly states this is Firefox-only and that the Chrome integration has no equivalent, which implies when to use it (when Firefox-specific status is needed) and when not to (Chrome contexts). It doesn't explicitly name alternatives, but the Firefox vs. Chrome distinction is a clear usage pointer.

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 covers behavior: native setter, input/change events, real clicks for checkboxes, dropdown matching logic, disabled control handling, and staleness errors. This gives a complete picture of side effects and failure modes.

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

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

The description is detailed yet tightly organized, with each sentence conveying necessary information without redundancy. The main action and requirements are front-loaded, followed by control-specific semantics and edge cases.

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 relevant operational details: how to obtain the ref, how to pair it with a tab, how values map to controls, what happens with invalid inputs, and when errors occur (stale ref, disabled, unmatched dropdown). It is complete 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?

Even though schema coverage is 100%, the description adds significant nuance beyond the schema: it clarifies stale refs, tab ownership, accepted value types per control, and rejection of arrays/objects. This meaningfully enhances understanding beyond the raw property 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 fills a form control using a ref from read_page, and explicitly distinguishes it from clicking. It enumerates supported control types, making the purpose unambiguous.

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

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

It states required parameters and gives detailed guidance on ref freshness, tabId association, and value semantics per control type. It contrasts with file upload tools but does not explicitly enumerate all alternative tools or conditions for choosing this one over them, though the context is largely sufficient.

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. It discloses extraction priorities, content filtering, truncation at 200000 characters, the closing note about actual length, modal blocking until firefox_dialog answers, and that no site approval is requested due to the browser profile.

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

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

The description is front-loaded with a clear first sentence, but it contains some stylistic redundancy and filler, such as 'so a long post arrives as paragraphs rather than as the furniture around them' and 'only a pathological page ever hits that.' These phrases add color but do not strictly earn their place.

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

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

There is no output schema, but the description adequately explains the output format ('plain text, no markup'), the 200000-character truncation, and the closing note reporting actual length. It also describes extraction priorities and error-relevant behavior like modal blocking, though exact error formats are not specified.

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 only parameter, tabId, already has 100% schema coverage, but the description adds meaningful constraints beyond the schema: 'Valid ids come from tabs_context_mcp or firefox_status', 'tabs outside this session's group cannot be read', and 'a browser_batch step has to name the id itself.'

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

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

The description clearly states the tool's purpose: 'Read a page as prose: plain text, no markup, no element handles.' It also explicitly distinguishes itself from sibling tools: 'Reach for it when the goal is to read or quote; reach for read_page or find when you need something clickable, since nothing here carries a ref.'

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

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

The description gives explicit when-to-use guidance and names alternatives: 'Reach for it when the goal is to read or quote; reach for read_page or find when you need something clickable.' It also notes important usage constraints like tab ownership, browser_batch self-naming, and modal-dialog blocking behavior.

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 thoroughly discloses side effects and quirks: frames live in server memory, tab close stops the loop, dropped frames are counted, the server writes the file itself (ignoring the download flag), filename auto-numbering and .gif appending, and the meaning of the quality ranges. These are far beyond typical tool descriptions.

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 thorough but quite verbose and repetitive. It restates default values multiple times (e.g., quality default, overlay defaults) and uses long, winding sentences. The structure is logical (purpose, actions, details, parameters) but could be tightened significantly without losing 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 complexity (4 actions, 5 parameters, nested options, multiple edge cases), the description is remarkably complete. It covers all actions, parameter effects, default behaviors, memory handling, file output, and even contrasts with Chrome's behavior. No significant aspect is left unexplained.

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

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

Although the schema already has 100% description coverage, the prose adds substantial extra meaning: default values for options, the fact that options are only read by export, the filename fallback numbering and directory stripping, and the clarifying note that the download flag is a no-op. This enriches the semantics 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 opens with a clear statement of purpose: 'Films a tab as a run of screenshots and encodes them into an animated GIF.' It also names the four actions and their roles, and the tool is unique among the siblings (no other tool records or exports GIFs).

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 explicitly contrast this tool with alternatives like 'computer' or 'screenshot', but the purpose is so distinct that the intended use case is obvious. It does give guidance on when to use each action (start, stop, export, clear) and mentions that 'export' is the only action that reads options.

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 carries full burden. It thoroughly discloses execution context (page's own world), side effects (writes stick to live document), output trimming at 10000 characters, error behavior (throw fails the call), and limitations (file input, alert/confirm). This is exceptionally 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?

Every sentence contributes unique information: purpose, parameter details, execution semantics, output handling, error behavior, and limitations. It is front-loaded with the primary purpose and avoids redundancy, despite being detailed.

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?

Fully complete for the tool's complexity: explains output format and truncation, error propagation, execution context, side effects, parameter requirements, and alternatives. No output schema exists, but the description covers return behavior adequately, leaving no critical gaps for an agent to invoke correctly.

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

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

Schema descriptions already thoroughly cover each parameter (console semantics, tabId source, fixed action value), and the tool description adds extra meaning beyond schema—notably the explicit limitations and alternatives. Given 100% schema coverage, the description still enriches understanding, warranting above baseline.

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

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

States precisely: evaluates JavaScript in a page and returns the final expression's value. The verb 'evaluate' and resource 'JavaScript inside a page' are specific, and it clearly distinguishes from sibling tools like navigate, read_page, and form_input.

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 explains when to use it (console semantics, top-level await, page context) and when not to (cannot fill file inputs or handle alerts, pointing to file_upload/upload_image and firefox_dialog as alternatives). Also directs the agent to obtain tabId from tabs_context_mcp, covering 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the call returns after loading settles, that it retires ref_N from earlier read_page calls, that Firefox opens in a separate automation profile without per-site approval, and that alerts/beforeunload are cleared via firefox_dialog. This is unusually thorough and covers side effects, environment behavior, and error recovery.

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 longer than typical but every sentence earns its place: it covers purpose, fallback logic, mandatory cases, return behavior, Firefox specifics, and alert handling. It is front-loaded with the core action and then layers detail. No redundant filler; the only slight deduction is that it is denser than necessary, but it remains well-structured and readable.

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

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

Given the tool's complexity (two parameters, special values, batch context, browser-specific behavior, return semantics) and the absence of an output schema, the description covers everything an agent needs to call it correctly. It explains all edge cases, prerequisites, and side effects. No missing information that would cause a mis-invocation.

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

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

Schema description coverage is 100%, so baseline is 3. However, the description adds substantial meaning beyond the schema: it explains the 'back'/'forward' literal values, the fallback tab selection logic, and the mandatory/optional contexts for tabId. It also clarifies URL normalization (adding https://) and the distinction between standalone calls and browser_batch. This goes well beyond the schema's field-level 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 opens with a precise statement: 'Send a tab to an address, or walk that tab through the history it has already built.' This distinguishes navigation from reading (read_page), form input, and other siblings. It also names the two distinct modes (direct navigation and history traversal) clearly, so an agent knows exactly what the tool does.

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

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

The description gives explicit conditions: 'Only url is always required' and explains when tabId can be omitted, when it is mandatory (for 'back'/'forward' and inside browser_batch), and when it is advisable ('whenever the group holds several pages'). It also contrasts with firefox_dialog for handling blocked loads and mentions the tab group behavior. This is comprehensive, actionable guidance with no 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 thoroughly discloses behavior: lazy capture, buffer size (1000 entries per tab), origin-change reset, output format (ISO timestamp, level, text, stack frames), behavior of the clear flag (empties buffer after reply), limit cap effect, and error handling for patterns (malformed or backtracking). It also states that read-only semantics are not pure because clear can modify state, and annotations are absent, so the description carries the full burden.

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

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

Although lengthy, every sentence carries essential information—no fluff. The structure front-loads the main function, then details buffering behavior, then parameter specifics. Repetitive phrasing about buffer limits and lazy capture reinforces critical constraints without adding noise. The description is dense but well-organized and necessary given the tool's nuances.

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 necessary context an agent needs: how to trigger capture, what the output looks like, how to limit results, how to filter, error conditions, and state-changing behavior (clear). It explains edge cases like origin changes and lazy capture, and mentions the header reporting held-back entries. Nothing essential is missing for safe and effective use.

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

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

Schema coverage is 100%, but the description goes beyond the field-level comments by adding context: it restates required tabId, explains the interaction between clear and subsequent reads, clarifies that limit caps apply to matches and headers count held-back entries, details pattern matching rules (case-insensitive, hits text or level), and gives a concrete example ('warn|error'). This elevates understanding of each parameter's practical behavior.

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

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

The description clearly states the tool's purpose: returning console output (log, info, warn, error, uncaught exceptions) for a specific tab. It explicitly distinguishes from sibling read_network_requests by naming it and describing the different resource, satisfying the verb+resource requirement.

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

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

It provides actionable usage guidance: explains the lazy capture (first call triggers buffering, so reload if needed), advises using the pattern parameter to narrow results, warns about malformed regexes causing errors, and gives clear instructions on the clear parameter for subsequent reads. It tells when to use the tool and how to get the best results.

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 side effects: the clear parameter discards recorded requests, recording begins on first call, only session tabs are readable, and only the most recent 1000 requests are kept. Also notes the header reporting hidden matches.

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

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

The description is long but every sentence carries essential operational detail. It is well-structured, covering purpose, usage, and limitations without redundancy or filler.

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

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

Given no output schema, the description explains the output format (rows with method, status, resource type, etc.) and the header behavior regarding capped matches. This gives the agent a clear picture of what to expect.

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

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

Every parameter is described in the schema, and the tool description adds context: tabId is linked to tabs_context_mcp, urlPattern is explicitly a literal substring (not a regex), and limit's behavior is clarified with the default and the header cue.

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 it lists HTTP traffic for a tab, enumerating the types of resources and the fields per row. It clearly differentiates from siblings like read_page or read_console_messages by focusing on network requests.

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 direct use cases: confirming an API call fired, inspecting responses, and finding slow assets. Also explains key limitations (per-tab session, recording start, buffer cap) which helps the agent decide when to use this 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?

With no annotations, the description carries the full burden of behavioral disclosure. It thoroughly explains the walk limits (depth, element count, char trim), that handles are per-document and invalidate after navigation, and that alerts/confirms freeze the page. It even reports how limits are signaled via bracketed notes. This is exemplary transparency 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 dense but every sentence adds unique value: purpose, filter usage, limits, handle invalidation, tabId requirements, and Firefox specifics are all covered. It is front-loaded with the core purpose and structured logically, with no filler or redundancy. The length is justified by the tool's complexity.

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

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

Given no output schema, the description fully explains what the output looks like (indented accessibility tree with roles, names, boxes, ref handles, and limit notes). It covers all parameters, the scenarios for using them, and edge cases (stale handles, alert freezing). An agent can invoke the tool correctly with only this description.

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?

While schema coverage is 100%, the description adds substantial meaning to each parameter: depth is contextualized for cutting bulky pages, filter distinguishes interactive vs layout exploration, ref_id is presented as the fix for overflow, and max_chars is tied to client capacity. The rationale and usage guidance far exceed the schema's terse property descriptions.

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

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

The description states a specific verb ('Dump a loaded page as an indented accessibility tree') with clear resource and scope. It differentiates itself from siblings by explaining it provides ref_N handles for other element tools, and explicitly mentions the 'interactive' filter as a contrast to the full tree. This leaves no ambiguity about what the tool does.

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

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

The description gives explicit when-to-use guidance: it is the source of ref_N handles for form_input and other element tools, and recommends the 'interactive' filter when only controls are needed. It also specifies tabId requirements, mentions browser_batch usage, and notes Firefox-specific behavior (alerts freeze the page). This covers both usage conditions and 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?

With no annotations, the description carries the full burden of disclosing behavior. It transparently explains that headless runs and older builds may refuse window resizing and instead stretch the viewport, that the reply reports innerWidth/innerHeight which may fall short due to toolbars and clamping, and that only the specified tab is affected. This is comprehensive 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 front-loaded with purpose and presents necessary detail, but it contains some redundancy (e.g., repeating that tabId is required and that only the named tab is affected). The longer sentence about expected fall-short and clamps is dense but informative. Overall it is reasonably concise given the complexity, but not maximally tight.

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 fully equips the agent to use the tool correctly: it covers input requirements, behavior under different conditions (headless, older builds), effect on other tabs, and what the reply will contain. Since there is no output schema, explicitly describing the reply format (innerWidth x innerHeight) ensures 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?

Though the schema already covers 100% of parameters, the description adds substantial semantic detail for each: tabId explains which tab and fallback behavior, width and height both clarify positivity requirements, that browser chrome reduces the actual page area, and that the reply reports measured dimensions. This goes well beyond the baseline for full coverage.

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

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

The description clearly states the action ('Change the size of the Firefox window a tab lives in') and identifies the specific resource (a Firefox window/tab). It also explains the intended use cases (layout checking at phone/tablet/desktop widths, screenshots). This distinguishes it from sibling tools, none of which perform window resizing.

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 context for when to use the tool (before layout checks or screenshots) and explicitly notes that tabId is required and there is no implicit tab. However, it does not explicitly contrast with alternative tools or state when not to use it, though such guidance is less critical given no sibling tool overlaps.

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?

Excellent transparency: it discloses that closing the last tab empties the group and Firefox drops it, and that a later createIfEmpty creates a fresh one. It also explains that already-closed or invalid tabs are refused, giving a clear behavioral contract.

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 unnecessarily verbose, using metaphorical phrasing ('tidy up once a page has served its purpose') and repeating the 'tabs_context_mcp' source multiple times. While all content is relevant, it could be condensed to a more direct statement without losing meaning.

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

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

Given the absence of an output schema, the description fully covers the tool's behavior, constraints, and edge cases (invalid IDs, last tab scenario). It provides everything an agent needs to call it correctly and anticipate outcomes.

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

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

The schema already covers the parameter (tabId, integer, required), and the description adds significant meaning: it must be a valid ID from tabs_context_mcp, that IDs are never reused, and that stale IDs cause refusal. This goes well beyond the raw 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: closing a single tab by ID. The metaphorical language ('shut one tab') is still unambiguous, and the context of sibling tools (navigate, create, etc.) makes the purpose distinct.

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 guidance on when to use the tool: when closing a tab, and explicitly instructs that the tabId must come from tabs_context_mcp. It also warns against invalid or stale IDs, which helps avoid misuse. However, it does not explicitly compare to siblings like tabs_create or navigate, though the action is inherently distinct.

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 behavioral burden. It discloses that the tool only lists tabs opened by this server in its Firefox profile (not user's own windows), that no site permission is needed, and the behavior when no group exists (reply says so, points to createIfEmpty). It also clarifies that createIfEmpty never appends a second tab. These are significant behavioral details beyond what a schema could convey.

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

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

The description is well-structured and front-loaded with the core purpose. Every sentence adds value: scope, usage timing, exclusions, fallback behavior, and guidance for new conversations. No fluff or repetition.

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

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

The tool has no output schema, but the description explicitly lists the returned fields (id, address, title, focus) and explains the createIfEmpty behavior. It also covers edge cases like empty groups and permission requirements. An agent has everything needed to call and interpret the result 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 description coverage is 100% for the single parameter createIfEmpty, and the schema already explains its effect. The description reiterates the 'when no group exists' context but does not add new semantics beyond the schema. 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 opens with a specific verb and resource: 'List the tabs this session owns' and enumerates the exact fields returned (numeric id, current address, page title, focus). It clearly distinguishes itself from siblings like tabs_create_mcp and navigate by stating it is a listing tool that precedes other browser actions.

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

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

The description gives explicit when-to-use guidance: run it before any other browser tool and again after tabs open or close. It also explains when to prefer tabs_create_mcp for new conversations and when createIfEmpty is relevant, providing clear alternatives and 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?

Discloses that it creates a tab and returns data, and notes the cleanup expectation. Does not mention potential side effects like focus changes or prerequisites, but the core behavior is transparent.

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

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

The description is somewhat verbose, mixing workflow instructions and cleanup policy into the tool definition. While structured and logical, it could be more concise by separating generic guidance from the tool's core purpose.

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

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

Provides enough context for an agent to use the tool correctly, including what it returns (id and group contents) and its relationship to other tools. Lacks exact output format, but that is not critical given the absence of an 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?

No parameters exist, and the description correctly states 'It takes no arguments.' Baseline score of 4 applies for zero parameters.

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

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

Clearly states the tool's action: open a new blank tab in the session tab group and report its id and the group's contents. Distinct from siblings like tabs_close_mcp and tabs_context_mcp.

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 instructs to call tabs_context_mcp first to know the group, then use navigate on the new tab id, and close it with tabs_close_mcp when no longer needed. Provides clear when-to-use and how-to-use guidance.

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

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

With no annotations provided, the description carries full behavioral transparency. It discloses side effects in detail: writing a scratch file, scrolling and falling back to drop for non-input elements, synthesizing drag/drop/paste events, and reporting which mechanism the page actually handled via the result line.

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?

Every sentence supplies necessary operational detail with no filler. The single paragraph flows logically from purpose to constraints, per-path behavior, and result interpretation, making it dense yet well 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 five parameters, conditional exclusivity, fallback behaviors, and a result contract, the description is complete. It tells the agent how to obtain ids, what to expect on errors, and how to validate success via the result line, leaving no operational gap.

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

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

The schema descriptions already cover all five parameters, and the prose adds critical semantics beyond them: imageId freshness ('Only the 20 most recent survive'), filename defaulting and sanitization ('directory part stripped', '.png' added), ref staleness after navigation, and coordinate invalidation after scroll or layout shift.

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 the tool's purpose precisely: 'Feeds a picture the session is already holding ... into a page'. It distinguishes the action from sibling tools by referencing the computer tool for capture and read_page/find for element references, making the verb and resource unmistakable.

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

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

It explicitly contrasts the two targeting paths (ref vs coordinate), states when each is appropriate ('above all a file input the page hides' vs 'a visible region that accepts dropped files without exposing an input'), and notes constraints like 'Giving both is an error and so is giving neither'. It also points to sibling tools (tabs_context_mcp, read_page, find) for obtaining required ids.

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