Trikaal Vaani Jyotish

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds the behavioral fact that output is derived from the Moon nakshatra and pada, which is useful but thin. It says nothing about computational determinism, required birth-time precision, or what the response contains beyond syllables and meanings.

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 waste, and the core output concepts (syllable, suggestions, meanings) come first. It is arguably too terse for eight parameters, but nothing is padded or redundant.

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

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

With no output schema, the description usefully sketches the return (syllable, name suggestions, meanings), which is its main contribution. However, for an 8-parameter birth-chart tool it omits when to use it, how precise the birth time must be, and how name/place are treated (the schema says display-only, but the description doesn't reinforce the derivation logic). Adequate but with clear gaps.

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

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

Schema description coverage is 88%, so the schema already documents date, time, latitude, longitude, timezone, gender and name conventions, including the 12:00 fallback for unknown birth time. The description mentions nakshatra and pada conceptually but adds no parameter-level syntax or format detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 resource and output: the lucky starting syllable (naamakshar) derived from the Moon nakshatra and pada, plus name suggestions and meanings. It is a noun phrase rather than a verb+resource construction, but an agent can still tell it apart from siblings like numerology or janam_kundali. Sibling differentiation is implicit 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?

There is no when-to-use guidance, no prerequisites, and no reference to any alternative tool. An agent must infer that this is for naming a newborn from Vedic astrology, and nothing routes it away from numerology or janam_kundali.

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 read-only/idempotent/closed-world profile, and the description adds real behavioral value beyond them: the result is gated to the first hour of the window for free users, the full-window answer lives in the paid report, and it will never return a time outside the doctor window. It stops short of describing error cases or the response shape for the paid path.

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-loaded with the core purpose, then the free/paid behavior, then the hard constraint. 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?

With no output schema, the description steps up and names what the free view returns (Lagna, Nakshatra, quality label) and what is paywalled, plus the window constraint. Only the three undocumented numeric params remain 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 50% (latitude, longitude, timezone are undocumented), so the description carries part of the burden. It clarifies the window concept ('doctor-approved window') and the date scope, but adds no format or default detail for the three bare numeric params.

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 ('Best delivery / C-section time') and scopes it precisely ('inside the doctor-approved window on a given date'), which cleanly separates it from the marriage/shubh muhurat siblings. An agent can identify this tool without opening the 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?

Gives useful context about the free tier (best slot only in the first hour) versus the paid report, but never names an alternative tool or states when to prefer e.g. shubh_muhurat or vivah_muhurat. Usage is implied rather than spelled out.

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 behavioral value beyond that by disclosing the returned content (current Mahadasha/Antardasha plus the full sequence) and the computation basis (BPHS Ch.46-49, Swiss Ephemeris), which signals deterministic, classical-rule-based output rather than generative text.

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 no filler; the scope of returned data is front-loaded and the provenance/methodology is appended as a short clause. Nothing can be removed without losing 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?

With no output schema, the description bears the burden of describing returns, and it does so by listing the three data sets produced. Combined with a fully documented 7-parameter schema and complete annotations, an agent has what it needs; only the exact response shape (nesting/format of the period list) remains unspecified.

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%, including patterns, ranges and the helpful note that 12:00 is conventional when birth time is unknown, so the schema carries parameter semantics entirely. The description adds nothing about date/time/lat/long inputs, 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?

The description names a specific domain resource (Vimshottari Mahadasha/Antardasha timeline) and enumerates exactly what it produces: current periods, all Antardashas of the running Mahadasha, and the full Mahadasha sequence. This is clearly distinct from siblings like kundali_milan or panchang_today. It stops short of naming a sibling it replaces or contrasting with any related timing tool, so it does not reach a 5.

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

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

There is no explicit when-to-use statement, no prerequisite (e.g. that a birth date/time/place is required), and no alternative tool named for related queries. The agent must infer applicability purely from the term 'Vimshottari Dasha', which is specialized domain vocabulary.

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 modest behavioral value by disclosing what the result contains (Manglik house details and cancellation conditions), but says nothing about permissions, determinism of results, or response shape beyond 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 first sentence is front-loaded and dense with useful enumeration. The second — 'Trikaal Vaani, Swiss Ephemeris' — is a branding/vendor tag that gives an agent no actionable selection or invocation information and dilutes conciseness.

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 7 parameters and no output schema, the description is adequate on inputs (schema covers them) but thin on what the agent gets back — only a hint about Manglik house details and cancellation conditions. For a specialized astrology computation with no output schema, more about the result structure would help.

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% across all 7 parameters, including units, ranges and the 12:00-default convention for unknown birth time, so the schema does the heavy lifting. The description contributes no additional parameter meaning, which is the baseline case.

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 (Checks) and resource (dosha) and enumerates the exact doshas covered — Kaal Sarp, Pitra, Guru Chandal, Grahan, Mangal/Manglik — plus the extras returned (house details, cancellation conditions). That is far more specific than siblings like yog_check or weak_planet, though it never explicitly positions itself against them and the trailing vendor string adds no clarity.

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

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

Usage is only implied: an agent can infer this is called with birth data when dosha analysis is wanted, but there is no when-to-use/when-not-to-use statement and no pointer to alternatives such as janam_kundali (full chart) or yog_check (yogas). With 21 siblings, 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.

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. The description adds no behavioral details beyond those annotations, such as response shape or static/cached nature, but it does clarify that the output is a catalog of offerings, so it is minimally adequate.

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 what the tool does in the first clause, and the enumeration is dense but purposeful. It could be more scannable as a bulleted list, but no sentence is wasted.

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

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

For a zero-parameter read-only catalog with no output schema, the description enumerates all offerings and mentions prices and where to buy, which is enough for an agent to answer user queries. It omits return structure details, but those are simple enough to infer.

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

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

The tool has zero input parameters, so there are no parameter semantics for the description to clarify. The rubric's baseline for no parameters is 4.

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?

Starts with 'Lists' and names the specific resource: Trikaal Vaani's paid reports and consultations. The enumeration of offerings clearly distinguishes it from sibling calculation tools such as janam_kundali or kundali_milan.

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

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

The description implies use when a user asks about paid reports or consultations, but it never states when to choose this tool versus siblings or that it requires no input. Usage is inferable from the content but not explicitly guided.

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 local (openWorldHint=false). The description adds real value beyond them: the exact scoring factors, the shape of the output (wear verdict + reason, lagna-lord life stone), the full stone list, and the commercial-neutrality disclosure. It stops short of detailing the return structure or edge cases for missing birth time, so not a 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?

Two dense sentences, front-loaded with the core action and score range, then the deliverables and the stone list. No filler; every clause carries 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?

With no output schema, the description steps in to describe the return shape (per-stone score, verdict, reason, lagna-lord life stone), which is what the agent needs. It is close to complete, though the handling of unknown birth time or the optional single-stone filter is not addressed.

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% with all 8 parameters documented in-schema, so the baseline is 3. The description adds nothing about parameter syntax or how inputs like the optional 'stone' filter interact with the scoring, leaving semantics 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?

States a precise verb (Scores) and resource (all 9 gemstones 0-100) with scope and methodology (functional benefic, Shadbala, dignity, afflictions) plus the verdict it returns. No sibling tool covers gemstones, so the agent can uniquely identify this one.

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

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

Usage is implied ('for this exact chart', requiring birth data) but the description never states when to pick this over the birth-chart siblings like janam_kundali, kundali_strength, or planet_strength, nor any exclusions. The only disambiguation is the closing note that it sells no gemstones, which clarifies intent rather than 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 declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful methodological context (Swiss Ephemeris, Lahiri ayanamsa) and output scope, but does not describe validation failures, timezone caveats, or response behavior beyond 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 front-loaded and compact: it names the chart, lists major outputs, then names the ephemeris method. It is dense but not wasteful, with no filler sentences.

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?

No output schema exists, so the description appropriately lists the returned chart components rather than explaining values. With annotations covering safety and the schema fully documenting inputs, the definition is largely complete, though it lacks usage-routing guidance for the crowded astrology sibling set.

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 all seven parameters are already documented in the input schema. The description adds no additional parameter meaning, leaving the schema to carry the full weight.

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

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

The description clearly identifies the tool as a Vedic birth chart generator and enumerates the main outputs: Lagna, Rashi, Nakshatra/pada, all 9 grahas, and Mahadasha/Antardasha. It is specific about the resource, though it does not explicitly contrast itself with siblings such as dasha_timeline or kundali_strength.

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 guidance, no prerequisites, and no named alternatives among the many astrology siblings. The purpose implies usage, but an agent receives no routing information to distinguish this full birth-chart tool from specialized tools like kundali_strength or dasha_timeline.

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 value the annotations cannot: it discloses what the computation returns (koota-wise scores and dosha checks) and the free-tier boundary versus a paid report elsewhere, which is useful scoping 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?

Two short sentences, front-loaded with the technique and scoring scheme, followed by the access/tier note. No filler, and the most decision-relevant information (what it computes) comes 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?

With no output schema, the description responsibly sketches the return (koota-wise scores plus dosha checks) and notes the free/paid split. Combined with a fully documented nested input schema, an agent has enough to call it correctly, though a hint at input granularity or result format would make it airtight.

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% with fully documented nested bride/groom objects (date, time, lat/long, timezone defaults), so the schema carries all parameter meaning. The description adds no syntax or format detail beyond naming the two parties, making the baseline 3 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 technique and scope: 'Ashtakoot Guna Milan (36 points)' for a bride and groom, with koota-wise scores and dosha checks. That is a precise verb+resource far beyond restating the title. It does not, however, explicitly differentiate itself from siblings like dosha_check or vivah_muhurat, so it stops short of a 5.

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

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

The marriage-matching context is implied by 'bride and groom' and the sibling set, but no explicit when-to-use or when-not guidance is given. The only routing statement ('detailed compatibility report with remedies is on Trikaal Vaani') points to an external product, not to an alternative tool in this server, so it does not serve as sibling-selection 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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds useful analytical context (the Shadbala/classical-minimum methodology and the metrics computed) but says nothing about cost, latency, or failure modes, so it is a modest increment over 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?

One front-loaded sentence with no filler; the core noun ('overall birth-chart strength score') leads and the supporting metrics follow. It is dense but readable, and nothing is redundant.

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

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

There is no output schema, so the description carries the return-value burden and does so by enumerating score, grade, strong-planet count, and ranking. Combined with fully documented input params and complete annotations, an agent has enough to call and interpret it, with only the usage-routing gap remaining.

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 all 7 parameters (including the note that 12:00 is the conventional unknown-time value and the India=5.5 timezone default) are already documented. The description adds no parameter meaning beyond reusing the concept of 'grahas', 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 concrete resource ('overall birth-chart strength') and spells out exactly what the calculation yields: Shadbala average versus classical minimum across 7 grahas, grade, strong-planet count, and ranking. It implicitly contrasts with siblings like planet_strength and lagna_bal via the word 'overall', though it never names an alternative.

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 prefer this tool over planet_strength, lagna_bal, or janam_kundali, and no prerequisites or exclusions stated. The agent must infer usage purely from the tool name and the sibling list.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds output semantics such as the Shadbala ratio and Strong/Moderate/Weak label, but no additional behavioral caveats like computation source, timing, or auth requirements.

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 a precise list of returned elements. Every clause names useful output content, with no filler or repetition.

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

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

There is no output schema, so the description carries the burden of explaining return values and does so by enumerating the result components. Parameters are covered by the schema and annotations cover safety, making this mostly complete, though output formatting details remain unstated.

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 birth date, time, coordinates, and optional name/place/timezone are already documented in the schema. The description adds no parameter syntax or meaning beyond what the schema provides, which is the expected 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?

States the specific astrological resource: the Ascendant (lagna) lord, and enumerates its outputs including house, strength, Shadbala ratio, Strong/Moderate/Weak label, house meaning, and planets in the 1st house. This clearly separates it from general planet-strength siblings, though it lacks an explicit verb and does not name alternatives.

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 guidance is given, and no alternatives such as planet_strength or kundali_strength are mentioned. Usage is only implied by the tool name and description.

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 genuinely useful context beyond that — the reading is text-sourced ('no AI writing') and access is tiered ('free view; full Rs 51 reading') — implying the default response is a partial/preview output, but it does not specify what that preview contains or any error behavior.

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

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

Front-loads the core purpose before the long topic list. The topic enumeration is dense but justified since it enumerates the enum values; the closing pricing sentence is a separate, useful clause rather than padding.

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 9 parameters, 5 required, no output schema and no nested objects, the description should carry more of the return-value burden. It hints that the default is a limited free view versus a fuller paid reading, but never states what the reading actually returns or how the two tiers differ, leaving a meaningful gap.

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

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

Schema coverage is 78%, so most parameters are already documented. The description's topic list maps natural-language questions onto the topic enum values, which is mildly helpful, but it adds no syntax or format detail beyond the schema for date, time, lat/long or timezone.

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 — a 'Granth-based reading for a life question' — and names its sources (BPHS, Phaladeepika) plus a concrete list of question types. It does not explicitly distinguish itself from siblings like janam_kundali or kundali_milan, and in fact claims 'a general kundali reading' as one of its topics, which blurs 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?

The enumerated topics (ex back, toxic boss, career pivot, property timing, etc.) give clear implicit context for when this tool applies. However there are no exclusions and no routing to alternatives, so an agent cannot tell when to prefer janam_kundali or kundali_milan over this.

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 that results are derived from Shadbala strength, which is useful interpretive context. It says nothing about determinism of the returned values, response shape, or the impact of an approximate birth time (the schema hints 12:00 fallback but the description does not warn about degraded accuracy).

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 that enumerates the outputs without preamble or filler. The list is somewhat dense but every item corresponds to an actual returned value, so nothing is wasted.

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

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

With no output schema, the description must convey what comes back, and it does: day, colour, number, metal, direction, and a per-weekday lucky/neutral/challenging breakdown. Required birth inputs are fully documented in the schema. The remaining gap is the absence of any note about accuracy when birth time is approximate.

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% with 7 parameters, each documented in the schema (date/time formats, lat/long ranges, timezone default, optional name/place). The description adds no parameter-level meaning beyond that. Baseline 3 is appropriate when the schema carries the full parameter burden.

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 concrete artifacts returned (lucky day, colour, number, metal, direction) and the derivation method (strongest planet via Shadbala), plus the weekday lucky/neutral/challenging classification. That is specific enough to distinguish it from generic report tools. It stops short of explicitly contrasting itself with close siblings such as planet_strength or numerology.

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 call this tool, what prerequisites exist (e.g. that a full birth chart must be computable from date/time/place), or how it differs from planet_strength, kundali_strength or numerology. The agent must infer usage entirely from the output list.

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 only that the list is a fixed set of 40 works; it says nothing about output format, ordering, or stability of the ids. Adequate but thin on top of 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?

A single front-loaded sentence: verb, count, resource, and the qualifying condition, followed by a compact illustrative list. Every clause earns its place and nothing is 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?

With no parameters, no output schema, and full annotation coverage, the description carries almost the whole burden and does so for purpose and content. The remaining gap is that it does not tell the agent how the returned karma ids are consumed by the sibling muhurat tools, which would close the loop.

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. There is nothing for the description to clarify about inputs, and it correctly does not invent any.

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 ('List') and resource ('40 works (karma ids)') plus the exact condition that makes them useful — a personal Shubh Muhurat can be calculated for each. Concrete examples (marriage, griha pravesh, vehicle purchase) make the resource unambiguous and implicitly separate it from the sibling computation tools shubh_muhurat and vivah_muhurat.

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 this is the enumeration step that feeds shubh_muhurat, but it never states when to call it, that it should be called before requesting a muhurat, or what to do with the returned ids. No alternatives or exclusions are named, so the agent must infer the workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety and determinism are covered structurally. The description adds only that inputs are minimal (DOB plus optional name); it says nothing about determinism of the calculation, validation failures, or output shape beyond the attribute list.

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

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

Two compact sentences, front-loaded with the domain and computed values, with the input requirement last. Dense but no filler; every clause carries information an agent can use.

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

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

With no output schema, the description correctly enumerates the returned values (the three numbers plus ruling planet, colour, day, friendly numbers), and it states the required input. For a two-parameter, read-only tool this is close to complete; only the exact response structure/precision is left unspecified.

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 50% (date documented, name undocumented), so the description must compensate, and it does: it marks name as optional and links it to Naamank (the Chaldean name number), which explains why the parameter exists. It does not add format or length guidance for name beyond what the schema already enforces.

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 domain (Vedic numerology) and enumerates exactly what is computed: Mulank, Bhagyank and Naamank, plus the derived attributes (ruling planet, lucky colour, day, friendly numbers). This is clearly distinguishable from every sibling, which are all natal-chart/muhurat/astrology tools rather than numerology.

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 supplies the input precondition ('Needs only date of birth (and optional name)'), which is useful routing information, but it never states when an agent should pick this tool over a sibling or what the tool is not for. Usage is implied by input requirements rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely useful behavioral context beyond that: the computation is geographically scoped to India and timezone-anchored to IST, which matters because sunrise/sunset and muhurat windows are location-dependent while the schema exposes no location parameter.

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?

One sentence, front-loaded with the resource, then the return contents. Every clause carries information and nothing is redundant.

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

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

With no output schema, the description compensates by enumerating the returned panchang elements, and the sole parameter is fully specified. Adequate for a zero-required-parameter query tool; it only lacks any note on how muhurat windows are scoped or bounded.

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% — the single 'date' property already documents the YYYY-MM-DD pattern and the today/IST default. The description restates the default ('default today, India') without adding format or boundary detail, 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?

Names the resource (Daily Hindu Panchang) and enumerates exactly what it returns — tithi, nakshatra, yoga, karana, vaar, sunrise/sunset, muhurat windows — so the agent knows precisely what it gets. It does not, however, distinguish itself from siblings like shubh_muhurat or muhurat_karma_list that also surface muhurat-related 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?

Usage is implied: this is the baseline daily almanac, and 'default today' signals the no-argument case. There is no explicit statement of when to prefer this over the many muhurat-finding siblings, nor any exclusion or prerequisite.

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 fully covered. The description's added value is the hint that output is a numeric ratio rather than a discrete label, which is genuinely informative but thin. It does not describe units, scale, or how the 'strongest/weakest' are selected.

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 followed by the differentiating output claim. Slightly padded by the marketing-flavored second sentence, but no real 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?

For a computed, read-only astrology tool with a fully documented 7-parameter schema but no output schema, the description conveys enough: the metric, its normalization basis, and the headline results. Missing only output scale/format details, which is a minor 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 100%, with patterns, ranges, and defaults (e.g. timezone default 5.5, 12:00 convention for unknown birth time) already documented. The description adds no parameter-level information, 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?

Names a specific verb/resource (Shadbala strength of the 7 grahas) and even cites the classical source BPHS Ch.27, plus what it returns: ratio against the classical minimum and strongest/weakest planet. Clear, but it does not explicitly distinguish itself from siblings like weak_planet, lagna_bal, or kundali_strength that sound adjacent.

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 guidance and no named alternatives. An agent cannot tell from the description whether to call this, weak_planet, or lagna_bal for a strength question; the 'Trikaal Vaani shows the real number' line is branding, not 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some behavioral value by enumerating what it evaluates and returns (running status, current cycle dates, full-life cycles), but discloses no prerequisites, computation basis, or edge cases like an unknown birth time (which the schema's time field hints at).

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 core output front-loaded. The only waste is the unexplained 'Trikaal Vaani' tag, which consumes space without informing the agent.

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

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

With no output schema, the description does sketch the return contents (running status, cycle dates, all cycles), and annotations cover safety. However, it leaves the coordinate/timezone-based birth-data requirement (which the schema requires as 4 mandatory fields) unmentioned, and gives no hint of result format for a computation-heavy astrology 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 100%, so all seven parameters including the conventional-noon fallback for unknown birth times are fully documented in the schema. The description contributes nothing about parameters, so the baseline of 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 subject and output: whether Saturn Sade Sati is running for a Moon sign, plus the current cycle dates and all cycles in life. This is distinguishable from siblings like dosha_check and planet_strength. The trailing 'Trikaal Vaani' is unexplained branding that adds no clarity.

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 versus alternatives such as dosha_check, yog_check, or planet_strength, all of which could plausibly touch on Saturn-related afflictions. Usage is only weakly implied by the tool name and the phrase about Sade Sati.

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 one genuine behavioral fact beyond them: the free view only covers the next 3 months, implying a paid tier beyond that. It omits result count, pagination, and any auth/quota details, so it is adequate 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?

Two short sentences, no filler, and the core capability is front-loaded ahead of the free-tier constraint. Every clause carries 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?

There is no output schema, so the description should at least sketch the return shape; it says 'dates AND times' but not how many results or how they are structured. It also never tells the agent that karma values must come from muhurat_karma_list. The free/paid coverage boundary is the one substantive completeness contribution.

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 all 8 parameters, including the karma work ids and the unknown-birth-time convention (12:00), are already documented in the schema. The description only gestures at 'chosen work' and 'birth chart' without adding syntax or semantics beyond the schema, which is the baseline case.

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 (auspicious dates and times) with a clear qualifier: personalised to the birth chart and scoped to a chosen work. An agent can distinguish it from narrower siblings like vivah_muhurat or child_birth_muhurat because the work type is passed in via karma. It does not explicitly name any sibling, so it stops short of a 5.

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

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

The description implies the use case (choosing a work and getting dates) but gives no when-to-use conditions, no exclusions, and does not point to muhurat_karma_list for valid karma ids or explain when a sibling like vivah_muhurat is preferable. Only the free-tier scope hint is present.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that by disclosing the exclusion rules (Kharmas, Adhik Maas, Chaturmas) that determine which dates appear, though it says nothing about output volume or ordering.

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: what it returns, what it filters out, and who it is not for. Zero filler and the output content is front-loaded.

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

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

For a single-parameter, no-output-schema tool with full annotations, the description covers return contents, filter rules, and personalization scope. The only gap is the year range, which is left 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 description coverage is 0%, so the description must carry the load; it only implies a year input via 'for a year'. It does not mention the 2024–2035 valid range that the schema enforces, so an agent relying on the prose alone could pass an out-of-range year.

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 ('shubh marriage dates for a year') and enumerates the returned fields (muhurat time, nakshatra, tithi, lagna). The 'strict-classical' qualifier plus the marriage scope cleanly separates it from siblings like shubh_muhurat and muhurat_karma_list.

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 clear scope conditions: it excludes Kharmas, Adhik Maas and Chaturmas, and is explicitly 'not personalised to any birth chart', which implicitly routes personalized queries elsewhere. It stops short of naming which sibling to use for chart-specific muhurat, so no explicit alternative is provided.

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 safety and side-effect profile are covered. The description adds only that the result is a Shadbala-based weakest-planet calculation and mentions life areas, but it does not disclose auth, computation source, or return behavior beyond 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?

It is a single front-loaded sentence that states the essential output categories before the interpretive closing clause. Nothing is wasted, and the core concept 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?

No output schema exists, so the description must carry the return-value burden; it does list the main components (weakest graha, life areas, strength numbers), but it does not describe the shape, ordering, or interpretation of those components. Given the rich input schema and safety annotations, it is mostly complete but leaves some output ambiguity.

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 (date, time, latitude, longitude, etc.) has a descriptive field in the schema. The description adds no parameter-level meaning, but the baseline is 3 when the schema already handles this.

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 computed resource ('the weakest graha by Shadbala') and enumerates three outputs: life areas, strength numbers, and the 'planet that most needs support.' That level of specificity lets an agent distinguish it from the broader sibling planet_strength, even without naming the 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?

No sentence says when to choose this tool over siblings, what preconditions are required, or when it should be avoided. It merely describes output, leaving the agent without 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 readOnly=true, idempotent=true, openWorld=false, so the safety profile is covered. The description does add one genuinely useful behavioral fact — that this is a limited free view lacking timing windows and remedies — which warns the agent the response is partial. It says nothing about accuracy caveats or rate 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?

Front-loaded with the core purpose, which is good, but the question list duplicates the schema enum verbatim (including Hinglish glosses like 'shadi kab hogi', 'santan') and the closing line is promotional rather than informative. Several phrases do not earn their place.

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

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

With no output schema and 9 params, the description carries more burden, and it does convey what comes back (yog strength with reasoning, granth/saar summary) and that the free view omits timing and remedies. It still leaves the shape of the return (structured vs prose), any pagination, and error conditions unspecified.

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% with 9 well-documented params, including the constraint that gender is required for marriage_timing and foreign_spouse and why. The description adds no parameter meaning 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 concrete verb+resource: it checks a specific 'yog' from the birth chart and enumerates the seven life questions it supports (government job, foreign settlement, marriage timing, etc.). That enumeration clearly separates it from siblings like dosha_check or kundali_strength, though the surrounding marketing phrasing dilutes the signal slightly.

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 only routing information is 'Free view; full report with timing windows and remedies is on Trikaal Vaani' — a tier/upsell note, not when-to-use guidance. It never tells the agent how to choose this over dosha_check, kundali_strength, or life_reading, nor what prerequisites (e.g. exact birth time) matter.

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