Web: search, fetch and crawl

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

Annotations already declare openWorldHint=true, readOnlyHint=false, and destructiveHint=true, but the description adds meaningful context beyond them: outbound network access, Firecrawl billing, and short-lived crawl jobs. It also states the return types, which helps set expectations for a potentially costly or state-changing 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?

Three compact sentences front-load the primary actions and follow with operational constraints and alternatives. Every clause contributes relevant information without redundancy or filler.

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

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

Despite 9 parameters and 5 actions, the description covers the essential selection context: public web vs authenticated/local alternatives, network access, billing, crawl job behavior, and return types. The schema handles parameter details, and no output schema exists, so the description is complete enough for correct invocation.

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

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

Schema description coverage is 100%, and the action enum description documents required parameters per action. The description adds no additional parameter-level syntax or mapping beyond what the schema already provides. Baseline 3 is appropriate when structured fields fully carry parameter semantics.

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 the core actions (search, fetch, Firecrawl search/scrape/crawl) and the resource (public web, Firecrawl). It explicitly distinguishes from sibling tools by naming navig_connectors and navig_knowledge as alternatives for authenticated and local data. An agent can identify exactly what this tool does without opening the schema.

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

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

It provides explicit alternatives for different data sources: 'Use navig_connectors for authenticated provider data and navig_knowledge for local docs.' This tells the agent when to choose those siblings instead, and the opening line implies the public-web use case for this tool. The billing and job notes add operational context that shapes invocation decisions.

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