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

With no annotations, the description carries the full burden and does so: it discloses data retention ('Raw text is never stored — only a content hash and the structured result'), metering with a concrete pricing formula and worked examples, plan-based input limits, caching behavior, and that every result reports au_cost. That is far more behavioral context than most definitions provide.

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?

Front-loaded with purpose and output shape before constraints and pricing, and every element is substantive rather than filler. It is, however, a single dense paragraph with stacked parentheticals (severity, enum values, pricing math), which taxes parsing compared to a lightly structured form.

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, no-output-schema, no-annotation tool, the description covers inputs, outputs, cost, retention, plan limits, caching, and the legal-advice boundary. An agent has everything needed to decide whether to call it, what to send, and what to expect back.

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 description coverage is 0%, so the description must compensate, and it largely does: it states the text range (100–150,000 chars, ≤50,000 on Free) and lists all eight document_type enum values. The remaining gap is that it never explains how document_type affects the analysis (e.g., which clauses are checked), leaving that choice unmotivated.

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 (first-pass review) and a tightly scoped resource (ONE contract), then enumerates exactly what the tool produces: summary, risk flags with severity, key terms, and presence/absence of 8 standard clauses with evidence excerpts. It is immediately distinguishable from the only sibling, check_usage, which it references explicitly.

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 when-to-use (first-pass review of a single contract), an explicit gating instruction ('Call check_usage BEFORE long documents'), and the condition that changes the decision (byte-identical re-analysis is 0 AU / cached:true). The 'ONE contract' framing and the 'NOT legal advice' disclaimer also set boundaries on when this tool is appropriate.

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