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

Goes well beyond the annotations: discloses the inbox lifecycle (file waits, person starts a case from it, expiration if none), the live-key requirement with a concrete fallback for test keys, the account/auth prerequisite, the 700 KB vs 4 MB transport limit, and the return payload. The note that each call sends one more file while a repeated idempotencyKey returns the first answer is consistent with idempotentHint=false (non-idempotent by default, opt-in safety via key), so this is additive context rather than a contradiction.

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 the usage condition before mechanics, and every sentence carries information (alternatives, limits, auth, returns). It is dense and runs long, reading as a single block rather than clearly separated usage/behavior/return sections.

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?

No output schema exists, yet the description names the return fields (id, type, guessed purpose, inbox expiry), and it covers auth, key type, size limits, and the sibling alternative. An agent has everything needed to call this correctly on the first try.

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, but the description adds routing-relevant meaning: it names filename/contentBase64/purpose/note as the inputs, explains the size ceiling that forces the direct API path, and clarifies that purpose is optional and guessed. It repeats some schema text (enum values, max size), which caps this below 5.

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 ('send a file to Evictions API before a case exists') and immediately scopes it against the sibling that does the same thing for existing cases. An agent can distinguish it from evictions_add_case_document and evictions_create_case 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 explicit when-to-use ('when the person asks you to send a file ... before a case exists'), explicit when-not-to-use ('Do not use this when the case already exists (use evictions_add_case_document)'), and a third routing rule for test keys ('create a test case and use evictions_add_case_document'). It also warns not to create the case itself. Nothing is left to inference.

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