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

Annotations already cover the safety profile (readOnly, non-destructive, idempotent, closed-world), and the description adds genuinely new behavior: 'never fetches, crawls or resolves the URL' plus a warning about what the result does not imply. This is the kind of non-obvious operational context annotations cannot express.

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?

Three short sentences, front-loaded with what it is, then when to use, then the negative boundary. No filler and no repetition of the title.

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?

For a single-parameter validator with no output schema, the description covers scope, limitations and side-effect profile. The one remaining gap is the return shape (presumably a boolean) and how strict 'conservative' actually is, which the agent must infer from the name.

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 schema itself explains the accepted form ('Absolute HTTP(S) URL string; other schemes such as javascript: are not supported'). The description adds only the word 'conservative', with no detail on which edge-case URLs pass, so it is baseline-adequate rather than additive.

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?

States a specific verb+resource ('Conservative HTTP(S) URL syntax') and immediately disambiguates from an actual network check with 'no HTTP request'. Within a sibling family of is-*-safe validators, the resource (HTTP(S) URL) is unmistakable.

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?

Gives an explicit use case ('before displaying or saving it') and an explicit anti-use case ('Do not use this to establish that a site is safe, accessible or trustworthy'). The most likely agent misreading of a tool named 'is-url-safe' is neutralized directly.

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