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

Annotations already cover the read-only, idempotent, non-destructive, closed-world profile, and the description still adds substantial context: heuristic and English-centric algorithm, the 'new is not proof' limitation, no corpus retention, sub-0.5s latency, USD 0.003 price with no free tier, and no logging/storage of submitted text. It even flags returned page text and on-chain strings as untrusted data, which is real operational guidance.

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 purpose, verdict vocabulary, and matching logic are front-loaded, and the pricing/privacy/security boilerplate is compressed into short clauses. It is dense and run-on in places (pricing, latency, and safety warnings all crammed into the same paragraph), but virtually every sentence carries decision-relevant information.

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 4-parameter, fully-documented tool with an output schema, the description supplies everything an agent needs: what it does, what it returns conceptually, its accuracy limits, cost, latency, and data-handling posture. There is no gap an agent would have to guess at before calling it.

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%, so the baseline is 3; the description earns an extra point by explaining the matching model behind the parameters (cosine of words and word pairs at 0.08 threshold with two shared words, or three shared multi-digit numbers) and the 1-50 corpus bound. Some of this overlaps the schema's own threshold description, but it adds interpretable meaning rather than merely restating it.

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 and resource ('check whether a draft repeats your earlier texts') and names the exact output verdicts (duplicate, near, new). An agent can distinguish this from near-siblings like text_similarity, diff_text, or compare_documents without opening any schema.

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 a clear use context ('before publishing') and an explicit negative constraint that shapes correct use: 'No saved corpus; check every flagged text,' plus the caveat that a 'new' verdict is not proof. It does not name an alternative sibling or when-not-to-use-it, so it falls short of a 5.

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