Birthstar Vedic Astrology MCP

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

With no annotations, the description provides the behavioral profile: it is a pure compute that returns specific values and is a one-shot shortcut that does not cache. It could go further by stating it makes no persistent changes or by listing error conditions, but it covers the main statefulness concern by directing stateful needs to create_chart.

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 tightly organized: a scoped purpose statement, two-sentence usage guidance, a bulleted Args list, and a Returns list. No sentence is redundant; every line 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?

With no annotations and no output schema, the description carries the full burden and succeeds: it defines all inputs, enumerates six explicit return fields, and names the alternative tool for stateful follow-ups. Minor omissions like ayanamsha options are mitigated by the stated default.

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%, yet the description documents every parameter with formats, examples, and units: dob, tob, tz, lat/lon sign conventions, and ayanamsha default. This exceeds the minimal schema by a wide margin.

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?

Sentence 1 names the verb, resource, and scope: 'Compute just a person's Vedic birth star (nakshatra) and core anchors.' It also distinguishes itself from the sibling create_chart by explicitly labeling itself a one-shot shortcut.

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?

Gives explicit when-to-use: 'use this when the birth star is the whole question,' and when-not-to: 'If you expect follow-up questions about the same person's chart, prefer create_chart, which caches the full chart behind a reusable handle.' This clearly routes an agent between siblings.

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?

There are no annotations, so the description carries the behavioral burden. It discloses caching, the decision to return only a chart_id plus headline placements rather than the full document, and the important tz-local default behavior of transit_date. It could additionally mention failure modes or whether repeated calls with identical inputs reuse the cache, but the key behavioral traits are 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 long but the length is justified by nine parameters with no schema descriptions. It is well-structured: two opening sentences establish purpose and usage, followed by a compact, scannable Arg list. Every line adds necessary information.

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 no output schema and no annotations, the description provides what an agent needs: what the tool does, how to invoke it with all parameters, what it returns, and how to proceed with sibling tools. It is complete for its role as the chart-creation entry point.

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%, and the description fully compensates by explaining every parameter: date/time formats, timezone/local-time semantics, coordinate conventions, allowed ayanamsha values, house system values, node_type values, and the meaning of transit_date. This goes far beyond the schema's bare property names 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 specific operation: compute a full Vedic natal chart, cache it, and return a short handle. It clearly distinguishes itself from the sibling getter tools by explicitly positioning itself as the first call that produces the chart_id they need.

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 usage guidance: 'Call this FIRST' and then pass the returned chart_id to get_grahas, get_houses, get_current_dasha, get_panchanga, and get_yogas. This unambiguously tells an agent when to use this tool versus its siblings.

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 disclosure burden and does well: it reveals exactly what gets returned (birth data, config, top-level sections, deferred/uncomputable field counts), and the phrase 'honestly marked as deferred or uncomputable' discloses that the engine may be unable to compute some fields — useful behavioral honesty. It implies the chart must already exist since it operates on a 'cached' chart. Error behavior is not covered, but the core traits are transparent.

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 sentences with zero waste. The core purpose is front-loaded in the first sentence, and the second sentence earns its place by adding usage context and return-value detail. Every clause 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?

For a simple one-parameter tool with no output schema and no annotations, the description is reasonably complete: it summarizes the return value constituents and the cached-chart prerequisite. Minor gaps are the absence of error behavior and an explicit safety statement, but nothing an agent needs to invoke it correctly is critically 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 compensate. It partially does by establishing that chart_id refers to a previously computed 'cached' chart, implying the ID must come from create_chart or similar. But it doesn't specify the ID format, how to obtain it, or what happens with invalid IDs, leaving the single parameter only partially 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 states a specific verb and resource: 'Get metadata and an inventory of what a cached chart contains.' The phrase 'cached chart' distinguishes it from sibling get_* tools that return computed chart slices, and 'orienting before drilling in' clarifies its role as an overview tool. It's clear, though 'metadata and an inventory' is slightly loose about the exact output shape.

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?

'Useful for orienting before drilling in' provides clear contextual guidance — this should be called first before querying specialized endpoints like get_houses or get_grahas. However, it doesn't explicitly name alternative siblings or state when NOT to use it, so it falls 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?

With no annotations, the description carries full disclosure burden and exceeds it: it clarifies that credits_remaining counts computations only, that reading existing charts is free, and that gated_tools is empty on paid plans. This gives the agent a precise mental model of the response semantics and side-effect-free nature.

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 with a first-sentence definition, a usage directive, and a field-semantics paragraph. The analogy is slightly elaborate but earns its place by reinforcing when to use the tool; no unnecessary 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 zero-parameter tool with no output schema and no annotations, the description provides everything an agent needs: what it does, when to call it, and the meaning of the key fields it returns. Nothing important 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?

There are zero parameters and the schema fully documents this with 100% coverage. The description adds no parameter details because none are needed; this is the baseline case for a parameterless tool.

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 clear, specific purpose: check the calling account's plan, remaining chart credits, and gated features. It distinguishes itself from generic health/server tools by focusing on account-level subscription state, and the describe_chart analogy clarifies its role as a lookup/index tool.

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 explicit timing guidance ('Call this BEFORE attempting a tool that might be refused, not after') and explains the planning-oriented use case. It does not name a concrete sibling alternative or specify when not to use it, but the context is clear enough for an agent to select it.

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 adds useful behavioral details: include_sodhana roughly triples the response and SAV total is always 337. Could mention return format, but the provided context is solid.

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?

Well-structured, front-loaded with meaning and use cases, then compact Args. Every sentence adds value.

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?

Strong overall: purpose, parameters, and performance impact are covered. The only gap is the exact return shape, which matters more because there is no output 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 description coverage is 0%, and the description fully compensates by explaining all three parameters: chart_id provenance, planet's per-planet scope, and include_sodhana's reduction effect and default.

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: 'Get Ashtakavarga bindus' — the per-sign point scores. The transit-strength use case differentiates it from sibling get_* 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?

Gives explicit call scenarios ('is this a good sign for Saturn to transit', 'which signs are strongest overall'). Does not name alternatives or exclusions, but the use cases make when-to-use clear.

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 well: it explains that graha and rasi drishti are separate systems, discloses that include_argala is off by default and 'roughly doubles the response,' and clarifies that planet restricts only graha drishti. This goes beyond the schema and gives useful behavioral warnings, though it does not describe response structure or error 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 concise and well-structured: a one-line summary, a short explanatory paragraph about the two systems, and a clean Args list. Every sentence contributes to understanding or usage, and the critical 'do not merge' warning is front-loaded in the explanation.

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 3 parameters, no output schema, and no annotations, the description provides a solid conceptual model plus parameter-level guidance. The main gap is that it never explicitly states that both graha and rasi drishti are returned together in the response, but the overall content is sufficient for an agent to call the tool correctly in most cases.

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?

Although schema description coverage is 0%, the description's Args section fully documents all three parameters. chart_id is tied to create_chart, planet is scoped to graha drishti, and include_argala includes its default and performance impact. This more than compensates 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 description opens with a specific verb and resource: 'Get planetary and sign aspects — who is looking at which house.' It clearly identifies the tool's domain as aspects and distinguishes between graha drishti and rasi drishti. However, it does not explicitly name or contrast sibling tools like get_grahas or get_houses, so it stops short of full sibling differentiation.

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 context on the two aspect systems and warns 'do not merge the two,' which is a direct usage instruction. It also explains when the planet parameter applies (only to graha drishti) and when include_argala is relevant. It does not mention alternative tools or explicit when-not-to-use scenarios, but the guidance given is substantive.

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 disclosure burden. It clearly states that two ladders are deliberately not computed and are reported as deferred rather than guessed, which is a meaningful non-obvious behavior. It doesn't cover error behavior or permissions, but the main limitation is well disclosed.

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: the main purpose is in the first sentence, technical terms are defined in the next, and the important caveat closes it. Every sentence adds value.

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 domain-specific tool with no output schema, the description defines the main avastha ladders and the deferred categories, so an agent can understand what the tool returns. It could be more complete by addressing the planets parameter, but the core selection and invocation context is present.

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% and the description does not explain chart_id or planets, nor how planets filters the output. The phrase 'each graha' weakly implies scope, but it doesn't compensate for undocumented 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 opens with a specific verb and resource ('Get planetary avasthas') and clarifies the concept as maturity, alertness, and mood states of each graha. It does not explicitly contrast against sibling tools such as get_grahas or get_strengths, so it falls short of full differentiation.

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 the tool is for retrieving computed avastha ladders and explicitly states that lajjitadi and sayanadi are not computed, which sets expectations. However, it never says when to choose this tool over an alternative or names a fallback for the deferred ladders.

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 details the exact components of the calculation — the 8 classical Kutas and the Kuja Dosha mutual cross-audit — and clarifies the Person 1/Person 2 association. It does not, however, mention the output format, error behavior, or any prerequisites beyond the two chart IDs, which is a minor gap.

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 dense, purposeful sentences. The main action and result are front-loaded, followed by a compact enumeration of the Kutas that adds valuable context without wasting words. No redundant phrasing or restatement of the schema.

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 no output schema, the description explains the computation well but omits any indication of the response structure — for example, whether it returns a total score, per-Kuta breakdown, or a verdict. An agent can call the tool correctly, but might not fully know what to expect in the result. Given the moderate complexity of Ashta-Kuta compatibility, a bit more return-value context would make this 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 coverage is 0%, so the description must compensate. It does add meaning by stating the calculation is between two charts and by mapping Person 1 and Person 2 to the two inputs. However, it does not clarify whether the IDs must be previously created charts, expected ID formats, or ordering semantics beyond the natural one, leaving some interpretation to the agent.

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 begins with a specific verb 'Calculate' and identifies a precise resource: '36-point Ashta-Kuta Guna Milan compatibility between two charts.' It then enumerates the exact Kutas and the additional Kuja Dosha audit, making the tool's purpose unmistakable and clearly distinct from sibling tools like get_doshas or describe_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 provides clear context for when to use this tool: whenever compatibility between two charts is needed. It does not explicitly state when not to use it or name alternatives, but the scope is sufficiently narrow and no other sibling tool addresses two-chart Vedic compatibility, so the usage context is effectively unambiguous.

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 full behavioral burden. It discloses the read-style nature, describes the returned nested lord chain and ISO dates, and exposes the non-obvious semantic that 'current' refers to the chart's baked transit date, not today's date at call time. This is meaningful context beyond the name and 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?

Three sentences, all functional: purpose, return shape, and a caveat. The main behavior is front-loaded, and the caveat is placed at the end where it will not obscure the primary description. No word 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?

With one parameter and no output schema, the description covers what is needed to call the tool correctly: the input identifier, the output structure, and the critical date semantics. It leaves error and empty-result cases unspecified, but for a simple getter on a cached chart this is not a major 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 coverage is 0%, so the description must compensate. It does so by tying chart_id to 'a cached chart,' clarifying that the identifier must refer to an already-computed chart rather than a raw chart request. The single parameter is otherwise self-explanatory from its name and title.

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 first sentence names a specific verb ('Get'), resource ('currently-running dasha periods'), and qualifier ('for a cached chart'), and the second sentence enumerates the returned nested levels and ISO dates. This clearly distinguishes it from siblings like get_dasha_periods, which would return the full dasha timeline rather than the active slice.

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 makes the intended use clear: call this when you need the current active lords at all nested dasha levels for an already-computed chart. The NOTE adds an important rider about the chart's baked-in transit date. It does not explicitly name sibling alternatives or give when-not-to-use guidance, so it stops 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?

With no annotations provided, the description carries the full transparency burden. It does well by disclosing the return shape ('Each period carries lord, ISO start/end, duration in years, and whether it is the one currently running') and the hierarchical traversal semantics, including a chara_jaimini quirk. It doesn't mention auth, rate limits, or explicit read-only status, but the operation is clearly a non-mutating list.

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 definition is well organized and front-loaded with purpose and usage, then a clear Args block. It is slightly longer than strictly necessary because the usage examples in the second paragraph partially repeat what the within parameter documentation later conveys, but every section still adds distinct value and nothing 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?

For a 3-parameter tool with no output schema, the description is fully complete: it covers all supported systems, defaults, the drill-down behavior, the special chara_jaimini case, and the exact fields carried by each period. An agent has everything needed to format a correct call and understand the result structure.

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 compensates exceptionally. It explains chart_id as a handle returned by create_chart, enumerates all valid system values with their default, and fully explains the within hierarchy with concrete examples for None, ['Sun'], and ['Sun', 'Mercury'], plus the special chara_jaimini rashi-keyed caveat. This is far more valuable than the raw schema alone.

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 and resource: 'Walk the dasha tree — list periods at any level, past or future.' It clearly distinguishes itself from get_current_dasha by explaining that the sibling only tells you what is running now while this tool gives the whole sequence. This fully separates it from siblings in a single glance.

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 concrete user questions: 'when does my next antardasha start', 'what runs after this mahadasha', 'when was I in Jupiter'. It explicitly names the alternative get_current_dasha and explains the boundary between the two tools, which is exactly the when-to-use vs when-not-to-use guidance an agent needs.

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 and does disclose the key behavior: it returns birth-day windows, day length, and a day/night indicator. The warning about not answering today's periods is useful behavioral context beyond a bare 'Get'. It does not mention output format or edge cases, but those are not critical for this simple read-style tool.

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?

Four short sentences front-load the purpose, then list the exact contents, then deliver the caveat. Every sentence adds information; the step-by-step progression is efficient and easy to parse.

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 one-parameter tool with no output schema, the description covers what the tool returns, the birth-day scope, and the common misuse case. It is slightly incomplete only in not describing the response shape or the source of chart_id, but these are minor against the explicit content listing.

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 never explicitly defines chart_id, but the phrase 'of the BIRTH day' and the DATE OF BIRTH warning imply chart_id identifies the chart whose birth day should be analyzed. This is adequate for a single obvious parameter, though explicit 'chart_id is the chart to use' would be stronger.

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 ('Get sunrise/sunset and the auspicious/inauspicious windows of the BIRTH day') and enumerates exactly which windows are returned (Rahu kala, Yamaganda, Gulika kala, Abhijit, Brahma muhurta). The repeated emphasis on 'BIRTH day' vs 'today' distinguishes it from time-oriented siblings like get_panchanga.

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?

Gives an explicit when-not: 'these are the windows for the DATE OF BIRTH, not for today.' It also states the alternative path: answering today's Rahu kala 'needs a chart created for today's date,' preventing an agent from misusing this tool for current-day queries.

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, and it uses that space to disclose the tool's scope and counting behavior: 8 classical cancellation exceptions, 12 Kaal Sarp variants, Gandanta junctions, and Pitre indicators. This tells an agent that results are rule-based evaluations, not just raw planetary positions. It does not disclose output format, pagination, or error behavior, but for a single-chart audit with one required parameter, the disclosed behavior is substantial and useful.

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?

Three sentences, each earning its place: the first states the main purpose, the second adds the evaluation anchors and rule counts, and the third lists the dosha categories. No filler, no repetition of the schema, and the most important information is front-loaded.

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 niche read-audit tool with one required parameter and no output schema, the description covers the core behavior well: what is evaluated, from which reference points, and how many rules. It lacks explicit mention of return shape or error cases, and it does not state prerequisites (e.g., chart must already exist). However, the description is sufficient for an agent to select and safely invoke the tool, which is the standard being evaluated.

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% and the schema only states 'Chart Id', so the description must compensate. It effectively does by explaining that chart_id refers to a Vedic chart whose Mars placements are evaluated from Lagna, Moon, and Venus. Although it does not spell out 'chart_id is required and identifies the chart to audit,' the evaluative context ('Mars placements from Lagna, Moon, and Venus') makes the parameter's role obvious. A single clearly named parameter with strong contextual grounding earns a top score.

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 leads with a strong verb ('Audit') plus the specific resource ('classical Vedic doshas') and enumerates the exact categories examined: Kuja Dosha (Manglik), Kaal Sarp, Gandanta, and Pitre. It also states the key reference points (Lagna, Moon, Venus) and counts of rules (8 cancellations, 12 Kaal Sarp variants), which makes the tool's purpose unmistakable and clearly distinguishes it from siblings like get_yogas or get_aspects.

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 when to use this tool: when the agent needs a comprehensive dosha audit rather than a general chart overview or a specific astrological factor (e.g., yogas, avasthas, aspects). It does not explicitly name alternatives or give an exclusion rule, but the detailed scope makes the use case clear. Because it never says 'use X instead for Y,' it stops 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?

With no annotations provided, the description carries the full behavioral burden and does so excellently. It explicitly explains that an empty conjunctions list is a 'provable negative, not a skipped check' and that planets_scanned and stars_scanned reveal the search scope. This prevents the agent from misinterpreting an empty result.

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 concise sentences with no filler. The core action is front-loaded, and the critical empty-result semantics are placed immediately after, making the structure highly efficient.

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 one-parameter tool with no output schema and no annotations, the description covers the key invocation concern: how to interpret the returned conjunctions and scanned fields. It falls slightly short only because chart_id semantics and explicit sibling distinctions are left to 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%, and the description does not mention chart_id at all. While the parameter name is conventional and the schema labels it as 'Chart Id', the description adds no semantic value about how the chart is referenced or what chart_id must satisfy.

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 uses a specific verb and resource: 'Get conjunctions between the grahas and named prominent fixed stars.' This clearly distinguishes the tool from siblings like get_aspects and get_grahas by naming the unique subject matter.

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?

Usage is implied: an agent would use this tool when fixed-star conjunctions are needed. However, the description does not explicitly state when to prefer this over alternatives such as get_aspects or get_grahas, nor does it provide exclusions or routing guidance.

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, and it does so well: it explains the default planet set, accepted outer bodies, the difference between basic and full detail, and the exact per-planet return fields. It does not explicitly state side-effect-free behavior or error conditions, but the get/cached framing plus the detailed return specification make the behavior largely transparent.

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 organized into Args and return-value sections, each sentence adds useful information, and there is no filler. The key scoping phrase is front-loaded, and the parameter details are concise but complete.

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?

There is no output schema, so the description fills that gap by listing the per-planet return fields. It also covers defaults, optional inputs, and all detail-mode extensions. For a three-parameter read-style tool, nothing essential is missing for an agent to call it 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?

Schema description coverage is 0%, so the description must compensate, and it fully does. chart_id is tied to create_chart, planets lists examples and accepted bodies plus the default, and detail explains both allowed values and what 'full' adds. This is richer than the raw schema alone.

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 and resource: 'Get planetary positions for a cached chart.' It distinguishes itself from siblings like get_houses and get_aspects by specifying the resource type (planetary positions) and the precondition (a cached chart). The scope is unambiguous.

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 context: this tool operates on a chart_id produced by create_chart, and it is the tool to call for planetary positions. It does not explicitly name alternatives or state when not to use it, but the 'cached chart' precondition and the parameter documentation make the intended usage clear.

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?

Annotations are absent, so the description carries the disclosure burden. It does disclose non-obvious behavior: the 'Always includes an analysis block' guarantee, the per-method differences in return content, and the fact that bhava_chalit can move a planet's house. It could mention error handling or caching side effects, but none exist for a read operation, and no annotation conflicts arise.

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 yet information-dense. It front-loads the purpose, then uses a tidy Args list and a short paragraph for the analysis block. Every sentence adds a useful detail, and none are redundant. It earns its length.

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 no output schema, the description does a strong job of explaining both the per-house output (by method) and the always-present analysis block. It doesn't detail the exact JSON field names or error conditions, but an agent has enough to invoke the tool correctly and interpret the major output. It could have explicitly stated that chart_id must reference an existing chart, but this is implied by 'cached chart.'

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 parameter descriptions are completely absent (0% coverage), but the description fully compensates. It defines chart_id explicitly as a handle from create_chart and explains each method value in detail: whole_sign returns sign, lord, lord placement, karaka, occupants; bhava_chalit uses Sripati/Porphyry cusps and can change house; kp_cusps uses Placidus cusps with sub-lords. This is more informative than a typical schema enum.

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 begins with a specific verb and resource: 'Get the 12 houses (bhavas) for a cached chart.' This clearly identifies the tool's main function and ties it to a prerequisite (a cached chart from create_chart). It doesn't explicitly name sibling tools, but the purpose is narrow enough to be distinguished from related tools like get_grahas or describe_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 clear context on when to use the tool: it operates on a cached chart and offers three explicit method choices. It explains what each method provides, including the edge case where bhava_chalit can assign a planet to a different house than whole-sign. However, it doesn't state when to prefer this tool over sibling tools, so no explicit 'when not to use' guidance is present.

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 and it delivers: it states the return ordering (whole ladder in descending degree order), the inclusion of natural karakas, and the important Rahu reverse-degree caveat affecting effective_degrees. It does not cover errors or auth, but for a read-only get tool this is solid disclosure.

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 tightly written: the first sentence states the core purpose, the second adds relevant Jaimini context, and the final note covers a critical edge case. Every sentence earns its place with no 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?

For a one-parameter astrological lookup with no output schema, the description covers the main return content, ordering, and the Rahu special case. It could explain Karakamsa/Swamsa or the expected chart_id format more, but what is present is enough for 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 input schema has only chart_id and schema description coverage is 0%, so the description needed to compensate, but it never mentions the parameter. The parameter name is self-explanatory, but the description adds no meaning beyond 'Chart Id' already present in 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 with a specific verb and resource: 'Get the Chara (Jaimini) karakas plus Karakamsa and Swamsa.' It clearly differentiates this from sibling planet/house tools by specifying the Jaimini significator focus and explicitly names the returned components.

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 context, explaining that the Atmakaraka is the single most-used significator in Jaimini analysis, which signals when an agent would want this tool. It does not name alternatives or exclusions, but no sibling tool directly competes with this karaka-specific function.

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 responsibility for behavioral disclosure. It does disclose one meaningful behavior: school-divergent special lagnas are reported under not_computed with a reason rather than guessed. However, it does not address authentication, rate limits, error cases, or mutability, though 'Get' strongly implies a read-only 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?

The description is tightly structured: a one-sentence summary followed by a scoped enumeration of contents and a brief note on edge-case behavior. Every sentence adds useful information, with 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?

Given the complexity of the returned data and the absence of an output schema, the description does a good job enumerating the lagna/angle categories and the special not_computed field. It falls slightly short of full completeness by not explicitly describing the response envelope or confirming that only read-only data is returned, but the coverage is strong overall.

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 only parameter is chart_id, and schema description coverage is 0%. The description never mentions chart_id or any expected format/value semantics. While chart_id is broadly self-explanatory and the schema provides type and required status, the description adds no param-level meaning and does not compensate for the coverage gap.

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 action and resource: 'Get the chart angles, special lagnas, Arudha padas and Bhrigu Bindu.' It then enumerates the exact constituents (MC/IC/Descendant/Vertex, Bhava/Hora/Ghati/Sree/Indu, AL/A2-A12/Upapada), which makes the tool's scope unambiguous and distinct from sibling chart-data 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?

No guidance is given about when to choose this tool over alternatives such as get_houses, get_grahas, or get_timeline. The description states what the tool returns but does not mention use cases, prerequisites, or sibling tools. Usage context is only implicit from the tool's name and content.

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 present, the description carries the full burden, and it does so thoroughly. It discloses that the methods are textually divergent, reduction rules are only partially applied, and the disclaimer must be propagated to the reader—important behavioral context beyond the simple 'get' verb.

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 most critical warning ('EXPERIMENTAL, not for predictive use'), and each sentence adds meaningful information. The structure moves from purpose to limitations to a hard usage rule without 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?

For a single-parameter tool with no output schema, the description covers the key behavior, return contents (Pindayu, Nisargayu, disclaimer), and cautions. It could be slightly more complete by describing the expected return shape or chart_id provenance, but overall it gives enough context 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%, and the description does not mention chart_id at all. The only clue is the parameter name itself, which is reasonably self-explanatory, but the description fails to compensate for the missing schema documentation by explaining how to obtain or use chart_id.

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 verb-resource pair: 'Get Ayurdaya (longevity) estimates.' It further clarifies the two computed values (Pindayu and Nisargayu) and immediately flags the experimental nature, making it easy to distinguish from the many sibling get_* 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: this tool returns experimental longevity estimates and must not be used or presented as a predictive lifespan. It does not name an alternative sibling, but it provides strong exclusionary guidance ('Do not present these as a lifespan prediction') and instructs the caller to pass on the disclaimer.

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 behavioral transparency burden. It discloses what is calculated and lists the major result categories, but it does not mention input constraints, expected date format, or behavior when 'dob' is omitted. For a deterministic calculation tool this is acceptable but not deeply transparent.

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 short, front-loaded with the primary action, and every sentence adds useful information about what the tool computes. There is 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?

Given the tool's low complexity and the absence of an output schema, the description provides a solid list of computed values so an agent can anticipate the result. It is slightly incomplete because it omits operational details like accepted date formats and defaults, but it still covers the core contract well.

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 indirectly maps 'name' to Name Number and 'dob' to Birth/Destiny Number, adding some semantic meaning. However, it never explicitly describes the 'dob' parameter format, its optionality, or what happens when it is left empty.

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 ('Calculate') and a specific resource ('Chaldean Name Numerology and Vedic Date of Birth numbers'), then enumerates the exact outputs such as Name Number, Birth Number, and Destiny Number. This makes the tool's purpose distinct from the many Vedic-astrology sibling tools that focus on charts, dashas, or houses.

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 clearly implies when to use the tool: whenever a user needs name numerology or Vedic date-of-birth numerology values. It does not explicitly exclude alternatives, but its unique domain is obvious alongside the astrology-focused siblings, providing clear context without needing exclusions.

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 behavioral disclosure burden. It does state that the tool 'Returns' a defined set of derived values, which communicates a read-only retrieval; but it does not mention prerequisites such as the chart having valid birth data, error behavior, or other caveats.

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 short sentences front-load the definition and then enumerate the returned data. There is no filler, repetition, or unnecessary detail.

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 return value is well specified even without an output schema, and the tool is simple. Still, for an unannotated tool, the description leaves usage guidance and parameter grounding to inference, so it is adequate but not comprehensive.

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 0% schema description coverage, the description ideally should explain that chart_id identifies the birth chart for which the panchanga is computed. It never mentions chart_id explicitly, but the single parameter's name is fairly self-explanatory and 'birth panchanga' implies that the tool operates on a chart.

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 pair ('Get the birth panchanga') and then enumerates the exact returned limbs: tithi, vara, nakshatra, yoga, and karana, plus lunar month and season. This makes it clearly distinct from sibling tools like calculate_birth_star or get_yogas, which cover only part of that data.

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 'birth panchanga' and 'at the moment of birth' imply the intended use: an agent needing the five Vedic calendar limbs for a chart. However, the description never explicitly says when to prefer this over siblings such as calculate_birth_star or get_yogas, nor does it state alternatives or exclusions.

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 it delivers: it explains category matching is case-insensitive, unrecognized categories produce an error listing valid names rather than a silent empty result, and include_full_templates defaults to False with a clear effect on output. It also describes the general return structure.

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, followed by concrete trigger examples, then parameter details, and finally return-value expectations. Every sentence adds useful information; there is 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?

Given there is no output schema and no annotations, the description is exceptionally complete: it states the output is a structured catalog with titles, descriptions, required arguments, and underlying tool chains. It also covers error behavior and defaults, so an agent has enough context to select and invoke the tool confidently.

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%, but the description fully compensates by enumerating the valid category values, explaining the default behavior, and defining exactly what include_full_templates does. An agent can populate both parameters correctly without any external documentation.

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 and resource: 'Fetch curated high-value prompt templates and multi-tool question workflows.' It also clearly distinguishes this tool from the sibling astrology data tools, as it targets user-facing question guidance rather than chart calculations.

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 states when to call the tool: when suggesting high-value questions, when the user asks 'what can you do?' or 'what should I ask?', and for guided astrology workflows such as Sade Sati analysis. This is strong practical guidance that an agent can act on immediately.

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 and delivers: it explains the ratio >= 1 interpretation, warns that plain rank (absolute total_rupa) frequently disagrees with rank_by_ratio, flags strongest/weakest as backward-compat keys, and notes that 'full' output is several times larger. It even discloses that Ishta/Kashta are derived from Shadbala rather than independent measurements, preventing a misreading of the data.

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 long but every sentence carries load-bearing information — the ranking pitfall, backward-compat keys, size warning, and derivation note each prevent a distinct misinference. It is front-loaded with purpose and trigger queries, and the Args section is cleanly separated and structured.

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 domain-heavy tool with no output schema and no annotations, the description covers everything needed to call and interpret it correctly: parameter sourcing, response contents (ratio, rank_by_ratio, meets_requirement, strongest_by_ratio/weakest_by_ratio), metric semantics, and size expectations. The key names are enumerated in prose, which is sufficient in the absence of an output 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 description coverage is 0%, so the description must compensate for both parameters, and it does: chart_id is defined by origin ('Handle returned by create_chart'), and detail enumerates its two values, their output contents, the size tradeoff, and a heuristic for choosing. Both parameters receive semantics the bare schema (type: string) completely lacks.

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 names a specific resource — 'Shadbala, Bhava Bala and Ishta/Kashta phala' — and the outcome ('how strong each planet and house is') with a specific verb (Get). Among the sibling tools (get_grahas, get_houses, get_ashtakavarga, get_vimsopaka), none measures planet/house strength via the Bala metrics, so the tool is unambiguously distinguishable.

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 trigger phrasing — "Call this for 'which planet is strongest', 'is Saturn strong enough', or 'which houses are weak'" — which maps user intent directly to this tool. It also instructs when to use 'full' detail ('ask for it only when the components matter'). It does not, however, name sibling tools as alternatives for when NOT to use this tool, so it stops short of full exclusion 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?

No annotations are present, so the description carries the full burden, and it delivers. It discloses that dates are exact and bisected against the ephemeris rather than sampled, that truncation is explicit with a resume date, that include_samples caps at 13 rows and shortens the event list, and that the response includes natal anchors and Sade Sati state. This goes well beyond minimal disclosure.

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?

Although long, the description is appropriately sized for a complex 7-parameter tool with no annotations or output schema. It front-loads the core concept and use cases, then moves logically through an Args section, return behavior, and truncation policy. Each sentence adds substantive information and no filler is present.

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 no output schema and no annotations, the description is remarkably complete. It explains what the tool returns, how dates are calculated, when to choose siblings, what every parameter does, and how edge cases like truncation and sample rows behave. An agent has enough context to invoke it correctly and interpret results confidently.

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 fully explain all 7 parameters, and it does. It defines chart_id as a handle from create_chart with independence from transit_date, specifies date inclusiveness and ordering, details systems behavior including antardasha handling, and clarifies step and include_samples interplay. This is exemplary parameter documentation.

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 and resource: 'Get the turning points between two dates — dasha changes and slow-planet ingresses.' It clearly differentiates this from sibling tools by explaining it is the 'two-clocks view' combining dasha sequence and gochara, and explicitly contrasts it with get_dasha_periods and get_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?

The description provides explicit when-to-use guidance with concrete example questions like 'what happens in the next five years' and 'when does Saturn cross my Moon'. It also states alternatives: get_dasha_periods for single-clock changes and get_transits for one-date full detail, making the routing decision unambiguous.

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 present, the description must carry the behavioral disclosure burden. It does so well by revealing a non-obvious behavior: 'transits are computed for the chart's as_of date ... not today unless the chart was created today.' It also discloses that houses are counted from BOTH the natal Moon and natal Lagna, which is a key behavioral trait 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?

The description is well-structured with a clear opening, example use cases, and a separate IMPORTANT caveat about date semantics. It is slightly longer than strictly necessary, but every sentence adds valuable information and the key caveat is front-loaded enough to be noticed before invocation.

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 single-parameter tool with no output schema and no annotations, the description is quite complete: it explains what the tool computes, from which references, and how date behavior works. The main missing piece is any hint about the output format or fields returned, but this is less critical for a simple chart_id-based lookup and does not undermine correct selection or 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 input schema only documents chart_id as a required string, and schema description coverage is 0%, so the description needs to compensate. It adds some meaning by referring to 'the chart's as_of date' and directing users to create_chart, which implies chart_id identifies the natal chart of interest. However, it never explicitly describes chart_id itself, leaving part of the semantic burden on the parameter's self-evident name.

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 'Get gochara — where the planets are now relative to the natal chart', a specific verb+resource statement that clearly identifies the tool's function. It goes further by naming the two reference frames (Moon and Lagna) and listing concrete questions the tool answers, such as 'is Sade Sati running' and 'is Jupiter transiting well', which makes it easy to distinguish from sibling get_* 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 provides clear usage context by listing example queries the tool is meant to answer ('is Sade Sati running', 'is today favourable'), which tells an agent when to invoke it. It also gives an important conditional about the as_of date and points to create_chart for other dates, but it does not explicitly name alternatives or state when not to use this tool.

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 full burden and does exceptionally well. It discloses that the chart must already be cached, describes exactly what is returned (varga ascendant, planet signs, and the method field), and warns that the counting scheme may differ from the user's tradition. It also points to describe_chart to clarify what the engine computes and deliberately omits.

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 with a one-sentence summary followed by concise argument explanations. Every sentence adds value: the return behavior, the caveat about method divergence, and the referral to describe_chart for coverage. No fluff 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?

For a simple two-parameter tool, the description covers the essential workflow: prerequisite (cached chart from create_chart), supported values (varga examples plus describe_chart reference), and return content. It lacks a detailed output structure, but since there is no output schema and the description summarizes the key return fields, it is nearly complete for an agent to invoke it 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?

Schema description coverage is 0%, so the description must compensate. It does for both parameters: chart_id is explained as the handle from create_chart, and varga is explained with examples and a pointer to the full list. It doesn't mention the default 'D9' from the schema, but the schema already carries that, and the description adds meaningful usage context.

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 and resource: 'Get one divisional chart (varga) from a cached chart.' It clearly distinguishes the tool from siblings by scoping it to a single cached varga chart, and it references create_chart and describe_chart to place it in the workflow. The purpose is unambiguous.

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 clearly implies when to use this tool: after create_chart, to retrieve one specific varga chart. It points the user to describe_chart -> varga_coverage for the full list of supported vargas, which is useful guidance. However, it does not explicitly name alternatives or state when not to use this tool, such as when a different chart type or full divisional list is needed.

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 behavioral burden. It discloses the return shape ('the score, the ceiling actually applicable, and an interpretive band') and importantly reveals that the band labels are 'a convention laid over it and tagged as such,' preventing the agent from treating them as classical quantities. This is meaningful behavioral context, though it does not cover error conditions or explicitly confirm read-only behavior beyond the 'Get' verb.

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 four sentences are tight and each earns its place: the definition, the use-case question, the maximum-score illustration, and the return-with-caveat summary. The core meaning is front-loaded in the first sentence, and there is 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 single-parameter lookup with no output schema, the description is largely sufficient: it states what is computed, what the return values are, and warns about the interpretive caveat. It could additionally clarify whether the result is returned per planet or as an aggregate, but the phrasing 'each planet's strength' reasonably implies per-planet output. Missing details are minor rather than critical.

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 for the undocumented chart_id parameter. It does not: chart_id is never mentioned or explained. The parameter's purpose is inferable from the tool's subject matter and the singular required id, but the description itself adds no parameter-level semantics. A short note confirming which chart the id refers to would have raised this score.

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 precise definition: 'Get Vimsopaka bala — each planet's dignity-weighted strength across the 16 vargas.' This names a specific verb, resource, and scope, and the use-case question distinguishes it from sibling tools like get_grahas or get_strengths by centering on divisional charts (vargas). No ambiguity remains about what the tool computes.

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 ideal-use sentence: 'Use this to answer "which planets are strong across the divisional charts?"' This is clear contextual guidance. However, it does not state when not to use it or name alternative tools, so it stops short of full when/when-not guidance.

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 a heavy burden and handles it well: it states that only rules that actually tested true are returned, each with the matched rule, and that an empty list is a real result rather than a skipped check. This prevents a likely 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?

Two short paragraphs with no filler. The first states the operation; the second adds essential interpretation. 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 simple one-parameter read tool with no output schema, the description provides the important return semantics and the critical empty-list edge case. It does not describe error behavior or exact output structure, but those are less central 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?

The single parameter chart_id has 0% schema description coverage, but the description references 'in a chart,' making the parameter's purpose reasonably clear from context. It does not explain the chart_id format or where it comes from.

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 uses a specific verb ('Get') and clearly names the resource ('yogas (classical planetary combinations)') for a single chart. It does not explicitly contrast with sibling tools, but the resource is distinctive enough among the get_* 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?

There is no guidance on when to use this tool versus alternatives like get_grahas or get_aspects. The description does explain how to interpret results, but not the selection context.

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 and does well by explaining degraded mode, the Moshier fallback, and ok/degraded status semantics. It doesn't explicitly state read-only/no side effects, but 'check' and 'reports' make the diagnostic nature clear.

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?

Three short, purposeful segments: a purpose statement, a trigger/use case, and status semantics. Every sentence adds useful information and the main point is front-loaded.

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 there is no input schema details or output schema, the description still explains what is checked, why it matters, when to call it, and how to interpret the key status field. This is sufficient for an agent to invoke and act on the result 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 tool has zero parameters, so the schema provides no burden and the description correctly adds no parameter detail. This matches the baseline for zero-parameter tools.

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?

Clearly states the tool checks server configuration and computational accuracy, with concrete reported items (ephemeris mode, engine versions, cache state). This differentiates it from the calculation-focused siblings, so an agent knows exactly what it does.

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?

Provides an explicit trigger: call when chart positions look wrong or disagree with another source, and explains the likely cause. It does not name alternatives or state when not to use it, so it stops 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the variant-based answer semantics, the need to read verdict.usable first, the cost model (one chart per candidate, minimum 20, cap 61), and the deliberate design behind the minimum. This far exceeds basic expectations and prevents realistic misuse.

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 long, but every block earns its place: mode semantics, result interpretation, cost model, and parameters are clearly organized with headers. The most important conceptual warning — that the answer unit is the variant — is front-loaded before argument details.

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 no output schema, it explains the key output field verdict.usable and the verdict behavior under few events, and it points to the error response for event_types. However, it does not fully enumerate the response shape beyond verdict.usable, so an agent may still need to discover some result fields at runtime.

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%, but the Args block explains every parameter: birth data is 'as for create_chart', tob is described as the window center rather than an assertion, events includes both format and example, half_width_minutes is constrained to max 120, and ayanamsha is defined as a sidereal zero-point. It also connects step_minutes and half_width_minutes to computational cost.

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 and resource ('Test how much a recorded birth time can actually be narrowed') and immediately distinguishes two modes. It also states what the tool does NOT return ('your real birth time is X'), sharply separating it from typical chart-calculation 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 explicitly says to use the no-events mode FIRST to decide whether rectification is worth attempting, warns that fewer than three events fits the events rather than the birth time, and cautions that probing repeatedly is the wrong way to use the tool. This is concrete, actionable selection and usage guidance.

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?

There are no annotations, so the description carries the behavioral transparency burden. It discloses realistic behavioral details: counters are per-process, reset when the client restarts the server, and the stats include cache hit rate and error breakdowns. This goes well beyond a generic 'retrieve stats' phrasing.

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 tight and well structured: one summary line, one detailed breakdown, and one line about reset behavior. Every sentence earns its place, with no filler or redundant restatement of the tool name.

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 there is no output schema, the description provides enough context by enumerating the metric categories, the per-tool granularity, and the reset lifecycle. With no parameters, there are no missing input-related details, and the expected result is adequately characterized.

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 and 100% schema description coverage, so the description does not need to explain inputs. It correctly focuses on what the returned metrics mean, which is the only relevant semantic content for a no-argument tool.

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 and resource: 'Get usage metrics for this server session,' then enumerates exact metric categories (calls, latency, errors, payload size). This is unambiguous and clearly distinguishable from sibling tools, including the similarly operational-looking health_check.

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 intended use is implied by the phrase 'Get usage metrics for this server session,' so an agent can infer when to call it. However, the description provides no explicit when-to-use/when-not-to-use guidance and does not contrast itself with siblings like health_check or other monitoring tools.

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