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

Annotations are absent, so the description carries the disclosure burden. It does disclose non-obvious behavior: the 'Always includes an analysis block' guarantee, the per-method differences in return content, and the fact that bhava_chalit can move a planet's house. It could mention error handling or caching side effects, but none exist for a read operation, and no annotation conflicts arise.

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?

The description is compact yet information-dense. It front-loads the purpose, then uses a tidy Args list and a short paragraph for the analysis block. Every sentence adds a useful detail, and none are redundant. It earns its length.

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 no output schema, the description does a strong job of explaining both the per-house output (by method) and the always-present analysis block. It doesn't detail the exact JSON field names or error conditions, but an agent has enough to invoke the tool correctly and interpret the major output. It could have explicitly stated that chart_id must reference an existing chart, but this is implied by 'cached chart.'

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 parameter descriptions are completely absent (0% coverage), but the description fully compensates. It defines chart_id explicitly as a handle from create_chart and explains each method value in detail: whole_sign returns sign, lord, lord placement, karaka, occupants; bhava_chalit uses Sripati/Porphyry cusps and can change house; kp_cusps uses Placidus cusps with sub-lords. This is more informative than a typical schema enum.

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?

The description begins with a specific verb and resource: 'Get the 12 houses (bhavas) for a cached chart.' This clearly identifies the tool's main function and ties it to a prerequisite (a cached chart from create_chart). It doesn't explicitly name sibling tools, but the purpose is narrow enough to be distinguished from related tools like get_grahas or describe_chart.

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 gives clear context on when to use the tool: it operates on a cached chart and offers three explicit method choices. It explains what each method provides, including the edge case where bhava_chalit can assign a planet to a different house than whole-sign. However, it doesn't state when to prefer this tool over sibling tools, so no explicit 'when not to use' guidance is present.

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