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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description still adds real behavioral value beyond them: the prerequisite of a completed verification and, importantly, the instruction to 'present figures as estimates, never as verified or approved income,' which shapes how an agent must handle and report the results.

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?

Two tight sentences with zero filler; the tool's output contents are front-loaded and the interpretational caveat follows immediately. Every sentence earns its place.

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 usefully enumerates the returned fields, and it flags the estimation caveat. It falls short only on parameter semantics and on failure/prerequisite behavior, which are minor gaps for a single-param read tool.

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% for the single required verification_id, so the description carries the burden of explaining it. It only obliquely hints at the parameter via 'a completed verification' and never states that the ID must reference a finished verification or what formats are valid, leaving the required parameter largely unexplained.

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 ('Returns') and resource ('income analysis... for a completed verification') and enumerates the payload (estimated monthly income, income sources, other deposits, account balances). It is clearly distinguishable from siblings like monthly_income_from_pay or get_account, though it never explicitly contrasts itself with them.

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?

The phrase 'for a completed verification' implies a prerequisite (the verification must be finished), which is useful usage context. However, there is no explicit when-to-use/when-not, no guidance on what happens with an incomplete verification_id, and no routing to the many sibling income tools.

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