http_check

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

With no annotations, the description carries the full burden and does so well: it discloses safety behavior (sends no cookies or credentials), resource limits (1 MiB body, 10 redirects, 30-second timeout), and the exact diagnostics produced. It stops short of saying whether the request is retried or how failures/timeouts are surfaced in the response, which keeps it below a 5.

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?

Front-loaded with the core action, then structured into per-hop output, final-response judgments, and safety limits. No sentence is filler, and the list of limits is compact enough to scan in one pass.

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 (one required parameter, no nesting), an output schema exists so return structure needn't be described, and the description still covers purpose, limits, and the key parameter caveat. Nothing an agent needs in order to call it correctly 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% for the single `url` parameter, and the description compensates with a genuinely useful semantic: 'url may omit the scheme (https assumed)'. That is exactly the ambiguity an agent would hit, though nothing is said about query strings, ports, or non-HTTP schemes.

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 opens with a specific verb and resource ('Follow a URL through its redirects and time every hop') and then names exactly what is measured per hop and on the final response. That scope is distinguishable from siblings like tls_check and dns_lookup, which cover narrower slices of the same request lifecycle.

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?

Usage is implied rather than stated: an agent can infer this is for diagnosing redirect chains and end-to-end HTTP behavior, but the description never says when to prefer it over security_headers or tls_check, even though it overlaps both (HSTS, HTTPS downgrade). No explicit exclusions or alternatives are given.

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