FoxBridge MCP

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

With no annotations, the description carries the full burden. It discloses the profile copying behavior but omits details on headless mode, default visibility, multiple instances, and return values. This is partially transparent.

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

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

The description is a single concise sentence that efficiently communicates the core action and key parameter usage. 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?

The description is too brief for a launch operation. It lacks details on return values, error conditions, prerequisites (e.g., Firefox installation), and headless behavior. Given no output schema, it should provide more context 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?

Schema coverage is 0%, but the description adds context for the 'useProfile' parameter (profile name or default for cookies copy). The 'headless' parameter is not explained, leaving it ambiguous. The description partially compensates for 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 'Launch the live Firefox instance,' specifying the verb and resource. It distinguishes the tool from sibling tools like close_browser, open_tab, etc., which handle different stages of browser interaction.

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

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

The description implies this tool is used to start a browser session, and it provides guidance on the useProfile parameter (copy vs clean). However, it does not explicitly state when not to use it or compare it to alternatives like ff_navigate or open_tab.

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 must fully disclose behavior. It states 'ALL cookies' and 'live browser context' but doesn't mention if page needs to be loaded, if operation is reversible, or impact on other sessions.

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 clear sentence, no wasted words. Front-loaded with action and object.

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 simplicity (0 params, no output schema), description is adequate. It explains what the tool does, though could mention scope of effect.

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; schema coverage is 100%. Description adds no parameter info, but none is needed. Baseline for 0 params is 4.

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

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

Description clearly states the verb (clear) and resource (cookies) with scope (ALL, live browser context). Distinguishes from siblings like get_cookies and set_cookie.

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 vs alternatives like clear_web_storage or clear_disk_cache. Missing context for appropriate 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?

No annotations are provided, so the description carries full burden. It discloses that Firefox must be closed and that the cache will rebuild, which are important behavioral traits. However, it could mention side effects like loss of cached data for ongoing sessions.

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—a single sentence that front-loads the action and key condition. Every word 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 simple input schema (1 undocumented parameter) and no output schema, the description is incomplete. It does not explain the 'profile' parameter or any return value, 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?

The schema has one parameter ('profile') with no description and 0% schema description coverage. The tool description does not mention this parameter at all, failing to add meaning beyond the bare schema.

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

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

The description clearly states the action ('Delete the HTTP disk cache') and the resource ('disk cache'). It distinguishes this tool from siblings like 'clear_cookies' and 'clear_web_storage' by specifying the cache type.

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

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

The description provides a clear precondition ('close Firefox first, or it rebuilds'), guiding when to use the tool. It does not explicitly exclude alternatives but the context is 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?

Without annotations, the description carries full burden. It accurately describes the destructive action but omits details like irreversibility, permission requirements, and that it only affects the current origin.

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 with no redundancy or extra words. Perfectly 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 parameterless tool with no output schema, the description provides sufficient detail about what is cleared. Minor omission: could mention success/failure indication.

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; schema coverage is 100%. The description adds nothing beyond schema, which is acceptable as no parameter information is 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?

The description clearly specifies the action ('Clear') and the exact resources (localStorage, sessionStorage, Cache API) and scope ('for the active tab's origin'). It distinctly differentiates from sibling tools like clear_cookies and clear_disk_cache.

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 context through the scope ('active tab's origin'), but does not explicitly state when to use this tool versus alternatives 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. The description does not disclose behavioral traits like whether it waits for element to be clickable, defaults (left click?), or whether it triggers navigation. For a simple click, more context 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?

Description is very concise with one sentence front-loading the purpose. It earns its place but could include minimal additional details without becoming wordy.

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

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

For a simple action, the description is minimal. Lacks details on default behavior (left vs right click, single vs double click) and return value. May leave an AI agent uncertain 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%. The description only mentions 'CSS selector' for the selector parameter, ignoring button and doubleClick parameters. No explanation of their effect.

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 'click' and the resource 'element by CSS selector'. It is specific and distinguishes from sibling tools like hover and type_text.

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

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

No guidance on when to use this tool vs siblings (e.g., ff_click, double click via parameter). No when-to-use or when-not-to-use information.

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

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

With no annotations, the description must carry the full burden of disclosure. It says 'close' but fails to mention potential consequences like loss of unsaved state, need to restart, or that it ends the entire browser session irreversibly. This omission reduces transparency.

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

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

The description is a single, clear sentence with no unnecessary words. Every word is meaningful, making it highly concise and efficient.

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

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

For a simple no-parameter tool, the description provides the essential information. However, it lacks context about what happens after closing (e.g., whether the browser can be restarted with browser_start). Still, it is mostly complete given the tool's simplicity.

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

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

There are no parameters, and schema coverage is 100% (trivially). The rule gives a baseline of 4 for zero-parameter tools. The description does not add parameter info, but none is 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?

The description clearly states the action ('Close') and the resource ('the live Firefox instance'). It distinguishes well from sibling tools like close_tab, which close individual tabs rather than the entire browser instance.

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., close_tab or other session management tools). The description implies it's the counterpart to browser_start but does not explicitly state when it is appropriate.

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

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

With no annotations, the description carries the full burden. It states the action (close a tab) but does not disclose details such as whether the tab is permanently removed, if there is any undo, or behavior on invalid index. For a simple close operation, this is adequate but could be improved.

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

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

The description is a single sentence with no wasted words. It is front-loaded with the action and parameter, making it easy to parse.

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

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

Given the simplicity of the tool (no output schema, one parameter), the description is sufficient. It could mention error handling for out-of-bounds index, but overall it provides enough context for an agent 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?

Schema description coverage is 0%, so the description must compensate. It adds meaning by noting that the index is optional and defaults to the active tab, which is helpful for correct invocation.

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

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

The description clearly states the verb 'Close' and resource 'tab', and specifies the parameter 'index' with a default of active tab. It distinguishes itself from sibling tools like 'switch_tab' and 'close_browser' by focusing on closing a single tab by index.

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 closing a specific tab by index or the active tab by default. It does not explicitly mention when not to use it or alternatives like 'ff_close_tab', but the context from sibling tools provides enough 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?

Explains the profile vs clean browser distinction, which is helpful. However, with no annotations, the description should also disclose whether the evaluation is sandboxed, what return types are supported, and potential side effects. Lacks depth on 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?

Two concise sentences: the first states the core purpose, the second adds parameter guidance. No wasted words, front-loaded with essential 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?

Covers basic functionality and parameter usage. However, with no output schema, it lacks information about return value structure (e.g., object with value/error) and limitations (timeout, error handling). Adequate but not fully complete.

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

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

With 0% schema coverage, the description compensates well. It explains the 'useProfile' parameter in detail (purpose, values) and implies 'code' is the JavaScript to run. Both parameters are semantically clear 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?

Clearly states the action ('Run JavaScript') and scope ('in the active tab and return the result'). Purpose is unambiguous and distinct from sibling tools like ff_eval.

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 guidance on using the useProfile parameter (with profile vs clean browser), but does not discuss when to choose this tool over alternatives like ff_eval or other browser interaction tools. Usage context is implied but not explicit.

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

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

With no annotations, the description carries the transparency burden. It discloses the tool operates on a real Firefox instance and requires a bridge add-on, but does not detail behavioral effects like tab focus change, potential side effects, 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?

Two short, front-loaded sentences with no wasted words. The action is stated first, followed by a crucial prerequisite.

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 activation tool with one integer parameter and no output schema, the description provides adequate context (real browser, add-on requirement). Minor omission: no mention of return behavior (likely nothing) or error cases, but acceptable for low 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 0%, but the description barely adds meaning beyond the schema: it mentions 'by id' but does not specify that 'tabId' should be obtained from ff_list_tabs or similar. The description fails to compensate for the missing schema documentation.

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

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

The description clearly states the action ('Focus/switch') and the target ('one of your real tabs by id'), using specific verb+resource. It distinguishes from siblings like 'switch_tab' by specifying it operates on 'REAL running Firefox' with a bridge add-on.

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 versus alternatives. The description mentions prerequisites (bridge add-on) but does not specify contexts where ff_activate_tab is preferred over ff_list_tabs or ff_open_tab.

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 is the sole source. It discloses the clearing action and the need for the bridge add-on, but does not mention return values, side effects, or whether the operation is reversible. 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 sentences, front-loaded with the core action, no wasted words. Efficiently conveys the essential information.

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

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

For a simple clear operation with one parameter, the description covers the main purpose and prerequisite. However, it lacks details about the parameter, output, and what happens after clearing. Acceptable but not exhaustive.

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 does not mention the tabId parameter at all, and the schema has no description (0% coverage). The parameter's purpose is inferred from context but not explained, leaving ambiguity.

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

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

The description clearly states the verb 'clear' and the resource 'captured network log for a real tab', which is specific and distinguishes from sibling tools like clear_cookies or ff_network that gets the log.

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 'call before an action to see only its new requests' and mentions the prerequisite of the bridge add-on. Lacks explicit when-not-to-use or alternatives, but provides clear 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 mentions the bridge add-on prerequisite but lacks details on what happens if the selector is not found, if the click triggers navigation, or any destructive 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. The first sentence states the action and resource, the second adds essential context about the environment, with 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 simplicity of the tool (2 parameters, no output schema), the description is minimally adequate but lacks details on error handling, return values, and explicit guidance on when to choose this over siblings like 'click' or 'ff_type'.

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%, requiring the description to compensate. The description explains that 'selector' is a CSS selector, but does not mention the 'tabId' parameter or its optionality, leaving ambiguity.

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

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

The description clearly states the tool clicks an element using a CSS selector in a real tab, with a specific verb and resource. It distinguishes from the sibling 'click' by specifying that it operates on a real running Firefox instance with a bridge add-on.

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: when you have a real Firefox with the bridge add-on loaded. However, it does not explicitly state when not to use it or mention alternatives like the generic 'click' 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 full burden. It mentions prerequisites (bridge add-on) and default behavior (close active tab), but fails to disclose return value, error handling for invalid tabId, or consequences of closing the last tab.

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 fluff. The key action is front-loaded, and 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?

For a simple tool with one optional parameter and no output schema, the description covers purpose, parameter semantics, and a dependency. It lacks return value information and differentiation from sibling 'close_tab', but otherwise is adequately complete.

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

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

Schema coverage is 0%, but the description explains the 'tabId' parameter as an integer ID with a default of active tab if omitted, adding meaningful context beyond the bare schema. It could further mention how to obtain tab IDs.

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 ('Close') and resource ('tab'), specifies it operates on a 'real' Firefox instance, and distinguishes from siblings like 'close_tab' by emphasizing the real browser context and the bridge add-on 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?

The description provides context on when to use this tool (for real Firefox tabs with the bridge add-on), but does not explicitly state when not to use it or compare to alternatives like 'close_tab' (likely for virtual browser).

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 discloses key behaviors: uses browser download manager, leverages tab's cookies/auth, waits for completion, returns local path, and requires a real Firefox with bridge add-on. This is sufficient for safe usage, though it omits error handling or rate limits.

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

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

Two sentences with no redundancy. The critical action and context are front-loaded. Every clause adds value (download action, auth usage, completion wait, return value, operational requirement).

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 download tool with two straightforward parameters, no output schema, and no annotations, the description covers purpose, behavior, and prerequisites completely. The agent knows what to expect and what is needed (real Firefox, add-on).

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%, but the description adds minimal parameter meaning. 'url' is implied as the file URL from the verb 'download'. 'filename' is mentioned but not described (optional custom name). Without explicit param details, the description partially compensates but leaves some ambiguity.

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

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

The description clearly states the tool downloads a file to disk via the browser's download manager, using the tab's cookies/auth for protected files. It distinguishes itself from siblings like ff_fetch (in-memory fetch) and ff_list_downloads (list downloads) by specifying real Firefox operation and return of local path.

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

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

The description provides clear context for when to use (downloading files requiring browser auth via download manager) and mentions a prerequisite (bridge add-on). However, it does not explicitly state when not to use or name alternatives, though distinctions from siblings are implied.

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

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

No annotations are provided, so the description bears full transparency burden. It discloses that the code runs in a real tab with DOM and storage access, but does not explain scope limitations (e.g., 'not page globals'), return value handling, side effects, or execution mode (sync/async). Partial transparency but significant gaps remain.

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

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

The description is exceptionally concise with two sentences that convey core purpose and operational context. No unnecessary words 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?

Given the lack of output schema and annotations, the description is incomplete. It does not describe return values, error conditions, or how to handle results. For a tool executing arbitrary JS, these omissions hinder 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 description coverage is 0%, and the description does not explain either parameter. While 'code' is implicitly the JavaScript to run, 'tabId' is not mentioned at all, leaving ambiguity about how to specify the target tab. The description fails to add 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 runs JavaScript in a real tab with access to DOM and storage, differentiating it from sibling tools like 'eval_js' which may run in a different context. The purpose is specific and unambiguous.

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

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

The description implies usage in real browser context but does not provide explicit guidance on when to use versus alternatives or when not to use it. The mention of needing the bridge add-on is helpful but insufficient for clear usage guidelines.

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 behavior: operates from inside logged-in tab with real cookies/auth, requires bridge add-on, and returns status plus body. Lacks details on error handling, rate limits, or behavior when tabId is not provided.

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, no fluff, front-loaded with the primary action. Every part 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?

With no output schema or annotations, the description covers the core functionality but lacks details on the options parameter and return format specifics. Adequate for basic understanding but not fully comprehensive.

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

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

Schema coverage is 0%; description explains the url parameter's context but does not detail the optional tabId or options object. Leaves agent to infer meaning from 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?

Clearly states the tool calls a URL/API from inside a logged-in tab, returning status and JSON/text body. Differentiates from siblings by emphasizing the authentication context and real browser operation.

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 context for use ('Great for scraping the site's own API') and prerequisite (needs bridge add-on). However, does not explicitly state when not to use or compare with 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 are provided, so the description carries the full burden. It discloses that the tool operates on a real running Firefox and includes httpOnly cookies, which is helpful. However, it omits behavioral details such as whether it modifies state, requires specific permissions, or what happens if no cookies are found (e.g., empty list vs. error).

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 at two sentences, with the main action in the first sentence. It avoids redundancy but could be slightly more structured (e.g., separating purpose from requirements). Overall, 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 tool is simple (2 params, no output schema), but the description lacks details on return format (e.g., array of cookie objects), error handling, and how it differs from sibling tools like 'get_cookies'. It provides minimal context, which is barely adequate for an agent to use 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?

With 0% schema description coverage, the description is expected to explain the parameters. It mentions 'for a URL/domain' but does not clarify the roles of the 'url' and 'domain' parameters, whether they are exclusive or combined, or what format they should take. This leaves significant ambiguity for an agent.

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 gets real cookies (including httpOnly) for a URL/domain, distinguishing it from abstract cookie retrieval tools. However, it does not explicitly differentiate from sibling tools like 'get_cookies' or 'get_live_cookies' by highlighting the Firefox-specific nature and real browser 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?

The description mentions the prerequisite (bridge add-on loaded) but does not provide guidance on when to use this tool versus alternative cookie tools (e.g., get_cookies, clear_cookies). It implies usage for real, httpOnly cookies but lacks explicit 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?

No annotations are provided, so the description must fully disclose behavioral traits. 'List' implies a read operation, but the description does not explicitly state it is read-only or mention any side effects. The bridge add-on requirement is a helpful behavioral context.

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

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

The description is extremely concise with two short sentences, front-loading the purpose. Every word adds value, with no wasted or redundant content.

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

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

The description covers the tool's purpose and output fields, but lacks information about the 'limit' parameter. Given no output schema, the agent only knows the fields returned but not the exact structure or behavior when limit is omitted.

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

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

The single parameter 'limit' is not mentioned in the description, and schema description coverage is 0%. The agent receives no guidance on its meaning or usage beyond the schema's type constraint, which is a significant gap.

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

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

The description clearly states the tool lists recent browser downloads with specific fields (path, state, size). This is a specific verb+resource, and no sibling tool duplicates this functionality, making it easily distinguishable.

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 notes that it operates on a real running Firefox and requires the bridge add-on, providing clear prerequisites. However, it does not discuss when to use this tool over alternatives, though no direct alternatives exist among siblings.

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

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

No annotations provided, so description carries full burden. Discloses need for bridge add-on and real browser state. Implies read-only operation by 'list', but could explicitly state no 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?

Two sentences, no filler. Efficiently conveys core purpose and prerequisite.

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 no output schema, description mentions key return fields. Could slightly improve by noting output is an array, but current info is sufficient for a simple list 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?

No parameters exist (empty schema), so description adds no parameter details. This is acceptable; baseline is 4, but the description provides useful return field info beyond schema.

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

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

Description clearly states verb 'list', resource 'real open Firefox tabs', and specifies the fields returned (id, url, title, active). This distinguishes it from sibling tools like 'ff_open_tab' or 'get_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?

Mentions prerequisite (bridge add-on) and emphasizes 'REAL' Firefox, implying it's for live browser state. However, does not explicitly contrast with alternative tools like 'list_tabs' or other Firefox read tools, leaving usage context partially implied.

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

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

No annotations provided, so the description carries the burden. It states the tool navigates a real tab and returns the page as data, but does not disclose error handling, wait behavior, or side effects. Some context added but not comprehensive.

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

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

The description is concise with two sentences, no redundancy, and front-loads the core action.

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

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

Given no output schema, no annotations, and no parameter details, the description leaves significant gaps. It does not explain return values, errors, or parameter behavior, making it insufficient for full understanding.

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 'url' format or 'tabId' usage. It adds no value beyond the parameter names in the schema.

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

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

The description clearly states the verb 'Navigate' and resource 'real tab to a URL', and distinguishes from sibling tools like 'navigate' by specifying it operates on 'REAL running Firefox' with a bridge add-on.

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 a prerequisite (bridge add-on) but does not provide explicit guidance on when to use this tool versus alternatives like 'navigate' or 'ff_open_tab'. Usage context is implied but not detailed.

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 it operates on a real Firefox instance and requires a bridge add-on. However, with no annotations, the description fails to mention if the tool is read-only or has side effects, which is adequate but not thorough.

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

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

Two sentences with key information front-loaded. The first sentence covers functionality and output, the second adds operational context. No redundant text.

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

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

Given four unannotated parameters and no output schema, the description should explain parameter usage and output structure. It only hints at output fields but lacks details on arguments and response 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?

No parameter descriptions are given despite 0% schema coverage. The description does not explain the four parameters (type, limit, tabId, filter) or how to use them, leaving the agent to guess their meaning.

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 lists recent network requests (XHR/fetch/docs) from a real tab, including method/url/type/status. This distinguishes it from sibling tools like ff_clear_network and other ff_* tools.

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

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

No explicit guidance on when to use this tool versus alternatives. Mentions the need for a bridge add-on and real Firefox, but does not specify prerequisites 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 are provided, so the description carries the burden. It mentions the need for a running real Firefox with bridge add-on, which is a key behavioral prerequisite. However, it does not disclose other behavioral traits such as error handling, whether the tab is opened in background or foreground, or if it returns any result.

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

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

The description is concise with two sentences. The first sentence front-loads the action. It could benefit from a slightly more structured format, but it is not 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?

For a tool with two optional parameters and no output schema, the description is incomplete. It does not explain what happens if no url is provided, how the 'active' flag works, or any return value. Given the many sibling tools, more context on when to use this specific tool 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 description coverage is 0%, so the description must compensate. It does not describe the two parameters (url and active) at all, leaving the agent without context on how to use them. The parameter 'active' is particularly unclear without explanation.

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

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

The description clearly states the action ('Open a new tab'), identifies the specific resource ('your real Firefox'), and distinguishes from siblings like 'open_tab' by emphasizing 'real' and the required bridge add-on.

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 real Firefox with bridge add-on, but does not explicitly state when to use this tool versus alternatives like 'open_tab' for simulated browsers. There is no guidance on prerequisites 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 are provided, so the description carries the full burden for behavioral disclosure. It informs about the need for the bridge add-on and that it reads ‘real’ data including storage, which suggests a safe read operation. However, it does not clarify if the operation is destructive, whether permissions are needed, or what happens if tabId is omitted (assuming current tab). The description adds some context but leaves gaps about exact behavior.

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

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

The description is concise, consisting of two short sentences. Key information (what it does, what it includes, requirements) is front-loaded and easily digestible. No extraneous words 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?

Given the absence of an output schema and annotations, and a single parameter with no schema coverage, the description is incomplete. It fails to explain what ‘structured data’ means (e.g., DOM, storage objects), whether there are limitations on pages, or if the tool returns the data directly. The requirement of the bridge add-on is mentioned, but the overall depth is insufficient for an agent to fully understand the tool's capabilities and constraints.

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 optional integer parameter (tabId) with no description in the schema (0% coverage). The tool description does not explain the parameter's meaning or what happens when it is omitted (e.g., defaults to current tab). This is a significant gap because the agent cannot infer how to use tabId properly without additional 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 what the tool does: it reads a real tab from a running Firefox instance as structured data, including localStorage, sessionStorage, and cookies. This distinguishes it from siblings like read_page (likely for Chrome) and get_local_storage (which only retrieves storage). The specific verb 'Read' and resource 'real tab as structured data' make 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 explicitly notes that the tool works on a REAL running Firefox and requires the bridge add-on, which guides when to use it (only with the bridge add-on). However, it does not explicitly state when not to use it or mention alternative tools for other browsers or virtual environments. The implied context is clear but lacks explicit exclusionary 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?

In the absence of annotations, the description carries the full burden. It discloses the prerequisite (bridge add-on) and default behavior, but omits details on side effects (e.g., loss of unsaved data), error handling for invalid tabId, or whether the operation is synchronous or asynchronous.

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 with no fluff. The first sentence conveys the core action and default, and the second adds the operational prerequisite. Every sentence 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 tool with one optional parameter and no output schema, the description covers the essential aspects. It lacks mention of any return value or confirmation, but this is acceptable given the tool's low complexity.

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

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

With 0% schema description coverage, the description adds meaning by noting the default active tab when tabId is omitted. However, it does not explain the parameter's source (e.g., tab index vs ID from ff_list_tabs) or its format, leaving ambiguity.

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

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

The description clearly states the action ('Reload') and the resource ('a real tab') with the default being the active tab. It distinguishes itself from sibling tools like 'reload' by specifying it operates on the real running Firefox, making its purpose unambiguous.

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

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

The description implies usage for the real Firefox browser with the bridge add-on, but it does not explicitly state when to prefer this over the generic 'reload' sibling or other ff_* tools. No exclusion criteria or alternative recommendations are provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses that it captures the visible area (not full page) and requires the add-on, but does not mention side effects, output format details, 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 concise sentences with no redundant words. It is front-loaded with the primary action and format, followed by the prerequisite.

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

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

For a simple screenshot tool with one parameter and no output schema, the description provides essential context: output format (PNG), scope (visible area), and prerequisite. Could mention whether the output is returned as base64 or binary, but overall sufficient.

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

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

The input schema has one parameter (tabId) with 0% description coverage. The description does not explain what tabId refers to (e.g., from ff_list_tabs) or how to obtain it, leaving ambiguity for the agent.

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: screenshot the visible area of a real tab in PNG format. It distinguishes itself from generic sibling tools like 'screenshot' by specifying it operates on a real Firefox tab and requires the bridge add-on.

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 a prerequisite (bridge add-on needed) and implies it's for real Firefox tabs. However, it does not explicitly state when to use this tool over alternatives like 'screenshot' or other ff_* tools.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states it scrolls a real Firefox tab and auto-detects inner-scroll containers, but fails to describe what happens if both 'y' and 'selector' are provided, what constitutes a successful scroll, or any potential side effects. The bridge add-on requirement is noted 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 concise with two sentences, no redundant information. The main action is front-loaded. However, it could be slightly better structured by separating the two usage modes more clearly.

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 three parameters with 0% schema coverage, the description is insufficient. It does not specify required parameters, default behaviors, error scenarios, or return values. The tool appears to have two distinct modes but the description leaves ambiguity about parameter combinations.

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% (no parameter descriptions in schema). The description adds context for 'y' (by pixels) and 'selector' (element via selector) but does not explain 'tabId' or the interaction between parameters. It does not compensate enough 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 two distinct scroll operations (by pixels with auto-detect of inner-scroll containers, or scroll element into view via selector) and specifies that it operates on a real Firefox instance with a bridge add-on. This effectively distinguishes it from generic scroll tools like the sibling 'scroll'.

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 the prerequisite 'needs the bridge add-on loaded' but does not provide guidance on when to use this tool versus alternatives like 'scroll' or other sibling tools. No exclusions or contextual hints are given.

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

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

No annotations are provided, so the description fully handles transparency. It mentions the prerequisite but does not disclose return type or side effects. For a simple status check, this is adequate but not detailed.

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 wasted words. The description is front-loaded with the action verb and efficiently covers the prerequisite.

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

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

No output schema is provided, and the description does not specify the return value format or example. For a status check, stating true/false or detailed status 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 tool has no parameters, and schema coverage is 100%. The description adds no param information, which is acceptable. Baseline score for zero parameters is 4.

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

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

The description clearly states the tool checks the connection status of the real-Firefox bridge add-on, using specific verb 'Check' and resource 'connection'. It distinguishes from sibling tools that perform browser actions or navigation.

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 it operates on a real running Firefox requiring the bridge add-on, implying use for connection verification before bridge-dependent actions. However, it lacks explicit when-not-to-use or alternative statements.

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 full burden. It reveals the 'real tab' and bridge dependency but omits critical details: whether it clears existing text, handles errors, requires permissions, or modifies the DOM beyond typing. Lacks disclosure of 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 a single, concise sentence (28 words) that front-loads the main action. It efficiently conveys key context but could be better structured with separate clauses for prerequisites.

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 annotations and 0% schema coverage, the description is too brief. It lacks information on return values, error handling, prerequisites (bridge add-on loaded), and behavioral modifiers like clearing input or waiting. Incomplete for a typing tool.

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

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

Schema coverage is 0%, so description must compensate. It clarifies that 'selector' is a CSS selector, but does not explain 'text' (plain string?) or 'tabId' (target tab?). Adds minimal meaning beyond parameter 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 the action (type text), the target (input via CSS selector), and the context (real Firefox tab). It distinguishes from sibling 'type_text' by specifying the real Firefox requirement and bridge add-on dependency.

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: it operates on a real running Firefox with the bridge add-on. This implies when to use (when bridge is loaded) but does not explicitly exclude alternatives or state 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 exist, so the description must fully disclose behavior. It mentions the need for a bridge add-on and that it operates on a real Firefox, but omits details like timeout behavior, error handling, or whether the tool modifies state. This is insufficient for a wait tool.

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

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

The description is two sentences, front-loaded with the core functionality. It is concise, but could include necessary parameter details without becoming verbose.

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

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

Given no annotations, no output schema, and zero parameter descriptions, the description lacks critical details for effective use. It omits behavior on timeout, error handling, and full parameter semantics, making it incomplete for a tool with 3 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 0%, but the description only explains the 'selector' parameter as a CSS selector. It does not clarify 'tabId' (optional) or 'timeoutMs' (timeout meaning, default, etc.). Minimal value added 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 waits for a CSS selector to appear on a real Firefox tab, specifically for dynamic/scraped pages. It distinguishes from sibling tools like 'wait_for' (likely for standard browser) by emphasizing 'real tab' and 'REAL running Firefox'.

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 says it's for dynamic/scraped pages and requires the bridge add-on, providing clear usage context. However, it does not state when not to use this tool or mention alternatives among siblings like non-ff wait_for.

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 bears full responsibility. It only states a read operation, but lacks disclosure on safety, performance (e.g., potentially large list), authentication needs, or whether the operation 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 (4 words), but this brevity sacrifices necessary detail. It is front-loaded but incomplete.

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 simple tool (1 param, no output schema, no annotations), the description should at least mention the return format and the meaning of the profile parameter. It does not, leaving the agent underinformed.

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 does not explain the sole parameter 'profile' (type string, optional). With 0% schema description coverage, the agent receives no hint about what value to supply or how it affects the result.

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 'Read all bookmarks.' clearly identifies the action (read) and resource (bookmarks), distinguishing it from sibling tools like get_cookies or get_history. However, it does not account for the optional profile parameter, which could imply 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?

No guidance on when to use this tool versus alternatives (e.g., get_history, get_live_cookies). There is no mention of prerequisites, limitations, 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 are provided, so the description must carry full behavioral disclosure. It states it reports cache size and entry count, indicating a read-only operation, but does not mention error scenarios (e.g., if cache is empty) 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?

A single sentence that directly states the tool's purpose with no unnecessary words, making it highly concise 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?

While the description mentions the output (size and entry count), it lacks details on output format or error handling. For a simple reporting tool with no output schema, this is adequate but not comprehensive.

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

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

The input schema has one parameter ('profile') with 0% description coverage; the tool description does not explain what 'profile' means or its acceptable values, leaving a significant gap for the agent.

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 'Report HTTP disk-cache size and entry count' uses a specific verb ('Report') and resource ('HTTP disk-cache'), clearly distinguishing it from sibling tools like clear_disk_cache or get_cookies.

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., clear_disk_cache or other cache-related tools). The description implies usage for checking cache stats but lacks explicit context or exclusion criteria.

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

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

With no annotations, the description carries full burden. It discloses that the tool reads from an on-disk profile and works for closed tabs, which are key behavioral traits. It doesn't mention permissions or return format, but for a simple read operation, 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?

A single sentence of about 10 words, front-loading the action and source. No redundancy; every word adds value. Perfectly 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?

Given no annotations or output schema, the description covers the core purpose and key behavior (on-disk, closed tabs, optional filter). It lacks explanation of the 'profile' parameter, but for a simple 2-parameter tool, it is mostly complete.

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

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

Schema description coverage is 0%, so description must compensate. It explains 'host' as an optional filter, adding meaning. However, 'profile' parameter is not described; it likely specifies which browser profile, but the description gives no guidance. Baseline 3 due to coverage, partial 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 it reads cookies from the on-disk profile, including for closed tabs, which differentiates it from get_live_cookies (session cookies) and ff_get_cookies (Firefox-specific). The verb 'read' and resource 'cookies' are specific.

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

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

The description implies using this tool for persistent cookies or when cookies from closed tabs or the on-disk store are needed, contrasting with live session cookies. No explicit exclusions or alternatives are mentioned, but the context of sibling tool names provides 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?

No annotations are provided, so the description alone must disclose behavioral traits. It only states that it reads history ordered by recency, with no mention of side effects, authentication needs, rate limits, or return format—minimal for a read operation.

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

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

The description is a single, tightly written sentence with no filler. It front-loads the action and resource, earning its place.

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

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

Given the tool has 2 parameters, no output schema, and no annotations, the description is too sparse. It does not explain what the returned data looks like, pagination, or how profile and limit affect results, leaving significant gaps for an agent.

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

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

Schema description coverage is 0%, and the description adds no meaning for the parameters 'limit' and 'profile'. It does not explain their purpose, valid values, or effects, leaving the agent with no guidance beyond the schema's type constraints.

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

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

The description clearly states the verb 'Read' and the resource 'browsing history', and specifies the ordering 'most recent first'. This distinguishes it from sibling tools like get_bookmarks and get_cookies.

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 reading history but provides no explicit when-to-use, when-not-to-use, or alternatives. Context is clear but lacks guidance on exclusion criteria.

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

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

No annotations are provided, so the description carries full burden. It mentions using a COPY of cookies/sessions, implying non-destructive behavior, but does not explicitly state safety, permissions, or side effects. Lacks disclosure of whether browser state is affected or if preconditions like an open browser are required.

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 waste. First sentence states core purpose, second explains the parameter. Effectively front-loaded and efficient.

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

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

For a simple tool with one optional param and no output schema, the description explains the parameter well. However, it does not describe the return format (e.g., list of cookie objects) or mention any prerequisites like the browser must be started. This leaves some gaps.

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

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

Schema coverage is 0% (only type string, no description). The description adds significant meaning by explaining the 'useProfile' parameter can be a profile name or empty string for default, and its effect (copy vs clean browser). This goes 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 'Get cookies from the live browser context', specifying a retrieval operation. However, it does not differentiate from sibling tools like 'get_cookies' which may also retrieve cookies, missing explicit sibling differentiation.

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

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

It provides clear context on when to set the 'useProfile' parameter (profile name or empty string for default, omit for clean browser). However, it offers no guidance on when to avoid this tool or alternatives, such as when to use 'get_cookies' instead.

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 scope (every origin, LSNG+legacy) but lacks details on read-only behavior, response format, or side effects. No annotations provided.

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, but could more clearly separate the purpose and parameter explanation.

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

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

Missing critical information about return values, behavior of 'profile' parameter, and error handling. No output schema or annotations to supplement.

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

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

Only explains 'origin' filter partially; 'profile' parameter is completely undocumented despite being in the schema. Schema coverage is 0%.

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 reads localStorage for every origin, distinguishes from sibling tools like clear_web_storage, and mentions an optional filter.

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 when to read vs clear storage, or differences from cookie-related tools.

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

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

No annotations are provided, so the description must disclose behavior. It implies a read-only operation but does not clarify whether the tool is idempotent, what happens if no session exists, or any potential side effects. The description is minimally transparent.

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

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

The description is a single sentence that immediately states the action and resource. It is front-loaded with the verb and includes essential scope. Every word earns its place with no redundancy.

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

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

Given the lack of output schema and annotations, the description is insufficient. The agent has no information about the return format, pagination, or what constitutes a 'session'. The tool has many siblings, yet the description does not help differentiate.

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 'profile' with no description in the schema (0% coverage) and no explanation in the description. The agent cannot determine what this parameter does or how to use it correctly.

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

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

The description clearly states that the tool reads the current or last session and includes open and closed tabs. This distinguishes it from sibling tools like list_tabs (likely only open tabs) and get_history (browsing history). The verb 'Read' indicates a read operation.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_tabs, ff_list_tabs, or get_history. The agent is left to infer usage without any contextual hints.

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 does not disclose behavior such as what happens when there is no history, whether the operation is synchronous, or any side effects. Minimal 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?

Single sentence, front-loaded with the action and resource. No wasted words. 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 simple no-parameter tool, the description is adequate but incomplete. It does not specify behavior on empty history, error handling, or whether it affects other tabs. Slightly below the minimal viable level given the lack of annotations and 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?

The tool has no parameters and schema coverage is 100%. With 0 parameters, baseline is 4. The description adds no parameter details, but none are needed. Acceptable.

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 ('go back') and the resource ('active tab's history'). It is specific and matches the tool name, but does not explicitly differentiate from siblings like 'go_forward' or 'navigate', though the intent is clear.

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., 'navigate' or 'go_forward'). Does not specify when not to use or any prerequisites. The agent must infer usage 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 bears full burden of behavioral disclosure. It only states the action, lacking details on what happens when no forward history exists, whether it requires an active browser, or any side effects (e.g., page navigation).

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 with no extraneous words. Efficiently conveys the core action.

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

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

Adequate for a simple parameterless tool but lacks context on history behavior (e.g., it moves forward after going back) and when it is safe to use. No mention of error handling or browser state 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?

No parameters exist, so schema coverage is 100%. The description adds no additional semantic value, but the baseline of 4 applies as the tool has no 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 goes forward in the active tab's history, using a specific verb and resource. It distinguishes from sibling 'go_back' by implication, but does not explicitly differentiate from 'navigate' or 'reload'.

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 'go_back' or 'navigate'. No prerequisites mentioned (e.g., existence of forward history).

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 only states the basic action without mentioning what happens if the element is not found, whether events are triggered, 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 extremely concise at one sentence. However, it may be under-specified; slightly more detail would not significantly harm conciseness and would improve utility.

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 simple tool with one parameter and no output schema, the description is inadequate. It does not explain parameter semantics, behavior on failure, or return values, leaving significant gaps for an AI 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 the 'selector' parameter. It does not specify the format (e.g., CSS selector, XPath) or provide usage hints, leaving the agent without necessary details to construct valid input.

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 a hover over an element, using a specific verb and resource. It is easily distinguishable from sibling tools like click, type_text, or scroll.

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. There is no mention of prerequisites, context, or when hover is appropriate compared to other actions.

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 only states it lists profiles, lacking details on prerequisites (e.g., Firefox installed), blocking behavior, or output format.

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, front-loaded sentence with zero wasted words. Appropriate length for a simple tool.

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

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

For a tool with no output schema and no annotations, the description is somewhat incomplete. It doesn't explain the format of the list (e.g., names, paths). Adequate but with 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?

Tool has 0 parameters, so schema coverage is 100% trivially. Baseline for 0 params is 4. Description adds no parameter info, but none is 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?

'List local Firefox profiles' uses a specific verb (list) and resource (local Firefox profiles). It clearly distinguishes from sibling tools, none of which seem to list profiles.

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. Usage is implied (e.g., before starting a browser to see available profiles), but no exclusions or context provided.

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

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

No annotations are provided, so the description carries full burden. It discloses the non-destructive nature (listing tabs) and the behavioral effect of the useProfile parameter (using cookie copies vs. clean state). However, it does not mention error conditions or the format of the returned list.

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 with no wasted words. The purpose and parameter usage are front-loaded and clearly separated.

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 the operation, return fields, and parameter. Given no output schema, specifying return fields is sufficient. It could mention that the list is for the current browser context, but overall it is nearly complete for a simple list tool.

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

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

With 0% schema description coverage, the description fully explains the single parameter 'useProfile': setting it to a profile name or empty string uses a copy of real cookies/sessions, omitting it gives a clean browser. This adds essential meaning 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 lists open tabs and specifies the return fields (index, url, title, active). It distinguishes from sibling tools like open_tab, close_tab, and switch_tab by focusing on listing/reading, not modifying 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 description provides guidance on when to use the useProfile parameter (for authenticated sessions vs. clean browser), but does not explicitly state when to use this tool versus alternatives like ff_list_tabs or switch_tab. The context is clear but lacks exclusionary 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?

No annotations provided, so description carries full burden. Vague on return value ('it as data'), no mention of page load completion, error handling, or state changes beyond profile usage. Insufficient for an operation that modifies browser state.

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

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

Two sentences, front-loaded with primary action, no filler. 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?

No output schema, so return value needs explanation. Does not specify what 'return it as data' means (URL only? page content?). Missing details on when to use this vs sibling tools like ff_navigate or open_tab. Incomplete for 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 0% but description adds meaning: url is the target, useProfile specifies profile usage. Explains 'omit for a clean browser' and 'set to a profile name or empty string for default', which is helpful beyond 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?

Clearly states verb 'navigate', resource 'active tab', and outcome 'return it as data'. Distinguishes from siblings like open_tab (opens new tab) and ff_navigate (Firefox-specific).

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

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

Explains useProfile parameter for session handling but fails to differentiate when to use navigate vs other browser navigation tools (e.g., ff_navigate, open_tab). No explicit when-not or alternatives 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?

Without annotations, the description provides valuable behavioral details: it makes the tab active, and explains the profile behavior (copy of real cookies/sessions or clean browser). This goes beyond the basic schema, though it could elaborate on side effects like handling existing tabs.

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 concisely written with two sentences. The first sentence front-loads the core action, and the second sentence provides essential parameter guidance. No unnecessary words or repetitions.

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 (two optional parameters, no output schema), the description covers the main use case and parameter behavior. It could mention error conditions or interactions with other tools, but overall it is adequately 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?

The schema coverage is 0%, so the description compensates by explaining the 'url' as optional navigation and the 'useProfile' parameter's effect. This adds meaningful context beyond the schema's type definitions, though the exact format or consequences of omitting parameters could be clearer.

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 action: 'Open a new tab' and optionally navigate to a URL, making the active tab. This distinctively describes the primary function and differentiates it from sibling tools like 'close_tab' or 'switch_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?

While the description explains the optional 'useProfile' parameter and its effect (using a copy of cookies vs. clean browser), it lacks explicit guidance on when to use this tool compared to alternatives like 'ff_open_tab' or 'navigate'. No when-not-to-use 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?

No annotations provided, so description must disclose behavior. It mentions optional selector to focus first, but does not specify default behavior (e.g., key sent to active element), supported keys beyond examples, or side effects. Lacks key behavioral context.

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

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

Two concise sentences, front-loaded with action and examples. 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?

For a simple 2-parameter tool with no output schema, description covers basic purpose and usage. Lacks return value, error conditions, or detail on behavior when no selector is given.

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 0% description coverage, so description adds value with examples for 'key' and usage note for 'selector'. However, does not specify format constraints (e.g., case sensitivity, modifier keys). Moderate 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?

Description clearly states the verb 'Press' and resource 'keyboard key', with examples (Enter, Tab, Escape). Differentiates from sibling tools like 'type_text' and 'click' by focusing on key presses.

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?

Implied usage for pressing a single key, but no explicit when-to-use or alternatives. Does not say when not to use compared to 'type_text' or other keyboard actions.

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, and the description does not disclose behavioral traits such as side effects (e.g., whether network logs are cleared), required permissions, or output format. Given the tool captures many potentially sensitive aspects, this is a significant gap.

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

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

The description is a single sentence that packs substantial information without any wasted words. It is well-structured 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 complex tool with no output schema or annotations, the description lists captured data but lacks details on output format, error handling, or state requirements. It is adequate but not fully complete.

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

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

With zero parameters and 100% schema coverage, the description adds value by clarifying that the tool captures multiple data types. Baseline for 0 params is 4, and the description meets it.

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 'Capture' and identifies the resource as 'active tab', listing multiple data types (DOM/text/links/controls/cookies/storage/network/console). This clearly distinguishes it from sibling tools like 'screenshot' or 'get_cookies'.

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 comprehensive page data capture but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions 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?

Without annotations, the description simply says 'reload', which implies a standard browser refresh. Does not disclose if it uses cache or discards form data, but for a simple action it is minimally 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?

A single sentence that is perfectly concise and front-loaded. 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?

For a simple action with no parameters and no output schema, the description is adequate but lacks mention of prerequisites (e.g., a browser must be open) or return value.

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 (0 params). Schema coverage is 100%. The description adds no parameter details but none are needed; baseline 4 applies.

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

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

The description clearly states the action ('Reload') and the resource ('the active tab'). It distinguishes from sibling tools like 'navigate' or 'close_tab'.

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

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

No guidance on when to use versus alternatives like ff_reload or navigate. The description implies basic usage but does not provide context for selection.

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

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

With no annotations provided, the description carries full burden but only mentions basic output format. Lacks disclosure about destructiveness, permissions, synchronicity, or effect on page state.

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

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

Single sentence, 13 words, front-loaded with main action. Concise but missing crucial parameter info; could be slightly improved 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?

Given 0% schema description coverage, no output schema, and no annotations, the description is incomplete. It fails to document the only parameter or differentiate from the sibling 'ff_screenshot' beyond name.

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

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

Schema description coverage is 0% and the description does not mention the 'fullPage' parameter at all. The agent cannot infer its meaning 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 clearly states 'Take a PNG screenshot of the active tab (returned as an image),' specifying the verb, resource (active tab), format (PNG), and return type. It distinguishes from sibling 'ff_screenshot' by name.

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 vs alternatives like 'ff_screenshot' or other browser tools. No when-to-use or when-not-to-use context provided.

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

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

No annotations are present, so the description bears full responsibility for disclosing behavioral traits. It does not mention whether scrolling is a read-only operation, triggers events, or has side effects. The description adds minimal context beyond the obvious action.

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

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

The description is a single sentence, making it concise. However, it is overly terse and omits critical information, so it does not earn its place effectively. It could be restructured to include parameter details and usage notes 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 that there are 2 parameters, no annotations, and no output schema, the description is incomplete. It does not clarify if parameters are required, how they interact (e.g., using both y and selector), or what the result of scrolling is. The agent lacks essential 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?

With 0% schema description coverage, the description must explain the parameters. It does not: 'y' (presumably pixels) and 'selector' (CSS selector) are left undefined, and there is no explanation of defaults, constraints, or how they interact. This is inadequate for an AI agent.

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 scrolls the page by pixels or scrolls an element into view, specifying two distinct use cases. While it lacks explicit differentiation from sibling tools like ff_scroll, the core purpose is unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., when to scroll by pixels vs. into view, or when to use scroll over other navigation tools). There are no explicit when-not-to-use 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?

No annotations provided. Description does not disclose whether the tool clears previous selection, waits for options to be enabled, or handles dynamic dropdowns.

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 key action. 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?

Minimal information for a form interaction tool. No mention of return values, error states, or handling of non-existent options. With no annotations or output schema, more context 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 coverage is 0%. Description implies 'value' can accept either value or label, but does not clarify which parameter maps to which. No explanation of 'selector' (e.g., CSS selector or XPath).

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 ('Select'), the target ('<option> in a <select>'), and the method ('by value or label'). It distinguishes itself from sibling tools like 'click' or 'type_text'.

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

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

No guidance on when to use this tool versus alternatives like 'click' or 'type_text'. No context about prerequisites or fallback 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?

With no annotations, the description bears full responsibility for behavioral disclosure. It does not mention side effects (overwrites existing cookie), required permissions, or whether the change is permanent (persistent vs session). Minimal behavioral info.

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 but overly minimal; could benefit from a brief parameter summary without becoming verbose. It is not structured for quick scanning.

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 fails to provide sufficient context. Missing handling of cookie attributes, domain constraints, or expiration behavior. Severely incomplete.

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 description adds no parameter explanations. Agent has no insight into meaning of required fields (name, value, domain) or optional fields (path, secure, expires, httpOnly). Poor 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 action (Set), resource (cookie), and location (in the live browser). It is specific and distinguishable from sibling tools like get_cookies or clear_cookies.

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., eval_js for programmatic cookie setting) or prerequisites (e.g., existing browser session). The description lacks contextual usage advice.

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 states the basic effect (switch tab), but does not disclose what happens if the index is out of bounds, whether it works across browser windows, or any state changes beyond activation. For a simple tool, this is minimally 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, dense sentence with no unnecessary words. Every part earns its place.

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

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

Given the tool's simplicity (1 parameter, no output schema) and the presence of many sibling tools, the description is minimal but leaves out details like whether the index is relative to all tabs or only visible ones, and error handling. It is adequate for a straightforward switch, but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It indicates the parameter is an index, but does not specify whether it is 0-based, the valid range, or how it relates to the tab list from list_tabs. The schema already defines index as integer with minimum 0, so the description adds marginal 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 ('switch the active tab') and the method ('by index'). It provides a specific verb and resource, but lacks differentiation from sibling tools like 'close_tab' or 'open_tab', which also manipulate 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. There are many sibling tools for tab management (e.g., list_tabs, close_tab, navigate), and the description does not specify 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?

Discloses the default clearing behavior, which is important for understanding side effects. However, it does not explain what happens if the element is not found, whether it waits for the element, or how typing is simulated (e.g., key events vs. value setting). With no annotations, the burden is higher.

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

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

Single sentence, no fluff. Front-loaded with the core action and target, then the key behavioral note. Every word earns its place.

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

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

For a simple type action, the description covers the essential: what to type and where. But it omits return value, error handling, and whether the element is focused. With no output schema and 3 parameters, more context would be helpful (e.g., 'returns success or throws error if element not found').

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

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

Schema coverage is 0%, so the description must define parameters. It indirectly covers 'selector' and 'text' through the phrase 'by selector' and 'type text', and adds meaning for 'clearFirst' by stating the default. However, it does not explicitly describe the 'text' parameter or explain what 'selector' means (e.g., CSS selector).

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 'type text', the target resource 'input/textarea', and the method 'by selector'. It also specifies a key behavioral detail: 'clears it first by default'. This is distinct from sibling tools like 'click' or 'press_key'.

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

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

No guidance on when to use this tool versus alternatives like 'press_key' or 'eval_js'. It does not mention prerequisites, limitations, or conditions that would help an agent choose correctly.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It fails to mention timeout behavior, error handling (e.g., what happens if element never appears), or any side effects. The schema hints at a timeout parameter but the description does not elaborate.

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 no wasted words, but it is under-specified. For a tool with two parameters and no annotations, a slightly longer description would be more appropriate 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?

The description is far from complete given the tool's complexity, two parameters, no annotations, and no output schema. Essential information about parameter usage, behavior, and 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?

Schema description coverage is 0%, yet the description does not explain the 'selector' or 'timeoutMs' parameters. It only mentions 'element' generically, adding no meaningful semantics beyond the parameter 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 the tool's basic purpose: waiting for an element. However, it does not specify whether this applies to the current page, default browser, or any context, and it does not differentiate from similar sibling tools like ff_wait_for.

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 such as ff_wait_for, click, or navigate. There is no mention of prerequisites or conditions.

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