AstroTune — Vedic astrology (Jyotish)

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

With no annotations, the description carries the behavioral burden. It clearly discloses that no interpretation is provided ('ТОЛКОВАНИЯ ЗДЕСЬ НЕТ'), that the agent must make conclusions from the data, and that free-text questions are rejected. This is strong transparency for a read-only calculation tool, though it omits any mention of error handling or prerequisites such as chart availability.

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 and front-loaded: purpose and topic list first, then the output contents, then behavioral warnings. Each sentence carries distinct value and nothing is redundant. The opening phrase is slightly awkward but not bloated.

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 that an output schema exists, the description does not need to explain return values in detail; it covers the critical behavioral context and the main invocation constraint. It is sufficiently complete for an agent to call the tool correctly, though explicit selection criteria relative to sibling tools would improve it further.

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?

The description adds meaningful semantics to the topic parameter: it names the five valid topics and explicitly instructs that the agent must name the topic and cannot submit free text. However, schema coverage is 0%, and the description does not compensate for the remaining parameters (date, time, place, chart_id, geonameid, lang, ayanamsa), leaving much of their meaning to be inferred from the schema's enums and defaults.

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 states a concrete action ('Отдаёт') and enumerates exactly what is returned: houses, signs, rulers, planets, varga, and current period. It also pins down the allowed topic set. However, it does not explicitly differentiate this tool from sibling tools like natal_chart or dasha_timeline, so it stops short of a 5.

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 phrase 'одним вызовом вместо пяти' implies this tool is an aggregate for a set of related astrological lookups, and the warning instructs the agent to supply the topic rather than free text. There is no explicit statement of when to prefer this tool over alternatives or which sibling tools it replaces, so usage guidance remains largely implicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the tool's non-rectification behavior, the output categories (stable items, possible lagnas, indeterminate items), and the constraint on the window size. It does not mention whether the tool requires a place/date or what happens if the window crosses midnight, but the core behavioral traits are well covered.

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, front-loaded with the core concept, and every sentence adds value. It uses a clear example, a warning, and a constraint without redundancy. The structure is easy to scan and the key message (not rectification) is emphasized.

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 an output schema (not shown here) and 8 parameters, but the description covers the essential usage context: what the tool returns, what it does not do, and the window constraint. It does not explain the meaning of all parameters, but the output schema likely covers return values. The description is complete enough for an agent to decide when to call it and what to expect, though a bit more detail on required inputs (date/place) would make it fully complete.

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 explains the meaning of the time window (time_from and time_to) and the output semantics, but it does not explain the roles of date, place, geonameid, chart_id, lang, or ayanamsa. However, the description's focus on the window concept and the explicit 'between 13 and 16' example helps clarify the two required parameters. The other parameters are standard for astrological tools and their names are self-explanatory, but the description does not add detail beyond the schema.

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 determinable (stable Moon sign, nakshatra, pada, current period) and what is not, and lists possible lagnas with time boundaries. It explicitly distinguishes itself from rectification, which is a strong differentiator.

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 explicitly says when to use this tool (when birth time is known as a window) and what not to do (do not pick one lagna for the user, do not treat it as rectification). It also specifies the window constraint (up to six hours within the same day), which is a clear usage boundary.

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

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

With no annotations, the description carries the full burden and discloses non-obvious behavior: the retrograde section ignores the bodies parameter, uses its own ~1-year horizon, returns horizon as a separate field not comparable with window, and fast-body windows are shortened. It stops short of describing full request/response behavior but covers the important traps.

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 text is long but information-dense; each warning (fast bodies, retrograde independence, horizon) earns its place, and the lead sentence states the core purpose first. Some redundancy exists in the slow-body explanation, but the structure with sections and warnings is readable.

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 definition is complete about its most surprising behavior and the bodies parameter, and the output schema covers return values. But with no annotations and several unexplained input parameters (chart_id, geonameid, place, years, date), an agent cannot confidently construct a non-default request from the description alone.

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 the parameters. It thoroughly explains the bodies enum and default, and touches on time (birth time optional), but date, lang, years, place, chart_id, and geonameid are left unexplained. Since most parameters are not covered, the description does not compensate for the missing schema descriptions.

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 opening sentence defines the tool's exact function: chart transits, current planetary positions ('где стоят грахи сейчас') and sign-change timing. It goes beyond a noun phrase by specifying the resource (chart transits), the action (report positions/sign changes/retrogrades), and the default body set, so an agent can distinguish it from sky_now or natal_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 substantial parameter-level usage guidance: default slow planets, short window for the Moon, retrograde section's own body set and horizon, and the birth-time caveat. However, it never names when to prefer this tool over sibling tools such as sky_now or dasha_timeline, so tool-selection guidance is only implied.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains that the tool shows discrepancies and emphasizes that different ayanamsas are both correct, which is helpful. However, it does not disclose whether the operation is read-only, any side effects, or the nature of the output beyond showing differences. It is adequate but not comprehensive.

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 well-structured and front-loads the purpose. It is a bit verbose with the star and the final sentence about telling the person, but each sentence adds context. It is concise enough and effectively communicates the key concept without unnecessary fluff.

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 the tool's complexity (7 parameters, no schema coverage) and the existence of an output schema, the description is incomplete. It thoroughly explains the conceptual purpose but omits practical details on how to construct the call (e.g., which parameters are required, how to specify the chart, or how to select ayanamsas). The agent would likely need to inspect the schema for guidance, which is not ideal.

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?

The schema has 0% description coverage and 7 parameters, yet the description only hints at the 'ayanamsas' parameter ('several ayanamsas'). It does not explain how to specify the chart (date, time, place, chart_id, geonameid) or how the ayanamsas list is used. The description fails to compensate for the lack of parameter documentation, leaving the agent to guess.

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 function: comparing the same chart across multiple ayanamsas to show where differences change signs or nakshatras versus fractional degrees. It uses a specific verb ('shows') and resource ('the same map') and explains the exact use case, making it highly distinguishable from sibling tools without needing to compare schemas.

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 provides a clear scenario for use: answering why another site shows a different lagna or Moon sign. It implicitly tells the agent when to invoke this tool. However, it does not explicitly mention exclusions or name alternative tools, but the context is strong enough for an agent to infer the appropriate situation.

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

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

With no annotations provided, the description fully discloses critical behavior: the score is returned as a range (min…max) rather than a single number, the reason (ambiguous Moon sign without birth time), the count of uncalculated points, and a clear prohibition on deriving a percentage. It also describes the response structure by kutas. This is exemplary for a tool with zero annotation support.

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 dense but well-organized, with emojis and clear sections for range behavior and percentage prohibition. The purpose is front-loaded, and each sentence contains essential information. Slightly long, but no wasteful filler.

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 the tool's 9 parameters, no annotations, and no schema descriptions, the description covers the critical aspects: output structure, range behavior, and the prohibition on deriving percentages. It does not address error handling or explicit prerequisites for each parameter, but the required fields are indicated in the schema. Overall, it is sufficiently complete for correct invocation.

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 does add meaning to time parameters by explaining that missing birth time causes a range output. However, it does not explain date formats, the use of place/geonameid, or the lang parameter, leaving several parameters to be inferred from their names. Partial compensation only.

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 starts with 'Сравнение двух карт по восьми кутам (kundli matching, аштакута)', which names a specific verb, resource, and scope. It clearly distinguishes the tool from single-chart tools like natal_chart and transit tools by specifying the eight-kuta matching domain.

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 implies use for kundli matching and tells the agent how to answer 'why this many' with the breakdown, but it never explicitly states when to use this tool over alternatives like compare_methods or natal_chart, nor provides exclusion criteria. Usage context is implied rather than direct.

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

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

With no annotations provided, the description fully carries the behavioral burden. It discloses that the tool counts pre-collected positions rather than calculating charts, that it returns two numbers (matching and indeterminable), and warns that omitting the indeterminable count can understate results by half for the Moon. This goes beyond basic safety and surfaces a critical edge case.

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 and front-loaded: purpose first, then clarifying distinction, then parameter enumerations, then a highlighted warning. Every sentence carries meaningful guidance, and the warning about the Moon is placed exactly where it matters.

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 an output schema exists and the tool is moderately complex, the description covers the core behavior, the non-calculation distinction, parameter constraints, and the key edge case. Minor gaps remain: it does not mention the English graha aliases or clarify the lang default, but these are partially recoverable from the schema.

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 defines the graha list and the znak range (0–11 with 0 = Aries). However, it omits the English synonyms present in the schema (sun, moon, etc.), potentially confusing an agent into thinking only the Sanskrit forms are valid, and it does not explain the lang parameter beyond what the schema already provides.

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 states exactly what the tool does: count people in the 76k-person corpus with a given graha in a given sign and list known ones. It also explicitly distinguishes itself from chart calculation ('это НЕ расчёт карты'), which separates it from sibling tools like natal_chart and chart_transits.

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 gives an explicit when-not-to-use signal: this is not chart calculation, but counting from collected positions. It also warns about the Moon ambiguity and clarifies that both matching and indeterminable counts must be reported, guiding correct usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the series is built from the Moon's longitude, warns that a date-only query would change the result, describes the ~100 KB payload when full=true at depth=3, and clarifies that from/to returns intersecting periods including an earlier-started mahadasha.

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 dense but every sentence earns its place: purpose, depth capability, birth-time prerequisite, range semantics, full=true warning, and sibling routing. It is front-loaded with the immediate use case and structured with clear visual markers for constraints.

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 10 parameters, no annotations, and an output schema present, this description is remarkably complete. It covers the main call patterns, the key caveat about birth time, the payload-size warning, and the distinction from a sibling tool. An agent can decide when to use it and how to invoke it correctly without needing additional documentation.

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?

The schema has 0% description coverage, but the description adds real meaning to key parameters: depth (1, 2, or 3 with no separate sub-tools), full (whole cycle vs. segment), and from/to (window-based period lookup). It also indicates the time-of-birth dependency behind date/time. Some parameters such as chart_id, geonameid, and place are not explicitly explained, but the core ambiguous ones 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 states a specific purpose: Vimshottari life periods, current period and what comes next, in a single call. It also distinguishes itself from sibling tools by explicitly noting there are no separate tools for mahadasha/antardasha/pratyantardasha and by routing event-date queries to life_events.

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 explicit when-to-use and when-not-to-use guidance: use range parameters for historical periods, use full=true only when the entire 120-year series is genuinely needed, and use life_events instead when the user provides their own event dates. It also states the hard requirement of a known birth time.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses that duplicate reports do not create a new record but increment a counter, and that frequency is treated as importance. It also warns that a human will read the report and vague wording is unhelpful. This goes beyond typical side-effect disclosure, though it does not mention persistence details or response behavior.

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 front-loaded with the core purpose, then gives triggers, content guidance, and duplicate-handling behavior in a logical order. Every sentence contributes necessary information without redundancy or fluff.

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 simple feedback tool with an output schema present, the description covers purpose, usage triggers, content expectations, and idempotency-like duplicate behavior. The main gap is that it does not address the required 'title' parameter absence in the schema, which could confuse an agent trying to construct a valid call, but this is a schema-level inconsistency rather than a major description omission.

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 75%, so the schema already explains body, meta, and tool. The description adds practical guidance on what to put in those fields: tool name, call arguments, expected result, actual result, and refusal text. It does not clarify the kind enum or the required-but-undefined title parameter, but it still adds useful semantics beyond the schema.

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 by stating exactly what the tool is for: feedback about the server itself, not about calculations. It then lists concrete trigger conditions (tool behaved unlike its description, missing parameter/field, unexplained refusal, unclear description), which makes the purpose unmistakable and distinguishes it from the calculation-oriented siblings.

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 explicit when-to-use scenarios and an explicit exclusion ('not about calculations'), so an agent can decide to call this tool instead of a calculation tool. It does not name feedback_list or other alternatives, but the trigger conditions are specific enough that the missing alternative mention is a minor gap.

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

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

No annotations are present, so the description carries the behavioral burden. It discloses that the tool returns both user comments and human replies, and that the default view shows 'живые' (open) items. It does not explicitly say 'read-only', but the wording clearly implies a non-mutating listing operation.

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 compact sentences deliver purpose, usage guidance, and default behavior with no filler. The capitalized directive 'ЗОВИТЕ ПЕРЕД feedback_add' effectively highlights the most important operational instruction.

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 list tool with six optional parameters and an output schema, the description covers the purpose, when to call it relative to feedback_add, and the default filtering behavior. Parameter details are covered by the schema, and the output schema removes the need to describe return values, so nothing essential is 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?

The schema already documents q, kind, tool, and status with descriptions, show with an enum, and limit with constraints, giving 67% schema description coverage. The description only adds the natural-language default 'живые' (open), which mirrors the schema default for show; it does not meaningfully explain parameters beyond the schema.

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 states the tool's resource (feedback about this server) and the kind of information it returns (what was reported and its current state). It also distinguishes itself from feedback_add, but it lacks a crisp imperative verb like 'list', relying instead on a noun phrase and the later directive 'ЗОВИТЕ ПЕРЕД feedback_add'.

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?

Explicitly tells the agent when to call this tool: before feedback_add, when unsure whether something has already been reported. It names the sibling alternative and explains what the agent will gain (seeing other people's remarks and human responses), leaving no doubt about the intended workflow.

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

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

With no annotations provided, the description must disclose behavioral traits. It does reveal important behavior: searches in any language with normalization (Koln → Köln, Ленинград → Санкт-Петербург) and explains why the date is needed (UTC offset varies by year). However, it does not mention potential side effects, error handling, or return format beyond geonameid. This is partial disclosure, not comprehensive.

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, consisting of two sentences. It front-loads the primary purpose (returns geonameid) and then provides essential context about language and date. Every sentence adds value, with no filler. It is well-structured for quick consumption.

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 an output schema, so return values are covered externally. However, the description still leaves gaps: it does not explain the 'limit' parameter, error behavior, or how the geonameid is used in calculations. For a search tool with a required query and several optional parameters, the description is moderately complete but not fully self-sufficient.

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 explains the purpose of 'date' (UTC offset variation) and implicitly clarifies 'query' (place name) through examples, but it does not explain 'lang' (though the language normalization example hints at it) or 'limit' at all. Given zero schema coverage, this is insufficient for an agent to fully understand all parameters.

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 function: find a place by name and return a geonameid, which is needed for calculations. It also gives concrete examples of language normalization. This is specific and unambiguous, distinguishing it from any sibling tools that focus on astrological calculations rather than place lookup.

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 explains when to use the tool (to obtain a geonameid for calculations) and provides context on why the date parameter matters. It does not mention alternatives or exclusions, but since no sibling tool performs place lookup, this is acceptable. It clearly implies it is the tool for this purpose.

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

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

No annotations were provided, so the description carries the full burden of behavioral disclosure, and it delivers richly: 'NOTHING IS SAVED: events come in the request and go with the response, not a line remains on the server'; 'NOTHING IS INTERPRETED: the coincidence of a period with an event doesn't prove a connection — a period lasts for years'; plus partial-month handling behavior ('If the period changed within a month, both will come and the transition moment') and the birth-time prerequisite. This exceeds what annotations would typically convey.

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 longer than average, but every sentence earns its place: trigger, core behavior, date flexibility, sibling differentiation, data-handling guarantee, interpretation warning, and prerequisite. It is front-loaded with the trigger condition and uses emoji and all-caps markers to structure the key warnings. It is verbose in places (the repeated ⛔ blocks could be tightened) but never padded with filler.

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 the tool's complexity (8 parameters, 13% schema coverage) and that an output schema exists, the description covers nearly everything an agent needs: when to call, what it returns (dasha pairs per date, with transition moments), what it does NOT do (save, interpret), and the birth-time prerequisite. The only gap is the undocumented ancillary parameters, which are likely shared tool-family conventions rather than life_events-specific knowledge.

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 13%, so the description must compensate, and it does for the core parameter: it precisely explains the events.date format ('February 2018 is written as 2018-02, year as 2018') and the batch nature of events ('one call for all events at once'). However, it leaves the ancillary parameters (lang, time, place, ayanamsa, chart_id, geonameid, date) undocumented in the description; these are likely shared conventions across the astro tool family, but with such low coverage the description still leaves those semantics to inference.

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 states a precise verb+resource+scope: 'CALL WHEN A PERSON NAMES THEIR DATES... it answers which mahadasha and antardasha were active then — one call for all events at once.' It is unambiguous about the resource (life events mapped to dasha periods) and explicitly distinguishes itself from the sibling dasha_timeline by naming it and explaining the difference. An agent cannot confuse this tool's purpose with any of the 17 siblings.

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 an explicit trigger condition ('CALL WHEN A PERSON NAMES THEIR DATES') and an explicit exclusion with the named alternative: 'Don't confuse with dasha_timeline: that returns the WHOLE series of periods, and you would have to match it with the person's dates yourself; here the matching is already done.' It also states a hard prerequisite: 'Requires a known birth time: without it, the dasha series doesn't exist.' Usage routing is fully specified.

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

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

With no annotations, the description carries the full burden. It discloses the output structure (per-day suitability with rule, plus auspicious hours/choghadiyas and Abhijit muhurta) and warns against misrepresentation. However, it does not address parameter-related behavior (e.g., what happens if date_from/date_to are null, or how city/geonameid are resolved) or error handling, leaving gaps.

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?

Purpose is front-loaded with a clear example, and the output format is described efficiently. The warnings about general vs. specific muhurta and the 31-day limit earn their place, though the caution against misuse could be trimmed. Each sentence contributes.

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?

An output schema exists, so return values are likely documented, and the description covers the main use case and constraints. However, with five parameters and zero schema description coverage, the agent is left uncertain about how to set city/geonameid/lang and whether a date range is required. The description should state which location field to use and that a date range is effectively needed for meaningful results.

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 clarifies that date_from/date_to define the interval and imposes the 31-day maximum, which adds value. But it does not explain city, geonameid, or lang at all, nor state that a date range is effectively required despite the schema defaults. The compensation is only partial.

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 specifies the tool's action: finding favorable time windows (muhurta) over a given date range, with a concrete example ('find good dates from October 1 to 20'). It explicitly distinguishes itself from specific-event muhurta (wedding, housewarming, purchase), which separates it from sibling tools and clarifies scope.

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 gives clear when-not-to-use guidance: this is only a general selection, not for specific events, and instructs the agent to tell users this directly. It also sets the usage boundary of a 31-day maximum interval, beyond which the question becomes month selection. It does not name alternative sibling tools, but the exclusions are explicit and actionable.

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

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.

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

With no annotations, the description must carry the behavioral burden. It discloses the default date behavior, location requirements, and the detailed/choghadiya toggle, which is helpful. Yet it does not mention error cases, timezone handling, or what happens when conflicting location parameters are supplied, so transparency is partial.

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 dense and well-structured: it opens with the core calculation, then lists additional outputs and parameter guidance. Every sentence adds value, with no filler or redundancy.

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 presence of an output schema reduces the need to describe return values, and the description covers main usage. Still, key invocation details are missing (date format, lang, podrobno), and with no annotations the description must do more to be fully complete. It is adequate but has clear gaps.

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 is essential. It explains city, geonameid (from find_place), date default, and detailed (choghadiya). However, it does not explain the meaning/format of the date string, the 'lang' parameter, or the 'podrobno' parameter, leaving important semantic gaps.

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 names the tool's purpose: calculating Panchanga (tithi, nakshatra, yoga, karana, vara) with change moments, plus sunrise, sunset, and Rahu/Gulika/Yamaganda periods. It distinguishes itself from siblings like muhurta_search by describing a specific, concrete resource and output.

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 practical guidance on location (city or geonameid from find_place) and defaults (no date → today). However, it does not explicitly compare this tool to alternatives like muhurta_search, so the 'when vs alternatives' aspect is only implied rather than stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that the server returns proportions, percentage-point difference, and interval, but does NOT determine significance – the user must. It also discloses that houses are never computed and warns about corpus bias toward public biographies. This is thorough and prevents misinterpretation.

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 a single paragraph with a clear logical flow: purpose, example, then three warnings/constraints. Each sentence adds essential information, and the core purpose is front-loaded. It is slightly dense but not verbose; every sentence earns its place.

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 the tool's complexity (statistical comparison), absence of annotations, and presence of an output schema (which likely describes return format), the description covers the critical aspects: what it does, what it doesn't do, how to interpret results (significance is user's decision), and data limitations. It does not describe pagination or exact response structure, but the output schema presumably handles that, so the description is sufficiently complete for an agent to decide and invoke correctly.

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?

The description explains the semantic role of the key parameters: graha and znak together define the feature, occupation_qid defines the group. It also clarifies that lang has a default. Since schema description coverage is only 40% (only occupation and occupation_qid have descriptions), the description compensates by explaining how the core parameters interact, though it does not detail enum meanings (e.g., zodiac sign ranges) – but those are in the schema enums, so the added value is meaningful but not exhaustive.

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: comparing the proportion of a feature (graha+sign) in a defined group (occupation_qid) against the whole corpus, with a concrete example ('Jupiter in Sagittarius among entrepreneurs'). It is specific about the verb (compare), the resource (group vs corpus), and the scope, and distinguishes itself from generic search tools like corpus_search by focusing on statistical comparison.

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: it is used when you want to compare a feature's prevalence in a group vs the corpus. It explicitly states what it does NOT do (houses are never calculated, because birth time is mostly absent), which helps avoid misuse. However, it does not explicitly name alternative sibling tools or provide 'when not to use' conditions, so it falls slightly short of a 5.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It explicitly states that the response includes the calculation moment and warns that without it, a stale snapshot is indistinguishable from the current one. This is a useful behavioral nuance. It does not mention read-only nature, but that is evident from the purpose.

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 two sentences long, front-loads the core purpose, and includes a meaningful caveat in the second sentence. No filler or redundant wording. Every sentence earns its place.

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 tool with one optional parameter and an output schema, the description is mostly complete. It highlights the critical timestamp nuance that an agent needs to understand the output. The lang parameter is fully covered by the schema, so its absence from the description is acceptable. No significant missing context for an agent to invoke the tool correctly.

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?

With schema description coverage at 0%, the description should compensate for the undocumented parameters, but it makes no mention of the 'lang' parameter at all. The schema already provides an enum and default, so the parameter is not confusing, yet the description adds zero meaning about how language affects the response or which values are accepted. Thus it fails to compensate for the low coverage.

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 a specific purpose: showing current positions of planets in signs and the current Moon nakshatra in this minute. The phrase 'в эту минуту' conveys real-time scope, which helps distinguish it from other astrological chart tools. However, it does not explicitly differentiate from siblings like panchanga that may also provide nakshatra, so it falls short of a 5.

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 implies usage for current sky queries and emphasizes that the calculation timestamp is included, but it gives no explicit when-to-use or when-not-to-use guidance or alternative tool references. The 'this minute' framing is a clear contextual hint, but without exclusions or sibling comparisons, it stays at an implied level.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the mandatory birth-time requirement, the reason for it, exactly what the tool returns, and the not_available response behavior for unsupported vargas. This gives an agent a concrete model of the tool's behavior.

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, front-loads the purpose, and uses typographic emphasis (caps, emoji) for important constraints. It is slightly longer than a minimal statement, but the added sentences about the varga parameter and not_available behavior earn their place in an annotation-free definition.

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 8 parameters, no annotations, and no schema descriptions, the description covers the critical decision points: supported vargas, required birth time, returned values, and unsupported divisions. The existence of an output schema and self-explanatory parameter names covers most of the remainder, though exact input formats are not stated.

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 adds real meaning for varga (selection among supported divisional charts) and highlights the birth-time dependency, but leaves date, place, geonameid, chart_id, and ayanamsa semantics to be inferred from names/enums rather than explained.

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 names the exact resource (varga/fractional chart), enumerates the supported divisions (D2, D3, D7, D9, D10, D12), and states the one-tool-per-varga design plus the returned contents (varga lagna, planetary placements, vargottama list). This makes it easy to distinguish from natal_chart and other astrological siblings.

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 gives clear preconditions: known birth time is mandatory because the varga lagna cannot be derived without it, and unsupported divisional charts should not be computed manually but reported via not_available. It does not explicitly name sibling alternatives (e.g., natal_chart or what_we_calculate), so it falls short of full alternative routing.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the numeric input convention for signs and nakshatras, explains that the response is a reason rather than a judgment, and warns that an unresolved case is reported as 'unexplained' without retrofitting. This is meaningful transparency, though it does not discuss side effects, required parameter combinations, or error handling in depth.

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 somewhat long but well structured: it opens with the core purpose, then gives parameter conventions, and closes with limitations and fallback behavior. The emojis and disclaimers add useful emphasis rather than pure filler, though a few ideas are restated.

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 description covers purpose, numeric input conventions, checked factors, and fallback behavior, which is fairly complete for a niche verification tool. Yet given the tool has 10 parameters, no annotations, and no in-schema descriptions, the absence of guidance on how parameters combine (e.g., chart_id versus date/time/place, geonameid usage) is a notable completeness gap.

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 usefully explains that signs and nakshatras are passed as numbers (0–11 and 1–27), and it relates ayanamsa and time calculations to the verification logic. However, several parameters such as chart_id, geonameid, lang, date, time, and place receive no explicit semantic explanation, leaving gaps for an agent to infer.

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 identifies the tool's function: it explains why an externally provided chart does not match the calculated chart and returns the reason for the discrepancy. It specifies what is checked (reference school and time handling) and explicitly distinguishes itself from a verdict tool, but it does not directly name or contrast sibling tools.

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 usage context: use it when someone supplies foreign chart numbers and wants to understand why they differ. It also states exclusions — it does not decide who is right, and it does not force an explanation when no cause is found. However, it does not explicitly describe alternatives among sibling tools.

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

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

With no annotations, the description carries the full burden. It discloses that the tool directly names missing capabilities and that self-calcification produces false numbers. This adds meaningful behavioral context beyond the bare function, though it does not specify output format or side effects.

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 two sentences with no filler. The primary purpose is front-loaded in the first clause, and the usage warning is directly attached. Every word earns its place.

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?

This is a simple no-parameter informational tool. The description tells the agent exactly when to invoke it and what to expect in terms of content. An output schema exists, so return-value details are not required. Nothing critical is missing for correct invocation.

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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed; the schema is empty and fully covers the inputs.

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: it reports what the server calculates and what it does not. It distinguishes itself from the astrological sibling tools by being a meta-capability reference, and the phrase 'what it does NOT calculate' adds specificity beyond the name.

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 instructs the agent to consult this tool before promising a method to a user. It also warns that missing capabilities must not be invented, providing clear when-to-use and when-not-to-act guidance without needing to name alternatives.

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