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

No annotations are provided, so the description carries the full burden, yet it discloses behavior for only one of nine modes: HEAD (non-destructive, no body) and status-only return. The disposal semantics of the other eight inputs ('discarded after the shape check', 'titles discarded', 'no disk access') live only in the schema, and the tool's central trait — that it validates any one of several input shapes and returns a status — is never stated.

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 single sentence is terse and front-loaded, but its brevity is achieved by omitting the tool's actual surface: nine input modes condensed into 'a public URL.' This is under-specification rather than successful conciseness, since the sentence describes a different (narrower) tool than the schema defines.

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?

With 9 parameters, 0 required, no annotations, and no output schema, the tool-level description needed to explain that exactly one input is expected and what 'status' means (HTTP code vs boolean vs envelope). Instead only the URL case is described, leaving the agent unable to determine correct invocation for the other eight modes; the rich schema param descriptions partially compensate, which keeps this above a 1.

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 coverage is 100% and the per-parameter schema descriptions are genuinely informative (input purpose plus disposal behavior), so the schema does the heavy lifting and the description itself adds no parameter detail. It is not neutral, however: 'HEAD a public URL' contradicts the schema's own url semantics ('HTTPS URL to normalize or cite'), actively reducing the description's value below the coverage-100% baseline.

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 concrete verb and resource ('HEAD a public URL ... status only'), which is clear for a narrow URL case, but not for this tool: the schema exposes nine distinct input modes (ref, city, feed, json, path, zone, query, host, url) whose checks have nothing to do with HTTP HEAD. The description therefore materially misrepresents the tool's scope and does nothing to separate it from URL-related siblings like web-fetch, playwright-url-ok, browser-url-ok, or normalize-url.

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?

There is zero when-to-use or when-not-to-use guidance and no mention of alternatives. Worse, the only usage the description implies — 'use this to HEAD a URL' — is contradicted by the schema, where url is described as 'HTTPS URL to normalize or cite' and where seven other parameter modes exist, so an agent would be actively misdirected rather than merely unguided.

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