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

The only behavioral disclosure is 'Body discarded', plus incidental hints in the schema ('no disk access', 'discarded after the check'). With zero annotations, the description carries the full burden, yet it does not say whether any network request is made, whether this is a local shape check, what the returned status values mean across the heterogeneous inputs, or whether the operation has side effects. An agent is left guessing about the tool's actual 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?

The text is very short and the core claim is front-loaded, which is structurally efficient. But for a tool with 9 optional heterogeneous params and zero output schema, this length is under-specification rather than strengths-conciseness; it does not earn all the info that would fit in a few additional sentences.

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 9-parameter, zero-required tool with no annotations and no output schema, the description must explain the input-selection behavior and the return semantics. It does neither: it never says which of the 9 params is primary, what prevents a call, what statuses are returned for valid or invalid inputs, or what happens when multiple params are populated. An agent cannot confidently invoke this tool correctly.

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% — all 9 parameters carry explanatory text (e.g., 'HTML text to validate; discarded after the check', 'No disk access', 'Discarded after the shape check'). This matches the baseline of 3; the main description contributes no parameter meaning beyond the word 'URL', and it actually muddies which parameter is the operative one.

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 verb and resource ('HTTP status for a public library docs URL') and adds that the body is discarded, so it is not a tautology. However, it badly misrepresents the input surface: the schema exposes 9 heterogeneous optional params (city, ref, json, zone, path, query, feed...), none of which corresponds to a 'public library docs URL' (the URL param is described as 'HTTPS URL to normalize or cite'). An agent reading the description and then the schema cannot tell what resource the tool actually operates on, which makes the stated purpose more misleading than clarifying.

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 no guidance at all about when to use this tool, when not to, or which alternatives to prefer. This is especially harmful given the sibling list contains overlapping URL/HTTP tools such as fetch-status, browser-url-ok, playwright-url-ok, normalize-url, and web-fetch; the description offers no selection criteria among them, so an agent must guess.

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