calculate_lot_gain

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

No annotations are provided, so the description carries full burden. It does disclose key behavioral traits: the two calculation modes, defaulting to latest price, defaulting to all remaining shares. However, it doesn't disclose what 'capital gain' means operationally (e.g., how cost basis is computed), whether this is read-only, or the return format. With an output schema present, some of this is mitigated, but the mutation vs read nature is not clear from the description alone.

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-sentence functional summary followed by a clean Args section. Every sentence earns its place: the mode distinction, the defaults for each parameter, and the lot GUID format. No filler or redundancy. Well front-loaded with the core purpose in the first sentence.

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?

Given 3 params, an output schema present, and a moderately complex two-mode calculation tool, the description covers the mode logic, parameter defaults, and lot identification. It could further explain gain semantics (capital gain formula) or clarify this is a read-only calculation, but for a calculation tool the mode disambiguation is the critical completeness element. The output schema covers return expectations.

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 33% (only lot_guid has a description in the schema). The description compensates well: it explains lot_guid format (GUID or 8+ char prefix), explains shares defaults to all remaining shares, sale_price defaults to latest price. This adds significant semantic meaning beyond the bare schema, which only describes lot_guid. The shares and sale_price descriptions are absent from schema but well explained in the 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?

Description opens with a specific verb+resource ('Calculate potential or actual capital gain for a lot') and clearly distinguishes between the two modes: hypothetical gain (with shares+sale_price) vs actual/current gain (using lot state and latest price). This clearly separates it from sibling tools like get_lot, get_latest_price, close_lot, and net_worth.

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 description explains the two usage modes with clear conditions ('If shares and sale_price provided, calculates hypothetical gain. Otherwise uses lot's current state and latest price.'). It doesn't name explicit alternatives, but the mode-based branching gives strong functional guidance. It lacks exclusions or when-not-to-use statements, but context for both invocation paths is clear.

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