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

With no annotations provided, the description carries the full disclosure burden. It does add useful behavioral information by stating that the body is discarded and only status/content type are returned, which prevents agents from expecting page content. However, it omits other relevant behaviors such as redirect handling, timeout behavior, failure modes, and whether JavaScript rendering is performed.

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 and front-loaded, with no filler or redundant wording. Every phrase earns its place, but it is somewhat undersized for a tool with nine optional parameters and many sibling tools.

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 the tool has no output schema, no annotations, nine optional parameters, and a large set of related siblings, the description is not complete enough. It explains one narrow use case but fails to inform the agent about the other parameters, the expected return shape, or how web-fetch relates to sibling tools.

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?

The input schema covers all parameters individually with descriptions, but the tool description only mentions URL and does not clarify the role of the other eight optional parameters (ref, city, feed, host, json, path, zone, query). This mismatch is confusing: the description implies a simple URL-only tool while the schema accepts many unrelated inputs.

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 clearly states that the tool returns HTTP status and content type for a public URL, and 'Body discarded' signals a distinct scope. It lacks an explicit verb and does not differentiate itself from siblings like fetch-status or browser-url-ok, but the core purpose is still understandable.

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?

The only usage constraint is 'public URL', with no guidance about when to prefer this tool over the many related siblings such as fetch-status, browser-url-ok, normalize-url, or playwright-url-ok. There are no decision rules, exclusions, or alternative tool mentions in the description.

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