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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine context by disclosing the ranking methodology and that every pass/fail reason plus a draft source key is returned, but says nothing about cost, runtime, or what happens when no window passes.

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 the operation and its methodology front-loaded and no filler. The density borders on jargon-heavy, but no sentence is wasted.

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?

The output schema exists, so return values need not be restated, and annotations cover safety. Still missing for a 10-parameter tool with nested objects: any explanation of the location input modes, the natal object, or how this differs from the natal-fit sibling, leaving real gaps before a correct call.

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 only 30% across 10 parameters, so the description must compensate and does not. It never explains the place-vs-latitude/longitude/timezone alternative, the limit cap, the date-range format expectations, or what the nested natal object unlocks — 'optional Tara/Chandra Bala' is the only nod to a parameter and is not mapped to one.

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 and resource ('Ranks candidate windows over a bounded date range') and enumerates the scoring factors, so the operation is unmistakable. It does not, however, distinguish itself from near-siblings such as find_muhurta_with_natal_fit or find_marriage_windows, leaving the agent to infer the boundary.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The phrase 'optional Tara/Chandra Bala' hints that natal data is not required (implying find_muhurta_with_natal_fit is the natal counterpart), but the agent must infer that routing decision rather than being told.

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