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

The description discloses 'No browser is launched,' but annotations are absent and the description does not reveal whether a network request is made, whether the URL is only syntax-checked, or why many input fields are marked 'discarded.' The parameter descriptions hint at side-effect-free checks, but actual behavior remains opaque.

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 very short, free of fluff, and easy to read. However, the brevity omits essential operational details, so it is concise but not optimally informative.

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 optional parameters, no required fields, no output schema, and multiple similarly named sibling tools, this description is severely incomplete. It does not explain return values, success criteria, parameter selection, or edge cases, leaving an agent unable to reliably invoke or interpret the tool.

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?

Although the schema has 100% description coverage, most parameter descriptions are unrelated distractors (e.g., city, feed, zone) and do not explain which field is the actual URL to test or how optional parameters interact. The 'url' parameter is described as 'HTTPS URL to normalize or cite,' conflating this check with normalization and citation tools.

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 simple purpose, 'Check whether a URL can be opened,' but does not define what 'ok' means or distinguish this tool from siblings like fetch-status, playwright-url-ok, and web-fetch. The input schema with 9 unrelated optional parameters further blurs the actual intended use.

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 about when to choose this tool over similar URL/status/shape tools. The description only gives a generic capability and does not mention requirements, limitations, or typical scenarios.

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