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

With no annotations, the description must carry the behavioral disclosure burden. It adds one meaningful trait: page content is not stored, which assures the agent about side effects and retention. It does not disclose other behaviors such as whether the URL itself is logged, whether a network request is made, or how invalid URLs are handled.

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?

Two sentences with no filler. The primary function is front-loaded in the first sentence and the non-storage guarantee follows naturally in the second.

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 description gives the essential return fields and one behavioral fact, but with many optional schema parameters, no annotations, and no output schema, an agent must infer which parameters actually matter and what the response shape is beyond the three named fields. It is minimally adequate but leaves room for ambiguity.

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 already documents each parameter, so the baseline is 3. The description adds little beyond identifying the URL as the key input and does not clarify the relevance of the many optional parameters such as city, feed, or json.

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 uses a specific verb and resource: 'Return host, scheme, and HTTP status for a URL.' It is clear about what the tool computes, and the note that page content is not stored distinguishes it from content-fetching tools, but it does not explicitly differentiate it from siblings like fetch-status 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?

No guidance is given about when to choose this tool over alternatives. The only related statement is the exclusion that page content is not stored, which hints that this is not a content-fetch tool but does not explain when to use citation versus fetch-status, web-fetch, or normalize-url.

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