ff_read_page

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.