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

With no annotations, the description carries the full burden and does substantial work: server-side safe following, verdict taxonomy, per-item refusal of private/internal links, per-item invalid reporting, and batch atomicity ('one bad entry never fails the batch'). It omits auth/permission requirements and whether results are cached or live.

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?

Four tightly packed sentences, front-loaded with the core action and capacity limit, followed by return shape and error semantics. Every clause adds information an agent needs; nothing is boilerplate.

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?

There is no output schema, and the description compensates well by naming the verdict values, the warning score, and the warning flags returned per link, plus per-item failure behavior. Minor gaps remain around latency, caching, and any authentication needs.

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% with a single parameter, so the schema already documents the urls array, the 1-25 range, and the http:// or https:// requirement. The description largely restates the same constraints rather than adding new meaning, so the baseline 3 applies.

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 concrete verb and resource ('screen up to 25 links in one call') and the batch limit implicitly separates it from the single-link sibling check_url. It never names check_url or check_message explicitly, so the differentiation is inferable rather than stated.

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?

Usage is implied by the batch framing ('up to 25 links in one call'), and the cost note ('one screen counts as one free check') hints at when bulk screening is worth it. There is no explicit when-to-use vs check_url guidance or any exclusion criteria.

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