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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the source (BPHS Ch.66 vv.13-68) and explicitly stating that Trikona/Ekadhipatya Shodhana and Pinda Sadhana are not included, which sets accurate expectations for the output. No contradiction with 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?

Three short sentences with no filler: the main function is stated first, the source is given second, and the important exclusions are last. Every sentence contributes meaningful 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?

The tool is read-only, has an output schema, and all 8 required input parameters are fully documented. The description covers the core computation, scope, and limitations. The only minor ambiguity is the relationship between 'all 7 planets' and the required lagna parameter, which is not fully explained, but this is a small gap given the otherwise strong structured metadata.

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 100%, and every parameter already has a clear meaning: sign index with 0=Aries through 11=Pisces. The description reinforces the 'sign positions' basis but adds no new parameter-level detail beyond what the schema provides, so the baseline score of 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?

The description states a specific verb ('Compute'), a specific resource ('Bhinna Ashtakavarga' raw bindu tables and 'Sarvashtakavarga'), and the input basis ('from sign positions'). It is clearly distinguishable from the sibling compute_* tools by naming a unique astrological domain and clarifying what is not included.

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

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

The description gives no explicit guidance about when to use this tool versus alternatives like compute_shadbala, compute_dasha, or compute_gochara. The exclusions tell the agent what the computation does not include, but they do not help an agent decide when this tool is the right choice.

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

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

With only readOnlyHint available, the description carries the burden of explaining the computation's behavioral traits. It does this well by describing the whole-sign rule, the classification output, and optional graha placement. There is no contradiction with the read-only annotation.

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 deliver the core purpose, the computational rule, the return contents, and the optional planet behavior. There is no filler, and the main verb is front-loaded.

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

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

Given the small parameter count, the presence of an output schema, and the read-only annotation, the description is fully sufficient for correct invocation. It covers inputs, computation rule, returned data, and optional behavior without leaving important gaps.

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

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

Schema description coverage is 100%, and both parameters are already well documented in the schema. The tool description adds little beyond restating sidereal longitude and the optional planet map, so it meets the baseline but does not substantially exceed what the schema already provides.

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

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

The description uses a specific verb and resource: 'Compute the whole-sign bhava (house) chart from an ascendant.' It also differentiates the tool from cusp-based systems by stating that 'houses do not have cusps within signs,' making the purpose unmistakable.

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

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

The description implies when to use the tool: whenever a whole-sign bhava chart is needed from an ascendant. However, it does not explicitly name sibling alternatives like compute_natal_chart or compute_vargas, nor does it state when this tool should not be used. The context is clear but the exclusion guidance is missing.

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, but the description adds useful behavior beyond that: it returns specific category strings ('Combust', 'DeeplyCombust', 'None'), reports degrees of separation, and clarifies that the tool consumes already-computed positions rather than computing a chart. This is meaningful context beyond the structured 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 description is compact and front-loaded: the first sentence gives the core purpose and outputs, and the following sentences provide essential workflow guidance. There is no filler or redundant restatement of the tool name.

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

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

Given the detailed input schema, output schema, and readOnly annotation, the description is complete: it identifies the prerequisite tool, the exact data source for parameters, the output categories, and the intended pipeline. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so the schema carries most parameter documentation. The description adds value by framing all inputs as a single pass-through from compute_natal_chart's planets[] entries matched by name, and by explicitly prohibiting recomputation or re-derivation. This helps the agent understand the intended data flow beyond the individual parameter descriptions.

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

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

The description states a specific verb ('Compute'), a specific resource ('combustion state for each planet relative to the Sun'), and names the exact output categories and planet set. It clearly differentiates itself from compute_natal_chart by calling itself a low-level tool over already-known positions.

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

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

The description explicitly says to call compute_natal_chart first and pass its longitude/retrograde values straight through, and explicitly warns not to recompute or re-derive them. It also states when this tool is NOT appropriate ('not a natal-chart tool'), giving clear pipeline 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?

Beyond the readOnlyHint annotation, the description discloses important behavioral details: grahas are paired by namesake rather than list position, a name present in one chart but not the other produces an error naming that graha, and the tool ignores everything except longitudes and speeds. This gives an agent accurate expectations about failure modes and matching semantics.

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 three sentences, front-loads the core computation, and each sentence adds essential information: what is computed, matching/error semantics, and data requirements. There is no filler or repetition of schema content.

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

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

Given the output schema, input schema, and annotations, the description covers the remaining essentials: prerequisite chart-name identity, error behavior, and what inputs are ignored. An agent can correctly select and invoke the tool with the information provided.

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

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

The input schema already documents chart_a, chart_b, longitude, and speed with 100% coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema by clarifying that chart_a and chart_b must contain exactly the same graha names and that matching is by name, not position. This raises it above baseline.

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 operation, 'compute the midpoint composite chart of two charts,' and defines exactly what is computed: shorter-arc longitude midpoints and arithmetic mean speeds. This clearly distinguishes it from sibling computational tools like compute_synastry or compute_transit.

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

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

The description gives clear context on when the tool applies: it works on two charts with matching graha names and needs only longitudes, not birth time/place/ephemeris. It does not explicitly name alternative tools or state when not to use it, so it stops just short of full routing guidance.

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

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

Annotations already provide readOnlyHint=true, and the description goes beyond that with substantial behavioral detail: it returns a JSON dasha tree with start/end Julian Days, clarifies that the epoch is UT1 and never converted, explains Ketu is derived from Rahu, and documents a historical indexing mismatch. No contradictions with 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 description is long but dense with necessary information for a tool with two distinct parameter families and five dasha systems. It front-loads the purpose and then organizes requirements by system. A few points are repeated from the schema, but there is no filler.

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

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

Given the tool's complexity — multiple systems, conditional parameters, nested objects, and a shared convention with compute_natal_chart — the description is complete. It covers prerequisites, parameter sourcing, output shape, time-scale behavior, and edge-case conventions. The presence of an output schema also reduces the burden of explaining return structure.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaningful semantics: it ties each parameter to specific dasha systems, explains the sign-to-lord period counting rule for Chara and Narayana, and warns that Ketu must not be supplied. Some detail is duplicated from the schema, but the added cross-system relationships still earn credit.

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

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

The description opens with a specific verb and resource ('Compute Vedic dasha (planetary period) sequences') and immediately enumerates the five supported systems. It differentiates the tool from generic astrology tools by explaining that it handles multiple dasha systems with distinct input requirements.

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

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

The description gives explicit input-requirement conditions: Yogini needs moon_longitude; Chara and Narayana need both lagna_sign and graha_signs. It also tells the agent where to source these values (compute_natal_chart's sign_index). It does not explicitly contrast with sibling tools, but for this tool's own selection logic the guidance is strong.

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 signal readOnlyHint=true; the description adds substantial behavioral detail beyond that: every graha aspects the 7th, Mars/Jupiter/Saturn have extra aspects, and the output includes graded strength and house distance. This gives a clear model of what happens when the tool is invoked.

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

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

The description is compact and front-loaded: it states the operation and scope first, then presents the key asymmetric rules and output shape. Every sentence contributes useful information with no filler.

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

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

Given the read-only annotation, complete parameter schema, and output schema, the description supplies the remaining essential context: the Vedic drishti model, special aspect rules, and returned strength/distance values. An agent has enough information to select and call this tool correctly.

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

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

Schema description coverage is 100% and every parameter is documented with the same format and range, so the description does not need to add much. The phrase 'for all nine grahas' maps to the required parameters but adds no semantic detail beyond the schema.

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

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

The description clearly states the operation: 'Compute graha drishti — Vedic sign aspects — for all nine grahas,' giving a specific verb, resource, and full scope. It differentiates from Western aspects and lists the unusual aspect rules, but it does not explicitly name or distinguish a sibling tool.

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

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

It provides clear usage context by explaining that drishti is sign-to-sign, asymmetric, and has special extra aspects for Mars, Jupiter, and Saturn, while contrasting with Western aspects. However, it never names an alternative tool or states a when-not-to-use condition, so it lacks explicit routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds useful behavioral context: the BPHS Ch.29 basis, the output items (favourable/unfavourable verdict, house from natal, raw vedha candidates), and the exclusion of Rahu/Ketu. There is no contradiction with 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?

Three sentences with no filler: purpose, output, and usage context are each stated once and front-loaded. Every sentence earns its place.

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

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

The description is sufficient for an agent to select and invoke the tool correctly given the rich schema and output schema. It supplies the missing domain context (BPHS Ch.29, seven grahas, natal reference choice, node exclusion) while the schema covers parameter mechanics and the output schema covers return structure.

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

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

Schema description coverage is 100%, so the schema already documents all parameters including the two enums. The description's natal-reference guidance (Moon vs Lagna) largely duplicates the natal_reference_sign schema description. It adds minimal extra parameter meaning beyond what the schema already provides.

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

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

The description uses a specific verb and resource: 'Compute Gochara (transit interpretation) for the seven grahas against a natal reference sign per BPHS Ch.29.' It also differentiates this tool from siblings like compute_transit by naming Gochara, the seven-planet scope, and the natal reference sign. The explicit exclusion of Rahu and Ketu further sharpens the tool's identity.

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

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

It gives clear operational context: the caller chooses the natal reference sign, typically Moon (Chandra Gochara) or Lagna. It also states a when-not condition by saying Rahu and Ketu are not included. However, it never names a sibling alternative such as compute_transit or search_transits, so it stops short of fully explicit routing guidance.

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

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

The readOnlyHint annotation already signals a safe read operation, and the description adds substantive behavioral detail: planets are ranked by degrees within their sign, highest is Atmakaraka, lowest is Darakaraka, and the 7- vs 8-karaka schemes differ by the inclusion of Rahu. This goes beyond the annotation without contradicting it, though tie-breaking or edge-case behavior is not covered.

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

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

Three tight sentences front-load the purpose, follow with the ranking rule, and end with scheme options. There is no filler and no repetition of schema content.

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 pure computation tool with readOnlyHint, a fully described schema, and an output schema, the description supplies the core algorithm and scheme semantics needed for correct invocation. It omits minor nuances like the Pitrikaraka label in scheme 8 or tie-breaking rules, but these are either captured in the schema or not essential to selecting and calling the 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?

The input schema already documents all nine parameters with descriptions, so the baseline is 3. The description earns extra credit by explaining that longitudes are 'sidereal', that ranking uses degrees within the current sign, and that Rahu is the additional body for scheme 8 – giving meaning to the parameter values rather than merely naming them.

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 specific verb 'Compute' and the resource 'Jaimini Chara Karaka assignments', then anchors the computation to sidereal longitudes and rank-by-degree logic. This clearly differentiates the tool from sibling compute_* tools such as compute_natal_chart or compute_dasha, even though it never names 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?

It states the exact scope of the tool: computing Chara Karaka assignments and supporting two schemes, which implicitly tells an agent this is the karaka-specific tool among many compute siblings. However, it does not explicitly mention when not to use it or name alternative tools, so routing guidance is slightly incomplete.

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?

The description confirms this is a read-only computation that returns a JSON ChartGraph, which complements the readOnlyHint annotation. It does not discuss edge cases, precision limits, or failure modes, but with annotations already covering side effects, the added return-type context is adequate but not exceptional.

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

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

The description is two short, front-loaded sentences with no filler. The action is stated first, and the return-value summary earns its place without duplicating 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?

The combination of a rich input schema, an available output schema, and the readOnlyHint means the agent has enough structure to select and invoke the tool correctly. The description states purpose and output, while the schema handles detailed inputs and return shape. A brief routing note against sibling compute_* tools would improve completeness but is not essential.

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?

All five parameters are thoroughly described in the input schema, including the important UT1-vs-TT warning for julian_day and detailed ayanamsha system definitions. At 100% schema description coverage, the baseline of 3 is appropriate, and the prose description's 'time and location' phrasing adds no new parameter-level meaning.

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

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

The description opens with a specific verb, 'Compute', and names the exact resource, 'natal astrological chart', along with the required time and location context. It also summarizes the returned ChartGraph contents, which clarifies the tool's scope. It does not explicitly contrast the tool with siblings like compute_transit or compute_bhavas, so it stops short of a top score.

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 'for a given time and location' states a clear usage context: use this tool when a natal chart is needed for specific inputs. It does not list exclusions or direct the agent to alternatives such as compute_transit or compute_bhavas, but the context is explicit enough to guide basic 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?

Beyond the readOnlyHint annotation, the description reveals non-obvious behavioral details: the vara reckoning mechanic, the civil-weekday fallback when no sunrise exists, and the important distinction between a null rahu_kalam and from_sunrise being false. It also specifies the UT1 time scale and the ΔT sensitivity near sunrise, which are critical and undocumented elsewhere. This is exactly the kind of context 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 description is front-loaded with the core purpose and becomes more detailed only where needed for edge cases. Every sentence carries information, and the length is justified by the genuine complexity of the vara and rahu_kalam behavior. It could be tightened slightly, but it remains highly efficient.

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

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

The description covers time-scale conventions, the polar fallback, the null-window distinction, and even warns to pass the same elevation_m as search_muhurta for consistency. With an output schema present, nothing an agent needs to invoke this tool correctly is missing. It is fully complete for the tool's 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?

The input schema covers 100% of the 7 parameters with already-thorough descriptions, including jd time-scale warnings and elevation's effect on sunrise. The main description reinforces that inputs are sidereal longitudes and outputs are in Julian Days (UT), but adds little parameter-level meaning beyond the schema. A baseline 3 is appropriate since the schema carries the load.

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

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

The description opens with a specific verb 'Compute' and a precise resource, 'the panchanga — the five limbs of the Vedic almanac — for an instant', then enumerates all five limbs (tithi, vara, nakshatra, yoga, karana). This distinguishes it clearly from sibling computation tools like compute_natal_chart or compute_dasha. No ambiguity remains about what the tool does.

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

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

The description provides clear operational context: it works on a single instant from sidereal longitudes, returns Julian Days (UT), and explains the polar-day/night fallback for vara at high latitude. It also warns to check vara.from_sunrise before presenting the weekday at high latitude. It does not explicitly name alternative tools, but the context is sufficient for correct use.

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?

Beyond the readOnlyHint annotation, the description discloses important behavioral details: which sub-components are included, which are deliberately omitted, and the limited scope of Kala Bala. This prevents the agent from assuming a full traditional Shadbala calculation and adds real decision-relevant information.

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, front-loaded sentences convey the full scope, inclusions, and exclusions without redundancies. Every clause earns its place, and the most important identifier ('six-fold Shadbala') appears first.

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

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

Given the rich input schema, readOnly annotation, and presence of an output schema, the description is complete enough for an agent to invoke the tool correctly. It explicitly calls out the calculation source and the specific omissions that would otherwise be surprises.

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

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

The input schema already provides 100% coverage with per-parameter descriptions explaining which Bala each field drives. The description adds domain-level context about components, but it does not add meaningful new parameter semantics beyond what the schema documents, so 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?

The description uses a specific verb ('Compute') and resource ('six-fold Shadbala'), enumerates all six components, and identifies the source (BPHS Ch.27-28). This clearly distinguishes it from siblings like compute_drishti or compute_ashtakavarga by naming a distinct astrological computation.

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

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

The description gives clear context about what the computation covers and its explicit limitations, such as Sthana Bala omitting Saptavargaja and Kala Bala covering Nathonnatha and Paksha only. It does not explicitly name alternative sibling tools or state when not to use this tool, but the scope is clear enough for an agent to route a Shadbala request here.

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?

The description discloses detailed behavior beyond the readOnlyHint annotation: every graha in chart A is tested against every graha in chart B, hits include aspect type/orb/strength, strength falls linearly from 1.0 to 0.0, and orbs follow Lilly values scaled by orb_factor. This gives the agent a precise model of what the tool will do.

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 dense sentences: the first states the core purpose, the second details the algorithm and output, and the third states the input prerequisites. Every sentence carries necessary information without repetition or 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 tool with four parameters, two of which are nested objects, the description covers the algorithm, the output shape, orb conventions, scaling behavior, and the minimal input requirements. The presence of an output schema further reduces the need to document return values, so nothing essential is missing.

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

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

The input schema already provides 100% parameter coverage, so the baseline is 3. The description adds meaningful semantic detail beyond the schema by explaining the orb values, orb_factor scaling, and strength formula, which clarifies how orb_factor changes results.

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

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

The description states a specific verb and resource: compute synastry aspects between two charts, with the precise cross-testing model. It clearly distinguishes this from siblings like compute_composite or compute_drishti by describing exactly what the tool computes.

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

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

The description gives clear context for when this tool is appropriate: comparing two charts by longitude only, with no need for birth time, place, or ephemeris. It does not explicitly name alternatives or exclusion conditions, but the scope is unambiguous.

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

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

Annotations already carry the safety profile (readOnlyHint=true), lowering the burden. The description adds useful framing by disclosing that the result contains both transit and natal longitudes for aspect work. It does not go deeper into edge behaviors (e.g., invalid date handling, planet set included, precision), which is acceptable but not rich given the annotation coverage.

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

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

Two sentences with zero waste: the first commits to the computation, the second to the return shape and purpose. Front-loaded and maximally signal-dense — every sentence earns its place.

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

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

With 100% parameter coverage, a rich output schema, and read-only annotations, the description covers what is computed, relative to what, and for what purpose. The only gap is that the roles of natal_lat/natal_lon in a transit computation are left to the schema, which documents their units but not their algorithmic function. Still, an agent can select and invoke the tool correctly.

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

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

Schema description coverage is 100% — all four parameters (natal_jd, natal_lat, natal_lon, transit_jd) have detailed unit/format guidance, including the UT1-vs-TT distinction. The tool description adds no parameter-level detail beyond the schema, 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 ('compute') and resource ('transiting planet positions relative to a natal chart at a specific moment'), then specifies the output shape (transit longitudes alongside natal positions). The scope is unambiguous enough to distinguish it from compute_natal_chart (natal only), compute_synastry (two-person comparison), and compute_gochara, without opening any 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?

The use case is implied via 'enabling aspect calculation between transit and natal placements,' which gives clear context. However, it never explicitly routes the agent away from domain-overlapping siblings like compute_gochara (also transit-related) or search_transits (searching transits), so when-to-use vs alternatives is left to inference.

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?

Beyond the readOnlyHint annotation, the description discloses important traits: Ketu is not listed separately because it is the node's opposite point, nodes carry no dignity so that field is absent, and the planet_longitude mode returns no graha name, dignity, or bhava. These are not visible in the annotations and are essential for correct interpretation.

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

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

The description is dense but not bloated, front-loading the purpose and then proceeding through output details, edge cases, and default behavior. Every sentence adds value, and the source citation is a compact closing detail.

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

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

Given the output schema exists and readOnlyHint is set, the description covers the critical edge cases: Ketu omission, node dignity absence, the planet_longitude mode, and the ayanamsha default. No essential behavioral detail for invoking the tool correctly 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 coverage is 100%, so the baseline is 3. The description adds useful parameter context not in the schema: the Tropical default ayanamsha and the specific body set from compute_natal_chart. It does not add much beyond the schema's already-detailed planet_longitude explanation.

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

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

The description opens with a specific verb and resource: 'Compute Vedic divisional charts (vargas).' It then details the exact output per division—varga lagna, rashi longitude, sign, dignity, bhava—and references the ten bodies from compute_natal_chart, which distinguishes this tool from its sibling.

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

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

It gives clear context by describing the standard time-and-place mode and the alternate planet_longitude mode for dividing a single longitude without an ephemeris lookup. It also mentions the Tropical default. However, it never explicitly states when to choose this tool over other chart-related siblings like compute_bhavas.

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?

The readOnlyHint annotation already signals non-mutating behavior, and the description adds meaningful behavioral context: it converts chart data into a property graph, accepts both raw compute_natal_chart output and pre-built ChartGraph objects, and produces multiple named formats. It also notes latitude/longitude are ignored for existing ChartGraph instances, which is useful 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 sentences with no redundant phrasing. The core action is front-loaded, and the input forms and output formats are compactly enumerated without wasting tokens.

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

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

The description, combined with the 100% schema coverage, covers the essential invocation details: required inputs, conditional coordinate requirements, accepted input forms, and output format options. The main gap is the lack of an output schema or explicit note about how the emitted text is returned, but the listed formats make the behavior sufficiently predictable.

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 100%, so the schema already documents each parameter well. The description adds value by clarifying the relationship between chart_json and latitude/longitude, noting that computed charts require coordinates while existing ChartGraphs do not, and naming compute_natal_chart as the direct source of chart_json. This goes beyond the schema's individual parameter descriptions.

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

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

The description uses a specific verb and resource: 'Turn a chart into a queryable property graph.' It lists concrete output formats (Cypher, SurrealQL, JSON-LD, JSON, RAG embedding text) and names compute_natal_chart as the upstream input, making it easy to distinguish from sibling compute_* tools.

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

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

The description clearly indicates when to use the tool: when you have a computed chart or an existing ChartGraph and need a queryable graph format. It also explains the coordinate requirement for computed charts. It does not explicitly say 'use this instead of compute_* for graph output,' but the context is unambiguous enough.

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?

Beyond the readOnlyHint annotation, the description discloses significant behavioral traits: the computational cost and why the range is capped, the internal refinement steps (per-candidate vara and tithi/nakshatra refinement), and the existence of a specific error code (MUHURTA_SEARCH_RANGE_TOO_LARGE). It also mentions time-scale consistency (UT1 vs TT) and cross-tool consistency expectations (elevation value matching compute_panchanga) in the schema. This is rich behavioral context that helps agents anticipate performance and 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?

Two sentences with no wasted words. The first sentence front-loads purpose and output; the second delivers the critical constraint and cost warning. Every part earns its place, and the error code reference is compact.

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 7-parameter tool with a full output schema and read-only annotations, the description covers the essential usage context: what it searches, what it returns, and the key operational constraint (30-day cap, cost). The schema covers parameter details. It falls slightly short of 5 because it never explicitly positions the tool against siblings like search_transits or compute_panchanga beyond the generic 'transit search' cost comparison, and an agent might still be unsure about selection criteria among these similar astronomical 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining why the start_jd/end_jd span is capped at 30 days and the cost implications of the per-candidate refinement. This rationale is genuinely useful for parameter understanding and invocation, lifting the score above baseline. However, individual parameter meanings are almost entirely left to the schema, which is already thorough.

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 ('Search') and resource ('auspicious time windows (muhurta)') with explicit context: within a period for a geographic location. It also lists what the tool returns (ranked candidates with quality scores based on tithi, nakshatra, yoga, karana, and planetary positions). It further distinguishes itself from 'a transit search' by cost, which both identifies the sibling category and clarifies its unique role.

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

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

The description gives clear context for when to use the tool (searching muhurta windows) and provides a strong cost-based constraint: the 30-day cap and the warning that wider spans make calls take minutes. It implicitly differentiates from the sibling search_transits by calling out the per-day expense relative to a transit search, but it does not explicitly say 'use this for muhurta, use search_transits for transit positions' or name alternatives such as compute_panchanga.

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?

The description discloses that the tool returns exact transit moments with aspect type, orb, and applying/separating status, adding behavioral detail beyond the readOnlyHint annotation. It does not mention limitations such as search range size or whether bodies/aspects default to all/major, but those are covered in schema. No contradiction with 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 sentences with no redundant words; the subject-action-object structure is front-loaded and immediately legible. Every clause contributes either the input requirement or the expected output.

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

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

Given the 6-parameter schema with 100% coverage, detailed parameter descriptions, and an output schema, the description is sufficient to orient an agent. It omits explicit alternative routing, but the time-window focus and 'search' verb are enough to select this tool among 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 100%, so the baseline is 3; the schema already richly documents each parameter (e.g., UT1 vs TT conversion in start_jd). The tool description itself only mentions natal positions and a Julian Day range, which maps to required params but adds no extra meaning not already in the schema.

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

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

The description states a specific action ('Search for') on a well-defined resource ('transiting planet–natal planet aspects') within a bounded time window. This clearly differentiates it from siblings like compute_transit, which would calculate a single transit, and compute_gochara, which returns current positions.

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

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

The description clearly implies usage context: when an agent has natal positions and needs a list of aspect events over a Julian Day range. However, it does not explicitly state when to prefer this over alternatives like compute_transit for a single moment or search_muhurta for electional timing, so no exclusions are provided.

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