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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the tool does not perform rectification and will report commonalities, possible lagnas, and indeterminacies. This is useful but does not mention output format, assumptions about timezone, or how it handles incomplete inputs. The description adds value beyond the name but leaves behavioral details to the output 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?

The description is extremely concise: two sentences with no redundant words. It front-loads the core purpose and then immediately clarifies the non-rectification exclusion. Every sentence earns its place, and the structure is optimal for quick comprehension.

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 tool has 8 parameters and an output schema, yet the description is minimal. It doesn't explain how to construct the input (e.g., time format), what the output contains beyond vague references to lagnas and indeterminacy, or any prerequisites (e.g., whether place is required for correct lagna calculation). Given the complexity and the lack of parameter guidance, the description is insufficient for an agent to call the tool correctly without additional inference.

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 compensate. It mentions the concept of a time window but does not explicitly explain any parameters, including the required time_from and time_to. Optional parameters like ayanamsa, place, geonameid, chart_id, and lang are not addressed at all. The description provides no additional meaning beyond the schema's basic types, leaving the agent to infer parameter semantics.

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 the tool's purpose: given a birth time window, it determines what is constant across the window, which lagnas are possible and when, and what is indeterminate. It also explicitly distinguishes itself from rectification by saying 'do not choose one lagna for a person,' which separates it from sibling tools like rectification-related ones.

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 provides clear usage context: use when birth time is known as a window (e.g., 'between 13 and 16'). It gives an explicit exclusion ('Not rectification') and a directive to not pick a single lagna, which tells the agent when not to use this tool. However, it doesn't name alternative tools or elaborate on when to prefer this over other astrological tools, leaving some inference required.

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