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

Annotations are all false, so the description carries the full behavioral burden. It discloses determinism ('not AI-generated content'), the French-only legal document plus optional non-binding English appendix, the 24-hour single-use link and deletion lifecycle, per-network caps and rate_limited response, and an instruction to have the landlord verify every field. This is exceptionally transparent.

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 description is heavily padded with marketing and account-tier/pricing details ('€4.90 — one document... €49 — 50 documents...') and the bilingual headline duplicates the same 'free, no account' information. While the essential behavior is front-loaded, much of the length is not needed for correct tool invocation.

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 tool with no output schema, the description explains the core outcome: a French legal PDF, a 24-hour single-use link, deletion after 24 hours, and a structured rate_limited result. It also covers per-network caps and the landlord-verification step. The only gap is an exact description of the response envelope/field names, but the provided lifecycle and legality details make it sufficiently complete.

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 loosely lists field groups (landlord, tenant, property, period, rent/charges, payment date) and clarifies includeEnglish's non-binding role, but the schema already documents every parameter, including locale and receipt-month derivation. No meaningful parameter semantics are added beyond that.

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 it produces a 'Rent receipt (quittance de loyer, loi n° 89-462 art. 21) PDF' from user-supplied data, naming the specific resource and legal basis. This clearly distinguishes it from the sibling calculators/checkers, which solve numerical or eligibility questions rather than generating documents.

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?

Provides rich context: free, no account needed, 24-hour single-use link, per-network caps, payment happening in the browser rather than through the agent, and 'not legal advice'. However, it never explicitly names an alternative tool or says when not to use it, so it reaches clear-context but not explicit exclusion.

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