Fetch URL

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the behavioral detail that 'Response size is capped,' which is useful context for understanding limits. However, it does not disclose the actual cap value, any authentication requirements, or error/redirect behavior. Given the annotations carry the main safety profile, a 3 is appropriate.

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 short sentences with no filler. The core purpose is stated first, and the relevant limitation (response cap) follows immediately. Every sentence contributes useful information.

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

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

For a tool with 0% parameter schema coverage, the description omits crucial details about both configurable parameters (max_chars, timeout_seconds) and how to set them. It also lacks any guidance to differentiate from similar sibling tools. The output schema's existence reduces the need to describe return values, but the parameter and usage gaps leave the description incomplete 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 0%, so the description carries the full burden of explaining the parameters. It fails to mention max_chars or timeout_seconds at all. The statement 'Response size is capped' only vaguely hints that a cap exists without connecting it to the max_chars parameter, and timeout behavior is completely undocumented. This falls far short of compensating 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 states a specific verb and resource: 'Fetch an http(s) URL from the host and return its text.' It clearly identifies the tool's primary action and output. However, it does not distinguish itself from siblings like browser_fetch or fetch_text, both of which could plausibly perform similar URL fetches.

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 browser_fetch or fetch_text. The description says nothing about scenarios where server-side fetching is preferred, or when a browser-based fetch or local file text extraction would be more appropriate. The phrase 'from the host' hints at one differentiator but does not give actionable selection guidance.

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