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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the output is flags for follow-up, and the tool is not an authentication or fraud-proof mechanism, which sets correct expectations about the result.

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?

Three tight sentences: what it checks, how to supply data, and what it does not do. The enumerated checks come first and every clause carries information; nothing is redundant with the name or title.

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?

With no output schema, the description carries the burden of describing results and does so at a high level ("flags items for follow-up"). Combined with the annotations covering the operation profile, an agent has enough to invoke it correctly, though the exact shape of the flags is left unspecified.

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 only 45% across 11 parameters, so the description must compensate. It does so by tying the checks to the inputs (gross, deductions, net, hours × rate, period length, pay date, YTD totals), making the purpose of most parameters inferable even where the schema has no per-field description.

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 (checks) and resource (figures on a pay stub) and enumerates exactly what is validated: gross-minus-deductions vs net, hours × rate, SS/Medicare rates, period length, YTD totals, round numbers. This clearly separates it from sibling extraction/verification tools like monthly_income_from_pay and start_income_verification.

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?

"Read the numbers off the stub and pass them in" gives the operating context, and the closing sentence gives explicit exclusions (does not authenticate a document or prove fraud). It stops short of naming which sibling to use for verification/authentication instead, so alternatives are implied rather than stated.

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