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

With no annotations at all, the description carries the full burden and meets it: it states that noon is not substituted, which outputs are omitted without birth time, that preview returns three lines plus chart_id, and that chart_id is a reusable handle. This is meaningful behavioral disclosure beyond the schema.

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?

Five dense sentences, each carrying operational value, with the core purpose declared first and the most important warnings (time optional, chart_id reuse) placed prominently. No filler or repetition.

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 10-parameter, 0-required tool with no annotations, the description covers the non-obvious conditions that determine the output: missing time behavior, place specification alternatives, detail levels, and chart_id lifecycle. An output schema exists, so return-value documentation is not needed here.

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 0%, so the description must compensate. It adds semantics for place/geonameid, time optionality, detail levels, and chart_id precedence. It does not explain the cryptic house_system letters, ayanamsa options, or 'podrobno', but those are at least surfaced via enums and defaults, and the most error-prone parameters are covered.

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 opens with a specific verb+resource: 'Натальная карта по джйотишу' and enumerates the chart components (graha positions, Moon nakshatra, lagna, vimshottari dashas, current period). It also distinguishes itself from siblings by naming downstream tools that consume its chart_id, so an agent can tell it apart.

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?

It explicitly explains how to specify the place (place or geonameid from find_place), that birth time is optional and what will be missing without it, how detail changes the payload, and how chart_id should be reused in later calls. It even gives an exclusivity rule: explicit user corrections override chart_id.

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