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

With no annotations provided, the description carries the full disclosure burden and does substantial work: it warns that actions run against the live site and that form submission can create persistent external side effects, and it states a bounded timeout and what the return payload contains. It stops short of session lifecycle details (what 'reuse' means, whether sessions persist after return) and any authentication or rate-limit 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?

Two sentences, both front-loaded: the capability statement comes first, the risk and return information second. No filler, no restatement of the tool name, and the side-effect warning is placed where an agent will read it before choosing arguments.

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 a 0-annotation, no-output-schema, 8-parameter tool with a deeply nested options object, the description covers the core mechanics and the return shape but leaves the entire scrapeOptions tree and session/conversation continuity unexplained. An agent can invoke it with a url plus prompt, but cannot confidently configure the options or chain sessions.

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

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

Schema description coverage is only 13%, so the description must compensate, and it does explain the two alternative entry points (url vs scrapeId) and the two execution modes (prompt vs code) plus language choices — none of which are documented in the schema. However, the large nested `scrapeOptions` object (proxy, formats, profile, jsonOptions, screenshotOptions, etc.) and `conversationId` receive no mention, leaving most of the parameter surface undocumented in prose.

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 names a specific verb set (open/reuse a session, navigate, click, fill, run code) against a specific resource (a live browser session), which is far more informative than the tool name alone. It does not name the sibling it supersedes — notably firecrawl_scrape for static fetching or firecrawl_interact_stop for ending a session — so differentiation is left to inference.

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 gives conditional input guidance ('provide either `url` or `scrapeId`, and either a natural-language `prompt` or executable `code`'), which is closer to parameter pairing rules than to when-to-use guidance. There is no statement of when this is preferable to firecrawl_scrape, nor any exclusion such as avoiding it for simple static extraction or destructive form submissions.

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