Jaimini — Aspects (Rasi + Graha drishti)

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

Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds that it computes aspects based on date/time/location, but does not elaborate on behavior, such as what happens if required parameters are missing, how errors are handled, or if any data is persisted. With annotations present, the description provides minimal additional behavioral context.

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 concise, front-loading the purpose and including a useful example. However, the example is placed at the end and the description lacks structured detail for many parameters, leaving gaps that could have been addressed without significant length increase.

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?

For a complex tool with 11 parameters, no output schema, and numerous sibling tools (including individual endpoints), the description is incomplete. It does not explain the output format, how to choose between tropical and sidereal zodiac, or clarify modality rules for rasi drishti. The grouping and example help, but many contextual aspects are 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 0%, so the description must explain parameters. It provides an example request body covering date, time, timezoneOffset, latitude, and longitude, but fails to explain the other 6 parameters (houseSystem, name, city, zodiacType, ayanamsaId, cosmogram). Users are left to guess their meanings and permissible values.

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 clearly states it computes combined Jaimini aspects (rasi and graha drishti) and explicitly identifies it as a convenience aggregate of two sibling endpoints `/drishti-rasi` and `/drishti-graha`. The title and group tag further reinforce its purpose.

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 mentions it is a convenience aggregate of two specific endpoints, implying this tool is for fetching both aspect types together. However, it does not explicitly state when NOT to use it (e.g., when only one aspect type is needed) or provide alternative tool names beyond the two endpoints.

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