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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, and the description does not contradict them. Beyond that it discloses genuinely useful behavior the annotations cannot convey: NAV-on-due-date with holiday rollover, the full return payload (instalments, invested, units, current value, absolute gain, XIRR, year-by-year summary), step-up support, and explicit exclusions (stamp duty, exit load, tax, no future projection).

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?

Purpose is front-loaded in the first clause, followed by mechanics, then output shape, then limitations. No redundant sentences and no repetition of what the schema or annotations already state.

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 compensates by enumerating the returned metrics, and it discloses pricing behavior and model limitations for a 5-parameter simulation tool. Nothing material an agent needs to call it correctly or interpret the result is missing.

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 100%, so the baseline is 3, but the description adds real semantics beyond the schema: the holiday-rollover rule that governs how start_date/end_date instalments are priced, and confirmation that annual_step_up_pct drives a yearly increase in the SIP amount. The remaining parameters (scheme_code, monthly_amount) are already fully documented in-schema and add nothing in the text.

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 precise verb (simulate) and resource (monthly SIP in one Indian mutual fund scheme) and explains the core mechanics: each instalment buys units at the NAV on its due date or the next NAV date after a holiday. The word 'monthly SIP' inherently separates it from the sibling calculate_lumpsum_returns, which an agent can distinguish without opening either 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 an explicit usage cue: "Use for 'what would my SIP be worth' questions." It also carves out scope limits (ignores stamp duty, exit load and tax; can't project future returns), which effectively tells the agent when not to rely on it. It stops short of naming the alternative tool (calculate_lumpsum_returns) for one-time investments, so it is clear context rather than full when/when-not routing.

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