Sahadeva

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that — no note on computational cost, precision sensitivity to birth time (relevant for arudha/pada calculations), or determinism 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 tight fragments, no filler, with the core resource (Arudha/Upapada) front-loaded. It is efficient, though the extreme brevity is part of why the other dimensions are thin.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the schema documents most inputs. Still, for a birth-data-driven analysis tool sitting among many look-alike siblings, the description omits what makes this output distinct and what inputs it depends on, leaving it only minimally 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 75% with 8 parameters, and the description contributes nothing about any of them — not the date/time/location requirement, not the place-vs-coordinates branch of the anyOf. It does not compensate for the parameters that carry no schema description (latitude, longitude).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific domain artifacts computed: Arudha Lagna, Upapada, all twelve padas, and Jaimini rashi drishti. An agent can tell this is a Jaimini arudha-structure analysis, which separates it from generic siblings like analyze_house or calculate_strength_profile. It does not, however, distinguish itself from the close sibling calculate_jaimini or analyze_special_points.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the ~80 sibling analyzers. The agent is left to infer that this is a specialized structural read, with nothing stating when it should be preferred over calculate_jaimini or analyze_special_points.

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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description's added value is the epistemic constraint that no supernatural causation is inferred — genuinely useful context for a Jyotish tool. It says nothing about output shape, but an output schema exists, so that is not required here.

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 with zero filler and the key concept front-loaded. The leading fragment 'BADHAKA.' duplicates the tool name and adds no information, which is the only waste.

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?

Return values need not be explained since an output schema exists, and the anyOf coordinate/place requirement is documented in the schema. What is missing is disambiguation within a ~90-tool Jyotish suite: nothing tells the agent when this specialized structural analysis is warranted over analyze_house or analyze_special_points.

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 75% and the description adds no parameter-level detail beyond an implicit reference to the Lagna's modality, which is derived from the birth date/time/place inputs. With the schema doing most of the work, baseline 3 is appropriate.

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 resource — the Badhaka (obstruction) house and its lord, derived from the Lagna's modality, plus its placement and relationships. That is far more than a restatement of the name. It does not, however, differentiate itself from near siblings such as analyze_house or analyze_special_points, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use statement, no prerequisite (birth data or coordinates required via the anyOf), and no alternative named. The closing clause 'Structural only; no supernatural cause is inferred' is an interpretive stance, not routing guidance. An agent gets no help deciding this tool over analyze_house.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds a genuine epistemic trait beyond annotations — output is evidence-linked and explicitly avoids deterministic outcome claims — which sets expectations for how results should be framed. It stops short of describing depth, determinism of scope, or any limitations.

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?

A single short sentence with no filler, which is appropriately sized, but the phrasing is awkward ('Evidence-linked analyze career structure') and reads as a name-plus-disclaimer rather than a front-loaded statement of purpose. Brevity here reflects under-specification rather than disciplined concision.

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 10 parameters, two input modes (place or lat/long/timezone), and a topics enum, the description omits input guidance, topic selection, and how results relate to the sibling analyzers. An output schema exists, so return format needn't be explained, but nearly everything else an agent needs for correct invocation 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?

Schema description coverage is only 30% and the description adds zero parameter detail: it never mentions date, time, the place-vs-coordinates anyOf requirement, the topics enum, or asOfIso. With 10 parameters and two mutually exclusive input modes, the description leaves the agent to reconstruct input requirements entirely from the schema. It 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 sentence essentially restates the tool name ('analyze career structure') with two qualifiers, so an agent learns nothing about what the analysis actually produces or what domain inputs drive it. 'Evidence-linked' and 'without deterministic outcome claims' describe epistemic posture, not the operation. No differentiation from siblings like analyze_house or analyze_chart_topic.

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 when-to-use guidance, no exclusions, and no named alternative among the many overlapping siblings (analyze_chart_topic, analyze_house, analyze_yogas, detect_life_themes). The only implicit hint is that the tool concerns careers. Nothing tells the agent when this tool is the right choice over a broader chart analysis.

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 already declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the deterministic pipeline, supporting vs opposing evidence, uncertainty handling, and explicit abstention boundaries. It omits any note on auth, rate limits, or latency, so it is not a full 5.

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 tightly written sentences, front-loaded with the core action before the return contents. The closing sentence about the web app sharing the engine is low-value framing but brief, so little 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?

An output schema exists, so return-value detail is not strictly required (and the description arguably over-covers it). But with 12 parameters at 0% coverage and no sibling differentiation, the definition leaves real gaps for an agent deciding how to invoke it versus its many analyze_* neighbors.

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% across 12 parameters, so the description carries the full burden of explaining them — and it does not. It never mentions the required date/time pair, the place-vs-coordinates anyOf, timezoneOffset, language, or birthTimeAccuracyMinutes, and it lists only five of the eight topic enum values.

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 ('Runs the shared deterministic judgment pipeline') plus the topical scope, and the return ledger is named. However, it does not distinguish itself from close siblings like analyze_career_structure or analyze_education_structure, leaving overlap unresolved. The topic list also omits three enum values (wealth, health, children), which slightly muddies the stated scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use, when-not-to-use, or alternative routing. Given siblings such as analyze_house, analyze_varga, and the per-topic analyze_*_structure tools, an agent has no guidance on why it would call this instead of those. Only an implied 'one topic at a time' reading is available.

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 already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety behavior is covered. The phrase 'Evidence-linked ... without deterministic outcome claims' adds a genuine epistemic trait (the output will be sourced and non-fatalistic), which is useful beyond annotations, though it is too vague to describe output format or limits.

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?

A single short sentence, but it is under-specified rather than concise — it mostly echoes the name/title and omits the information an agent needs. Brevity here reflects missing content, not efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, anyOf-constrained tool with an output schema and many domain siblings, the one-sentence description is grossly incomplete. Return values are covered by the output schema and safety by annotations, but usage, parameter meaning, and analytical scope are all absent.

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 10 parameters and only 30% schema description coverage, the description must compensate and adds nothing: no mention of date/time requirements, the place-vs-coordinates anyOf branch, topics, asOfIso, or name. An agent gets no semantic help for the 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 is essentially the title restated: 'Evidence-linked analyze education structure without deterministic outcome claims.' It names no specific analytical content (houses, planets, dashas, etc.) that would let an agent distinguish this education analysis from the many sibling 'analyze_*_structure' tools. The only added content is an epistemic disclaimer, not a purpose statement.

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 siblings like analyze_career_structure, analyze_marriage_structure, or analyze_chart_topic, nor any prerequisites or exclusions. The description gives no context for selection.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds genuine non-annotation context: outputs are 'evidence-linked' and deliberately avoid deterministic outcome claims, which tells the agent how to frame results. It still says nothing about input validation failures or the required date/time plus location-vs-coordinates branching.

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?

It is a single short sentence with no padding, so nothing is wasted, but it is a fragment whose brevity comes from under-specification rather than disciplined compression. Being front-loaded is easy when there is only one clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a 10-parameter analysis tool sitting in a dense sibling cluster, the description omits the analysis scope, its topic coverage (the topics enum), the location-vs-coordinates requirement, and any guidance on interpreting 'evidence-linked' results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 30%: place, timezone, and timezoneOffset carry descriptions, but date, time, name, topics, asOfIso, latitude, and longitude are documented nowhere. The description adds no parameter meaning at all, so it fails to compensate for the coverage gap on a 10-parameter tool with an anyOf location requirement.

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 sentence 'Evidence-linked analyze finance structure without deterministic outcome claims' essentially restates the tool name and title without explaining what a 'finance structure' analysis actually produces (wealth houses? income vs. assets? dasha timing?). It offers no differentiation from close siblings such as analyze_career_structure, analyze_marriage_structure, or analyze_education_structure, which follow the identical naming pattern.

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 when-to-use guidance, no stated prerequisites (e.g., a chart must already exist), and no routing to or away from alternatives among the ~80 sibling tools. The only framing is the epistemic caveat about deterministic claims, which is a constraint rather than 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: 'supporting and opposing evidence', 'unresolved source keys' and 'sensitive-house restrictions' signal evidence-quality and possible restriction behavior, but these terms are left undefined, so the added value is partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single dense sentence with no filler, which is good, but it is an undifferentiated comma-separated output dump rather than a front-loaded statement of function followed by supporting detail. Short, but not well 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?

An output schema already exists, so the description's entire content — a list of return fields — is largely redundant. Meanwhile the elements an agent actually needs (when to use it, how the 9 inputs including the anyOf location branch work, what restrictions apply) are absent. Incomplete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% across 9 parameters, so the description must compensate and does not: it never mentions date, time, the 1-12 house input, the place-vs-latitude/longitude/timezone anyOf requirement, or timezoneOffset. Only 'the selected house' obliquely gestures at the house parameter.

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 enumerates what is returned (house, lord condition, occupants, functional lordship, evidence) which lets a reader infer this is a per-house analysis tool, but it never states the action in verb+resource form and offers no differentiation from the many sibling analyzers (analyze_career_structure, analyze_marriage_structure, analyze_finance_structure, etc.). The purpose is recoverable but vague rather than sharply stated.

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 when-to-use guidance, no prerequisites (e.g. chart data required), and no routing to alternatives such as the topic-specific structure analyzers or analyze_chart_topic. The agent must guess whether this generic house tool or a specialized sibling is appropriate.

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 already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lowered. The description adds real value beyond them by bounding scope (no prediction prose, no annual-chart emulation) and stating what is actually returned (source locators per planet-house section) — a no-annotation schema could not convey that.

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, zero filler, with the core transformation front-loaded before the scope limitations. Both the negative scope statement and the sibling pointer earn their place by preventing misfires.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be re-explained, and the read-only annotations cover the safety profile. The one remaining gap is the input contract — the agent gets no prose about the dual place/coordinate requirement, leaving a fairly complex 9-parameter anyOf schema to speak entirely for itself.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (3 of 9 params), and the description supplies no parameter guidance at all — no date/time format, no explanation of the place-vs-latitude/longitude/timezone anyOf branch, no note on the birthTimeAccuracyMinutes default. With low coverage the description was expected to compensate and does not.

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+resource transformation (natal placements -> Lal Kitab fixed houses) and names the concrete deliverable (source locators for all nine planet-house sections). It also explicitly excludes two adjacent capabilities (prediction prose, annual-chart emulation), which sharply distinguishes it from siblings like analyze_house and analyze_lal_kitab_remedies.

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 routes the agent away from this tool for remedies, naming analyze_lal_kitab_remedies and reason_lal_kitab as the correct destinations, and rules out prediction/annual work. It stops short of stating positive preconditions (e.g. that chart placements must already be verified/calculated) or naming the tool that produces those verified placements.

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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description usefully adds that matches come from a fixed 778-page corpus and that results carry provenance and risk-flag labels, but it omits any note on computation cost, chart preconditions, or how the nine houses are derived.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight, front-loaded sentences with no filler; the purpose leads and the output content follows. Minor redundancy in describing return fields when an output schema already exists.

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 9-parameter tool with an anyOf input structure and only 33% schema coverage, the description leaves the most confusing part — how to supply a location versus explicit coordinates — entirely unaddressed. The output schema covers return values, so the return-value sentence is not the missing piece; the input guidance is.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% and the description explains no parameters at all — it never mentions date/time, place, or the place-vs-coordinates (latitude/longitude/timezone) alternative required by the schema's anyOf. With low coverage the description should compensate but adds nothing beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Matches the chart's nine fixed-house placements to remedy blocks') and a concrete scope ('extracted from the complete 778-page corpus'). It is clearly distinct from generic remedy tools, but it never names or contrasts with close siblings like analyze_remedies or explore_lal_kitab_remedy_catalog.

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 when-to-use guidance, no prerequisites, and no alternatives named. The description implies the tool operates on an already-computed chart, but an agent gets no signal on when to pick this over the sibling remedy/catalog tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: every finding is tied to a located passage, unanswered questions are explicitly marked unavailable, and no deterministic outcome claims are made. It stops short of stating input prerequisites (the place/coordinate requirement) or any limits on what the installed texts can answer.

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 lead clause front-loads the deliverable well, and the closing sentences about citation and non-determinism are high value. The middle sentence, however, is a dense comma-separated run-on enumerating the six profile parts that is hard to parse on first read, hurting structure more than 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?

An output schema exists, so the description is not obliged to explain return values, and it focuses instead on the epistemic stance of the findings. The unresolved completeness gaps are on the input side (11 parameters, low schema coverage, unstated coordinate/place requirement) and the lack of any sibling routing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 36% across 11 parameters, so the description is expected to compensate, but it names no parameter. 'the person's current place' only loosely gestures at currentPlace, and date, time, name, topics, asOfIso, latitude/longitude/timezone receive no explanation at all. The anyOf requirement (place vs. coordinates+timezone) is never surfaced.

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 gives a specific, concrete account of what the tool produces: an evidence-linked marriage structure plus a six-part spouseProfile covering timing, new/known partner, direction from the current place, partner nature, work hints, and prior relationships. This is far beyond a restatement of the name. However, it never contrasts itself with close siblings such as find_marriage_windows, get_marriage_readiness, or calculate_relationship_compatibility, so an agent must infer the boundary from the name alone.

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 when-to-use statement, no prerequisite (e.g., accurate birth date/time), and no named alternative. Given a sibling set that contains several other marriage/relationship tools, the absence of any routing guidance is a real gap, leaving usage purely implied by the tool name.

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 already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds two genuine behavioral traits beyond that: output is 'evidence-linked' and it avoids deterministic predictions. However, it says nothing about required auth, birth-data prerequisites, or how evidence is surfaced.

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?

It is a single short sentence with no filler, so it is not bloated, but its brevity comes at the cost of substance. The one clause that matters is front-loaded after the redundant restated 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?

For a 10-parameter, dual-input-mode analysis tool, this is substantially incomplete: it omits the place/coordinates requirement, the topics enum meaning, and the significance of asOfIso. An output schema exists, so return values need not be explained, but the input and routing context 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?

Schema description coverage is only 30% (10 params; place, timezone and timezoneOffset described). The description adds zero parameter meaning and does not compensate for undocumented date, time, name, topics, or asOfIso, nor does it explain the anyOf place-vs-coordinates input rule.

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 largely restates the tool name ('analyze nakshatra profile') with two qualifiers, rather than stating a specific verb+resource outcome. It never says what a nakshatra profile actually is or how it differs from closely-related siblings like calculate_devata_profile, get_natal_panchanga, or analyze_chart_topic.

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 when-to-use, when-not, or alternative-tool guidance. The only hint is the phrase 'without deterministic outcome claims,' which describes a stance on results rather than a condition for selecting this tool over its many analyze_* 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?

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuine behavioral context by disclosing that numerology is 'labelled modern, not classical' and by distinguishing which checks require a full chart versus date alone — useful framing an agent cannot get from annotations.

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 core action is front-loaded and every sentence carries information, but the opening sentence is a dense run-on packing five distinct analyses together. It is appropriately sized for the tool's complexity with only mild structural looseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the description adequately frames the domain and the classical-versus-modern split. For an 11-parameter tool it is largely complete, though the thin parameter coverage leaves some input details to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 27%, so the description must compensate. It clarifies the role of date/time/place and name/spellings, but says nothing about latitude, longitude, timezone, timezoneOffset, variantLimit, or when generateVariants applies, leaving roughly half the parameters' semantics unaddressed.

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 with unusual precision: it checks a name's first syllable against the Moon's birth nakshatra pada (Avakahada rule) and scores it with Chaldean/Pythagorean/Cheiro numerology. An agent can distinguish this from siblings like analyze_nakshatra_profile or calculate_devata_profile purely from this text.

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 concrete input guidance ('Give date, time and place for the chart-based checks; date alone gives birth numbers only'), which tells the caller what to supply for which depth of analysis. It does not, however, tell the agent when to prefer this over a sibling tool or when it is inapplicable.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful epistemic context by saying results are 'Evidence-linked' and avoid 'deterministic outcome claims,' which is meaningful for a predictive astrology tool. It does not, however, describe input requirements, limitations, or output behavior beyond that constraint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, which is structurally concise. However, it is grammatically awkward and front-loads the vague modifier 'Evidence-linked' before the actual verb and resource. For a tool with 10 parameters and an anyOf constraint, this level of brevity leaves the definition under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 10 parameters, a required date/time pair, and an anyOf requirement for either place or latitude/longitude/timezone, yet the description gives no input guidance. An output schema and rich annotations reduce the need to explain return values and safety, but the description still omits critical invocation context. It is not complete enough for an agent to call this complex 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?

The description provides no information about any of the 10 parameters. With schema description coverage at only 30%, the description needed to compensate for undocumented parameters such as date, time, topics, asOfIso, and the anyOf place-versus-coordinates requirement, but it does not. The agent must rely entirely on a partially documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb ('analyze') and a resource ('property and vehicle'), so the broad purpose is discernible. However, it largely repeats the tool name and does not specify what kind of analysis is performed or how it differs from siblings like analyze_house, analyze_career_structure, or analyze_chart_topic. The added phrases 'Evidence-linked' and 'without deterministic outcome claims' describe an output stance rather than clarifying the purpose.

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, no prerequisite information, and no exclusions. The phrase 'without deterministic outcome claims' hints at a constraint, but it does not tell the agent when this analysis is appropriate. The agent receives no routing help despite a large set of related analyze_* 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context that every candidate exposes its source and that belief/cost/burden preferences constrain the output, but it doesn't explain how preferences filter results or what happens on missing/invalid inputs.

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, front-loaded with the core purpose and followed by the component list. Dense but every clause names a distinct output domain; the enumerated repertoire reads slightly list-like but is not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. However, for a complex 14-parameter tool with a nested required preferences object and an anyOf location constraint, the description omits prerequisites and input expectations, leaving the agent to infer them from the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 29%, so the description carries extra burden. It does map to the nested preferences object (belief/cost/burden) and the topic ledger, but it says nothing about date/time/place, the coordinate-vs-place anyOf requirement, or detail/language semantics, leaving most of the 14 parameters to the 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 gives a concrete verb (combines/calculates) and names the specific artifact produced: a chart remedy protocol spanning mantras, gemstones, vrata, charity, conduct and Lal Kitab remedies, with source exposure. It is specific about scope, but it never distinguishes itself from near-overlapping siblings like build_remedy_repertoire, analyze_lal_kitab_remedies or explore_lal_kitab_remedy_catalog.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance. With siblings such as build_remedy_repertoire, suggest_safe_practice and analyze_lal_kitab_remedies in the same space, the agent is given no criteria for choosing this tool over them.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description is not required to carry it. The description adds only a catalogue of computed outputs and says nothing about computation cost, determinism of results, or data prerequisites, which is a modest contribution given a rich annotation set.

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?

A single dense sentence, front-loaded with the 'SPECIAL POINTS' label, and every item in the list corresponds to a distinct computed quantity rather than filler. It is long but the length is load-bearing for enumerating the output domain.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is not required, and the annotations cover the safety profile. What is missing is any usage framing or input prerequisite for a tool whose inputs (place or coordinate triple plus date/time) are non-obvious, leaving the definition adequate but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description says nothing about the 8 parameters; it is purely a list of computed points. Schema coverage is 75%, near the threshold where the schema does the heavy lifting, so a baseline 3 is appropriate — the date/time/place vs latitude/longitude/timezone alternative is documented in the schema, not the description.

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 enumerates exactly what is computed — Upagrahas (Dhuma group, Gulika/Mandi/Kala/Mrityu/Ardhaprahara/Yamaghantaka), Bhrigu Bindu, Yogi/Avayogi, Jagradadi avasthas, Pushkara, Gandanta, Vargottama, and nakshatra attributes — so the resource is unambiguous. However it never states a verb or draws a line against siblings that also cover nakshatra attributes (analyze_nakshatra_profile) or sensitive degrees/strength (calculate_strength_profile, analyze_varga).

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 statement of when to reach for this tool versus the many overlapping analyzers in the sibling list, nor any prerequisite (e.g. that a birth date/time and place or explicit coordinates are required). The agent must infer usage from the output enumeration alone.

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 already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds two useful behavioral notes – 'evidence-linked' and no deterministic outcome claims – but does not explain what evidence linkage means in practice or how outputs are constrained.

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 single sentence is too short for a tool of this complexity; it under-specifies rather than being concise, and the qualifiers are not front-loaded with actionable scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter analytical tool with many siblings and low schema description coverage, the description is inadequate. Output schema existence relieves return-value explanation, but usage, scope, and parameter semantics are 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?

With 10 parameters and only 30% schema description coverage, the description supplies no parameter meaning at all (date, time, place, topics, coordinates/timezone, asOfIso, etc.). It fails to compensate for the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is essentially the tool name and title reworded ('analyze spiritual path') with two qualifiers, so it is tautological rather than stating a specific analytical operation. It does not distinguish this tool from siblings like analyze_chart_topic or analyze_house.

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 when-to-use, prerequisites, alternatives, or exclusions are given. The phrase 'without deterministic outcome claims' is a constraint, not 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety behavior is covered elsewhere. The description adds that it combines natal promise with running dasha and slow transits between startIso and endIso, which is useful computation context, but it does not disclose output format, performance, or other behavioral caveats beyond what annotations provide.

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 a clear purpose label ('TIMING FOR A TOPIC') followed by two tightly scoped sentences. Every sentence adds routing or scope information, with no redundant explanation of values already covered by 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?

An output schema exists, so the description need not explain return values, and it successfully covers purpose, usage, and the key alternative sibling. Given the tool's complexity and 12 parameters, it could say more about parameter roles, but the core guidance needed to select and invoke the tool 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 50%, and the description only mentions startIso and endIso as a range while repeating the topic enum values already present in the schema. It offers no clarification for other required or optional parameters such as asOfIso, date, time, place versus coordinates, or timezone handling, so it fails to compensate for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific function: combining natal promise for one topic with running dasha and slow transits over a time range. The scope is concrete and the sibling it is not (analyze_transits) is named, so an agent can distinguish it from related timing tools without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use it for 'when' questions about one area of life and names analyze_transits as the alternative for a plain list of current transits. It does not address other similar siblings like find_marriage_windows or fuse_timing, so it stops short of full when-not coverage, but the primary routing guidance is 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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description usefully anchors the computation to asOfIso, clarifying that this is a snapshot evaluation rather than a forecasting timeline. It adds no notes on cost, limits, or how the birth-data inputs must be supplied relative to the as-of date.

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?

Front-loaded with the tool name and core concept, then a single dense enumeration of outputs, then the usage cue. No filler sentences, though the undifferentiated jargon list is heavy to parse in one pass.

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 nine-parameter analytical tool with an output schema present and annotations covering safety, the description is complete enough: it enumerates the computed factors (houses from Moon and Lagna, Vedha, Ashtakavarga bindus, Kakshya, Murthy Nirnaya, Sade Sati, double-transit houses) and names the triggering user question.

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 78%, so the schema carries most parameter meaning and a 3 is the baseline. The description only ties asOfIso to the output ('for each graha at asOfIso'); it does not explain the place-vs-explicit-coordinates branch, the timezone/timezoneOffset relationship, or the date/time birth inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific computation (current Gochara transits against the natal chart) and enumerates exactly what each graha output includes. An agent knows precisely what the tool returns, but the description never distinguishes it from close siblings such as calculate_gochara, calculate_gochara_from_known_place, or analyze_transit_activation, all of which sit in the same domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use for 'how are my transits now / this month'" gives a clear intended scenario, but there are no exclusions and no routing advice despite heavy sibling overlap with calculate_gochara and analyze_transit_activation. Usage is implied rather than scoped.

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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower and the description clears it by adding real behavior: only one varga per call, and D60 demands an accurate birth time. The data-quality dependency caveat is genuinely useful context not available in structured fields.

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 sentences, front-loaded with the single-chart constraint and then the selection guidance. The parenthetical enumeration of varga codes partially restates the schema enum, which is slight redundancy, but the rest is waste-free.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and annotations carry the safety profile. The description adequately covers scope, varga selection, and precision caveats for a 10-parameter tool; the main omission is any hint about the place-vs-coordinates input branch, which the schema does document.

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 60% schema coverage, the description compensates by mapping astrological topics to specific varga codes and flagging the birth-time precision requirement tied to D60. It adds real interpretive meaning beyond the enum list, though it says nothing about the topic, date/time, or coordinate alternatives.

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?

Opens with a precise scope statement ("ONE DIVISIONAL CHART") and names the concrete outputs: placements, lords, topic emphasis. It clearly delimits the tool to a single varga, which distinguishes it from broader synthesis tools, though it never names a sibling alternative explicitly.

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 actionable selection guidance for the core parameter (D9 marriage/dharma, D10 career, D7 children, D4 property, D24 education, D60 fine detail), which is exactly what an agent needs to pick a varga. It stops short of stating when to prefer this over siblings or when not to use 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral content beyond that: the evaluation emits rule, evidence, cancellation tests, a participant-strength grade, and the dasha periods activating each yoga — i.e., it tells the agent what analysis is actually performed and surfaced.

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?

A single lead label ('YOGAS.') front-loads the topic and one dense sentence carries the whole scope, with no filler. The long enumerated list is justified because it defines the tool's coverage boundary, though it pushes toward the verbose end.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, annotations cover the safety profile, and the description fully characterizes the analytical scope. What is missing is only routing guidance against the many overlapping analysis siblings, which keeps it short of a 5.

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 78%, so the schema already documents nearly all nine parameters (date, time, place, lat/long/timezone, asOfIso). The description contributes no parameter-level detail such as the coordinate-vs-place alternative or how asOfIso drives the dasha windows, so the baseline 3 applies.

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 ('Evaluates') and resource ('about a hundred classical yogas') and then enumerates the exact families covered (Nabhasa, Pancha Mahapurusha, Chandra/Surya, Raja, Dhana, Viparita, Parivartana, Neecha Bhanga, Lakshmi/Saraswati/Parvata). This clearly separates it from siblings like calculate_doshas or analyze_house.

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 scope implies when to reach for it (you want yoga formation/strength/timing analysis), but there is no explicit when-to-use or when-not-to-use guidance and no named alternative for overlapping tools such as calculate_doshas, calculate_strength_profile, or get_timing_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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description still adds real behavioral value beyond the annotations by disclosing that the gates are independent and, notably, that Lal Kitab is reported as source-only until a dedicated reviewed engine exists – a substantive caveat about the tool's output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with zero filler. The enumeration of the readiness domains is front-loaded, and the Lal Kitab caveat is appended as a distinct, clearly-scoped fact rather than buried in prose.

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 an output schema present, the description is not obligated to explain return values, and with no parameters and full annotation coverage the remaining burden is light. It is nearly complete, but a brief note on when this readiness check should be run relative to the validation siblings would close the one real 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?

The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description is needed to clarify inputs, and it correctly does not waste space restating a nonexistent parameter set.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (reports) and a specific resource (independent readiness gates) and enumerates the five domains assessed: calculations, executable rules, worked examples, practitioner review, and outcome calibration. This distinguishes it reasonably well from generic siblings like get_validation_report, though it never explicitly contrasts itself with get_synthesis_validation_status or knowledge_status, which an agent might confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to call this tool versus the many similar-sounding readiness/validation siblings (get_synthesis_validation_status, get_validation_report, get_marriage_readiness, knowledge_status). No prerequisites or exclusions are stated; the agent must infer usage purely from the name and the list of gates.

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 already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds a genuine scope boundary beyond the structured fields: it explicitly disclaims external ephemeris recomputation, telling the agent what the audit does NOT verify.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the scope statement front-loaded and the disclaimer second. Nothing is padded, though the dense enumeration is slightly hard to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. However, for a 9-parameter audit tool with 33% schema coverage, the description leaves the input contract and the when-to-use-vs-siblings question substantially unaddressed.

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 only 33% across 9 parameters, so the description is expected to compensate, yet it mentions no parameter at all. The agent gets no help on the place-vs-coordinates anyOf, the timezone requirement, or birthTimeAccuracyMinutes, which is the parameter most relevant to a sensitivity audit.

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 (checks) and enumerates the resources it audits: engine certification, timezone provenance, conventions, and boundary distances. This clearly reads as a calculation-provenance verifier. It does not, however, explicitly distinguish itself from near-neighbors like explain_chart_sources, get_validation_report, or compare_conventions.

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?

'...before interpretation' implies the usage context (run prior to reading a chart), which is a meaningful hint. But it names no alternatives, no prerequisites, and no conditions under which another audit/validation sibling should be preferred.

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 already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: the five gate families it applies, the three possible verdicts (publish, caution, claim-level abstain), and the policy that sensitive topics stay answerable with bounded reflections. That is meaningful disclosure for a decision 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?

Two tight sentences, front-loaded with the action and verdict set, then the sensitive-topic policy. No filler, though the dense gate jargon goes unexplained, which slightly undercuts readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be spelled out. But for a 10-parameter audit tool the description leaves the entire input contract — especially harmClass and the evidence arrays — to an undocumented schema, and gives no routing guidance among the several sibling audit tools.

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?

Ten parameters with 0% schema description coverage, so the description carries the full explanatory burden — yet it documents none of them. The gate names ('calculation', 'approved-rule', 'opposition', 'calibration', 'harm') loosely hint at calculationCertified, approvedRules, opposingEvidence, empiricallyCalibrated and harmClass, but nothing is explicit, and the enum for harmClass is never 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?

States a specific verb and resource (audit one prediction claim) and adds a sequencing cue (before narration) that separates it from generic audit siblings. It does not, however, name or differentiate itself from the closely related assess_prediction_readiness or audit_reading_evidence 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?

'Before narration' implies the point in the workflow at which to call it, but there is no explicit when-to-use versus assess_prediction_readiness / audit_reading_evidence / audit_chart_calculation, and no stated prerequisites or exclusions. Usage must be inferred.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the tool 'lists contradictions,' hinting at output behavior, but says nothing about what a contradiction is, how placements are sourced, or any limits beyond the annotations.

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 with the action front-loaded and no filler. Efficient, though arguably over-sparse for a 9-parameter tool with a domain-specific 'safety rules' concept.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return format needn't be described. However, for a tool demanding full birth data plus up to 30k characters of prose, the description omits key context: what safety rules are, how placements are computed, and what 'audit' produces conceptually.

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 67% (latitude/longitude/text lack descriptions), which is below the 80% threshold, so the description should compensate but does not. It never explains that the 9 inputs form a birth-data block (date/time/place or coordinates) whose chart the prose is audited against, leaving the coordinate-vs-place choice to the schema's anyOf.

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 ('checks/audits') against a defined resource ('prose'/'reading') and names the two comparison bases: calculated placements and safety rules. This distinguishes it reasonably from siblings like audit_chart_calculation or audit_prediction_claim, though it doesn't explicitly name them.

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 no when-to-use context, no prerequisites, and no routing to related tools such as audit_prediction_claim, get_validation_report, or validate_rule_spec. The agent must infer when auditing prose is the right call versus any of the ~80 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The phrase 'without deterministic outcome claims' is the one behavioral signal the description contributes, but it is too vague to tell the agent what the output guarantees or refuses to do. No mention of latency, dependencies, required evidence inputs, or failure modes.

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 single sentence is short, but brevity here reflects under-specification rather than conciseness: it is a fragment that repeats the tool name and carries no actionable content. Nothing is front-loaded because there is nothing substantive to front-load. This mirrors the calibration case where a one-word 'Process' description scored low on this dimension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with a branch-conditional input schema and an output schema, a single fragment sentence is wholly inadequate. Even granting that the output schema can explain return values, the agent still has no idea what evidence sources are consulted, what the ledger aligns, or how this differs from the many audit/journal siblings. Nothing an agent needs in order to invoke it correctly 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 only 30% across 10 parameters, and the description provides no parameter information whatsoever — no mention of date, time, place, coordinates, timezone, topics, or the anyOf branch requiring either 'place' or latitude/longitude/timezone. With low coverage, the description was obligated to compensate and does not. The one input constraint the description could clarify, the exclusive place-vs-coordinates requirement, is left entirely to 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 is essentially a restatement of the name and title: 'Evidence-linked build claim evidence ledger' adds no verb or resource framing beyond what the tool name already says. The only extra semantic content is a negative qualifier ('without deterministic outcome claims'), which describes an epistemic stance rather than what the tool produces. It does not distinguish this tool from auditing siblings such as audit_reading_evidence or audit_prediction_claim.

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 statement of when to use this tool, when not to, or which sibling to prefer. With roughly a dozen adjacent evidence/claim/journal tools (audit_prediction_claim, audit_reading_evidence, build_prediction_journal), the absence of any routing guidance leaves the agent to guess. The description is silent rather than misleading, so it lands at the low end of the scale rather than 1.

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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds useful artifact context — the claim must be falsifiable and carries a review date. It does not clarify the key ambiguity of whether the claim is persisted ('freeze'/'journal' vs readOnlyHint=true) or what happens on repeat calls, leaving a real 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 tight sentences, front-loaded with the core action and output components, with the follow-up routing last. No filler, though the density means parameter details get squeezed out.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, but for a 12-parameter tool with zero schema descriptions the description is far too thin — an agent cannot infer what most inputs mean or whether the call persists state.

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% across 12 parameters, so the description must carry the semantic load and largely does not. 'Topic judgment' loosely gestures at the topic enum and 'review date' at a date field, but date, time, place, latitude, longitude, timezone, asOfDate, nodeMode, and birthTimeAccuracyMinutes are entirely unexplained.

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 gives a specific verb (builds) and resource (one reviewable claim from a topic judgment) and enumerates the artifact's parts: active dasha window, observable outcome, falsifier, review date. It distinguishes itself somewhat by naming record_consultation_outcome as the resolution counterpart, but does not separate itself from close siblings like audit_prediction_claim or build_claim_evidence_ledger.

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 points to the downstream step ('Resolve it later with record_consultation_outcome'), which is a genuine lifecycle hint. However, it gives no guidance on when to choose this over the many adjacent claim/audit tools, so usage is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered; the description adds genuinely new behavioral context by describing the computation pipeline and the default-on/exclude-with-false semantics of the remedy families. It does not discuss cost, rate limits, or output size, but the defaults behavior is the key trait an agent needs.

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 long opening sentence is dense but front-loaded with the output inventory, followed by two short sentences that carry the default/exclusion rule and the 'no topic required' cue. No sentence is filler, though the family list is heavy enough to slow scanning slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description covers what the tool produces and how to scope it. But for an 11-parameter tool with nested options and a place-versus-coordinates alternative, the description leaves the birth-data inputs entirely to the schema at 27% description coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 27% across 11 params (including a nested options object), so the description carries some compensating burden. It does explain the options booleans collectively ('every family is on by default; pass false to leave one out'), but says nothing about date/time formats, the place-vs-coordinates alternative, language, or birthTimeAccuracyMinutes.

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 (works out each graha's functional nature and afflictions) and enumerates the concrete deliverables (beej/Vedic mantras, stotra, gemstone, daana, vrata, rudraksha, yantra, conduct, Lal Kitab remedies, dosha remedies, dasha timing), which separates it from narrow siblings like analyze_remedies or analyze_lal_kitab_remedies. It never names those siblings explicitly, so the differentiation is inferable rather than stated.

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 topic required' implies a contrast with topic-driven tools, and 'Every family is on by default; pass false to leave one out' gives operational guidance for scoping the output. However, there is no explicit when-to-use-this-vs analyze_remedies / analyze_lal_kitab_remedies / suggest_safe_practice statement, so the agent must infer the 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description usefully discloses the computational scope: carefully bounded slow-transit periods over a future interval plus Vimshottari intersections. It adds no auth, performance, or output-format context.

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?

A single front-loaded sentence led by the verb 'Returns' with no filler. It is dense with domain jargon but every clause names a distinct output, so little 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?

An output schema exists, so return structure needn't be explained, and the description enumerates the main outputs. However, for an 11-parameter tool it omits why both a natal birth moment and a future interval are required, leaving a real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 9% across 11 parameters, so the description must compensate but largely does not. Only 'selected future interval' loosely maps to startDate/years; the seven required natal inputs (date, time, place, latitude, longitude, timezoneOffset) and their relationship to the interval are never 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?

States a specific output: Saturn/Jupiter/Rahu/Ketu sidereal sign periods, Sade Sati/Dhaiya ranges, and Vimshottari intersections. An agent can tell what it computes, but nothing distinguishes it from close siblings like calculate_ingress_timeline, calculate_gochara, or fuse_timing, which likely produce overlapping transit 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?

No when-to-use, when-not, or alternative guidance is given. With many transit/timing siblings (calculate_gochara, analyze_transit_activation, get_timing_context, query_vimshottari_date), the agent has no basis from the description to choose this tool over them.

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 already declare this is a read-only, idempotent, non-destructive, closed-world calculation, so the safety profile is fully covered. The description adds the computational outputs (reductions, Pinda) but says nothing about input prerequisites or how results are scoped; with annotations doing the safety work, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the technique name front-loaded and no filler. It is efficient, though the lead token 'ASHTAKAVARGA.' is a bare label rather than a load-bearing clause.

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 an output schema present and a 75%-documented input schema, most detail is carried structurally; the description supplies the computational scope, which is the main missing context. The one gap is not noting the birth-data/coordinates requirement, but that is captured by the schema's required fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so parameter documentation largely lives in the schema, and the description contributes no parameter-level detail (e.g. date range limits or the place-vs-coordinates alternative). Baseline 3 is correct when the schema does the heavy lifting and the description adds nothing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific techniques computed (Bhinnashtakavarga for seven planets, Sarvashtakavarga, Trikona/Ekadhipatya reductions, Pinda), so the agent knows exactly what the tool produces. Compared to siblings like calculate_strength_profile or calculate_gochara, however, it doesn't explicitly say why this differs from those general strength/transit tools, leaving overlap unresolved.

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?

'Use for sign strength and transit support' gives an implied context for invocation, but no alternatives are named and no when-not conditions are stated. An agent cannot tell from this alone when to prefer it over calculate_strength_profile or analyze_transits beyond a vague thematic hint.

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 already declare readOnly/idempotent/non-destructive, but the description adds genuine behavioral context: reporting boundary changes, preserving per-convention validation status, and explicitly stating that non-Lahiri full derived systems are not silently recomputed. That last clause is a real behavioral guarantee an agent cannot get from the annotations.

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 sentences with no filler, front-loaded on the verb and the selectable conventions. The final sentence about non-recomputation is slightly cryptic in isolation but carries real 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?

An output schema exists, so return values need not be explained, and the boundary-change/validation notes add useful context. However, with 11 parameters at 27% coverage and a required anyOf branch, the description omits how the coordinate vs. place inputs interact and leaves much of the input contract unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 27% across 11 parameters, so the description carries a heavy burden it does not meet. It names the four ayanamsa enum values, but those are already in the schema enum, and it says nothing about the place-vs-coordinates anyOf, date/time formats, or the several undocumented numeric 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 gives a specific verb and resource ('Projects placements and sign-based Graha Drishti') and scopes it to four named ayanamsa conventions, which is distinctly more specific than most calculate_* siblings. It does not, however, name or contrast with the closest siblings such as calculate_chart_from_known_place or compare_conventions, so differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use statement, no named alternative, and no guidance on when a different projection tool is preferable. The only hint of usage is the choice among ayanamsa conventions implied by the enumeration, which the agent must infer.

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 already declare readOnly/idempotent/non-destructive, so the description correctly spends its budget elsewhere: determinism ('never invokes another AI model'), bare-place-name auto-resolution to a curated best-effort match with alternatives noted, and host-dependent interactive rendering. These are real behavioral traits not derivable from annotations, though rate limits or failure modes are unmentioned.

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?

Front-loaded with the imperative purpose, then usage, then return shape, then routing exclusion, then caveats. Dense and mostly waste-free, though the return-value sentence partially duplicates what the output schema already covers.

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 an 11-parameter calculation tool with an output schema and full annotation coverage, the description supplies the key missing behavioral context (determinism, place resolution, host rendering). The gap is parameter semantics: an agent still cannot infer what focus, language, timezoneOffset, or birthTimeAccuracyMinutes do.

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% across 11 parameters, so the description carries the full burden and largely fails. It clarifies only the geo inputs (explicit latitude, longitude, IANA timezone) and place auto-resolution; date/time formats, name, focus, language, timezoneOffset, and birthTimeAccuracyMinutes are left entirely to bare type/pattern constraints.

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 concrete verb+resource ('SHOW THE BIRTH CHART') and enumerates the outputs (Lagna, planet table, Vimshottari, Panchanga, Navamsa), which is specific and agent-actionable. It differentiates from consult_jyotishya but says nothing about how it differs from close siblings like calculate_south_indian_chart or render_chart, which appear to produce overlapping artifacts.

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 trigger ('use when the person wants to see their chart...') and an explicit exclusion with a named alternative ('For interpretation of a question use consult_jyotishya instead'). It does not address when to prefer it over the other chart-producing siblings, so routing is clear only on one axis.

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 already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine context beyond that: it resolves both birth places itself, calculates both charts, returns 'auditable' breakdowns, and explicitly disclaims that results are not a relationship verdict.

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 but purposeful sentences, front-loaded with the action and followed by the scope caveat. No filler, though the second clause packs several concepts that could be split for scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, and annotations carry the safety profile. What remains missing is disambiguation from the marriage-compatibility sibling and any hint about the required inputs, which matters for a nested two-person tool.

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 reported at 0% and the description says nothing about the bride/groom objects, their required date/time, the place-vs-coordinates either/or, or the language parameter. With nested objects and low coverage, the description must compensate for the schema gap and does not.

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?

Names a specific verb (calculates/resolves) and a well-defined resource set: 36-point Ashtakoota, ten-Porutham, and Mangal/Kuja Dosha evidence. The procedure is concrete, but it never distinguishes itself from the close sibling calculate_relationship_compatibility, leaving the agent to guess which marriage-compatibility tool to pick.

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?

'Traditional research preview; never a relationship verdict' frames intent and sets an interpretive boundary, which is useful usage context. However, it gives no when-to-use condition versus the overlapping calculate_relationship_compatibility or calculate_doshas siblings, so routing is only implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about output shape ('period running at asOfIso', 'detail: full returns every level'), but does not explain anything further such as computation scope or failure modes.

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 short, but the leading fragment 'A DASHA SYSTEM.' is not a coherent sentence and does not earn its place, leaving the reader without a clear front-loaded statement of what the tool does. The remainder is densely parenthetical rather than well 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?

An output schema exists, so return values need not be explained. However, for an 11-parameter tool with a non-trivial anyOf location requirement, the description omits how location inputs work and does not clearly delimit its scope against the many calculation siblings.

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 73%, so the schema documents most parameters and the baseline is 3. The description does add meaning beyond the schema for two parameters (the '5 levels' for Vimshottari at asOfIso and the focused/full behavior of detail), but leaves the anyOf location requirement (place vs latitude/longitude/timezone) unaddressed.

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 the fragment 'A DASHA SYSTEM.' rather than a clear verb+resource, so the actual action (calculating a dasha timeline) is only inferable from the title. It lists the supported systems, which helps, but it never states what the tool produces and gives no differentiation from siblings like query_vimshottari_date.

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 choose this tool versus alternatives such as query_vimshottari_date, calculate_jaimini, or calculate_kp. No prerequisites, no when-not conditions, and no mention of the required birth data or location inputs.

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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine behavioral context beyond that: failure handling ('unsupported lineages are withheld'), deterministic tie-breaks ('visible tie-breaks'), and scope limits ('never prescribes initiation-only mantra or claims one uniquely correct deity'). Return format is not described, but an output schema exists, so that is not a 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 sentences, front-loaded with the calculation and method, followed by guarantees. Dense but every clause carries information; the jargon (Rashi Drishti, occupants) is inherent to the domain rather than 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 complex 10-parameter calculation tool, the description adequately covers purpose, failure behavior, and scope guarantees, and an output schema means return values need not be explained. However, it leaves usage routing and most parameter semantics unaddressed, so it is minimum-viable rather than complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 30% across 10 parameters. The description's 'explicit lineage preset' touches the lineage enum, but date, time, name, latitude, longitude, timezoneOffset, and birthTimeAccuracyMinutes carry no meaning in the description. It 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 uses a specific verb ('Calculates') with a precise, distinctive resource set ('Iṣṭa, Dharma, Pālana, Guru and Kula Devatā anchors'), which separates it from generic siblings like analyze_spiritual_path or calculate_jaimini. It also names its method ('occupants, Rashi Drishti, then sign lord'). It stops short of explicitly naming a sibling it displaces, so 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance. The statement 'Unsupported lineages are withheld rather than silently mixed' is a behavioral constraint, not routing advice. An agent gets no signal about when this beats analyze_spiritual_path or analyze_nakshatra_profile.

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 already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that results are evidence-first with raw/effective severity and explicit cancellation/mitigation evidence, which is useful context but describes output content more than 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?

A single front-loaded sentence dense with specific terminology and no filler. Efficient, though the heavy noun stacking borders on jargon that an unfamiliar agent may need to parse carefully.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, with 10 parameters at 30% schema coverage and no usage guidance, the definition leaves the agent under-equipped on how to call it and when it applies.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 30% across 10 parameters, and the description mentions none of them. It does not explain the date/time vs place vs coordinates anyOf requirement, the IANA timezone requirement, or how birthTimeAccuracyMinutes affects results, leaving a significant documentation 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?

Names the specific calculations (Mangal/Kuja, Kaal Sarpa, Kemadruma, Pitru-related structural candidates) with a clear verb, which distinguishes it from siblings like analyze_yogas or analyze_badhaka that handle other chart patterns.

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 on when to select this tool versus alternatives such as analyze_yogas, analyze_badhaka, or calculate_strength_profile. Nothing tells the agent which chart questions this answers or any prerequisite (e.g., a chart must already be computed).

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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuine methodological context beyond that: 'deterministic' and the whole-sign house mapping rule. It still says nothing about input precision requirements or how the transit is scoped, so it is modest rather than rich.

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?

A single front-loaded sentence with no filler; the scope qualifier ('explicit instant') and mapping rule are packed in efficiently. It is appropriately sized, though it is so terse that it leaves no room for the usage guidance the tool needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, but for a 9-parameter tool with 0% schema coverage and a confusingly similar sibling, the description is too thin. It gives no parameter semantics, no invocation example, and no disambiguation from calculate_gochara_from_known_place.

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% across 9 parameters, so the description carries the full burden of explaining them. It gestures at the instant (date/time), place and natal Lagna but omits latitude/longitude/timezoneOffset ranges, the language enum, and the 0-11 sign indexing, leaving most parameters undocumented in both schema and description.

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+resource (calculates transit placements) with two qualifiers: an explicit instant and whole-sign houses from a supplied natal Lagna. An agent can tell this is a gochara/transit calculation. However, it never distinguishes itself from the near-identical sibling calculate_gochara_from_known_place, which is a real ambiguity.

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 when-to-use or when-not-to-use guidance, and no alternatives are named. The phrase 'explicit instant' and 'supplied natal Lagna' hints at the contrast with calculate_gochara_from_known_place, but the agent must infer that distinction itself rather than being told.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the useful pipeline detail that place and IANA timezone are resolved internally before transits are computed, but says nothing about auth, rate limits, or what happens if the place is not found in the catalogue.

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?

A single front-loaded sentence with no wasted words; the key scoping constraint (verified place, avoiding manual entry) leads the sentence. Efficient, though very terse for a 5-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the annotations carry the safety profile. The gap is the undocumented parameters, particularly the required natalLagnaSign, which the description does not address.

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% across 5 parameters. The description only loosely gestures at 'place' and the timezone handling, leaving date, time, language, and especially the required natalLagnaSign (a 0-11 ascendant index) entirely unexplained in both schema and description.

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+resource: it resolves a catalogue place and its IANA timezone, then calculates sidereal transits (gochara). The 'from a verified place' scoping distinguishes it from the sibling calculate_gochara, though it does not name that sibling explicitly.

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 'avoiding manual coordinate and offset entry' implies this is the choice when you have a place name rather than raw coordinates, giving implied usage context. However, it never explicitly names an alternative tool or states a when-not condition.

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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds useful scope context (which grahas are included, future-only interval), but says nothing about how crossings are reported or ordering of results.

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?

A single tight sentence with no filler, and the scoping detail (bodies plus interval) is front-loaded. Nothing needs trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be described, but for a 9-parameter tool with six required fields and zero schema documentation, the description omits any parameter guidance or usage routing. The result is too thin to call the tool confidently without opening the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 9 parameters, and the description compensates for none of them: date, days, place, latitude, longitude, timezoneOffset, timezone and language are all left unexplained. 'Explicit future interval' only loosely gestures at date/days and adds no format, bounds, or coordinate-system detail.

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 (finds sign-boundary crossings), names the exact bodies covered (Sun through Saturn and the lunar nodes), and the temporal scope (explicit future interval). It does not, however, distinguish itself from close siblings such as build_slow_transit_calendar or calculate_gochara, which also deal with planetary movement over time.

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 when-to-use guidance, no exclusions, and no naming of alternatives. The phrase 'explicit future interval' implies a forward-looking constraint but never states that past dates are rejected or when another transit tool would be preferable.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds one genuinely useful behavioral note — that conventions are not silently mixed — but says nothing about input requirements or error handling beyond that.

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?

A single dense sentence, appropriately front-loaded with the key outputs. It is list-heavy but every clause names a distinct deliverable, so little 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?

An output schema exists, so describing return contents is partly redundant, and the description leans on that rather than on usage or parameter guidance. For a 10-parameter, low-coverage tool it should say more about inputs and when to prefer it over overlapping siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 30% across 10 parameters, so the description carries the burden but adds nothing about parameters. It does not explain the place-vs-coordinates branch, the timezone requirement, or birthTimeAccuracyMinutes, leaving the agent to rely on sparse schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names specific Jaimini resources (Chara Karakas, Arudha Padas, Karakamsha, Rashi Drishti matrices), so the agent knows what the tool produces. However, it does not distinguish itself from the overlapping sibling analyze_arudha_and_upapada, which also covers Arudha Padas, so differentiation is missing.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. Given siblings like analyze_arudha_and_upapada and compare_conventions that overlap with this tool's outputs, the absence of routing guidance is a real gap.

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