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

Annotations only declare readOnlyHint=false, openWorldHint=false, idempotentHint=false, destructiveHint=false, which conveys little about the actual flow. The description fills that gap well beyond the minimum: it explains the two-phase session model (returned session_url, user uploads off-server, then get_mail_analysis with session_id), the data-handling guarantee ('Photos are processed on LendMail and are not stored'), and the monetization disclosure ('may include a clearly disclosed affiliate link'). Nothing here contradicts the annotations, and the non-idempotent, non-read-only hints are consistent with creating a new session each call.

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 core purpose and the call sequence are front-loaded, and most sentences carry unique information (what is identified in the mail piece, the no-image-data rule, the privacy guarantee, the affiliate disclosure). It loses a point for redundancy: the opening 'use this when someone receives a credit or loan offer' and the closing 'Use LendMail when users ask for help understanding, evaluating, or decoding credit card and loan offers they received through postal mail' restate the same condition in different words.

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 session-initiating tool with one optional parameter and no output schema, the description supplies everything an agent needs: the trigger, the exact two-step invocation sequence with the user in the loop, what the eventual analysis contains, and the data-handling constraints. The absence of an output schema is compensated by the explicit enumeration of analysis outputs.

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?

There is a single optional 'note' parameter whose schema description already covers it at 100%, so the schema does the heavy lifting. The tool description never mentions the note field or what it is used for, adding no meaning beyond the structured field. With full schema coverage and only one optional parameter, the baseline 3 is appropriate.

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 names a specific action and object ('Analyze a photo of a mailed credit card offer, prescreened credit offer, personal loan offer...') and then enumerates exactly what it outputs: lender identity, credit type, advertised rates/terms/fees, fine-print red flags, and an overall offer score. That level of detail separates it cleanly from get_mail_analysis, which the description explicitly positions as the follow-up step.

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?

It states the triggering situation ('when someone receives a credit or loan offer in the mail and wants help understanding what it actually offers, evaluating its terms, or deciding whether it deserves further consideration'), the explicit exclusion ('Do not send image data to this server'), and the alternative path ('then call get_mail_analysis with the session_id'). Both when-to-use and how it hands off to a sibling are spelled out rather than inferred.

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