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

No annotations are provided, so the description carries the full burden—and it meets it comprehensively. It discloses inauspicious window subtraction, scoring with Abhijit/Amrita overlap, hard-avoid Bhadra Mukha, skipped periods like Pitru Paksha, Panchaka checks at two levels, Disha Shoola filtering, and night-specific scoring. It even documents a legacy activity name resolution, a genuinely non-obvious behavior.

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

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

The description is front-loaded with a one-sentence purpose and then organizes behavior, version notes, optional birth-data params, and an Args list. It is dense and long, but almost every sentence contributes unique operational detail. The 1.9.0 changelog-style paragraph is the least essential for invocation, making it slightly less concise than ideal.

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

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

For a complex 14-parameter astrological tool with an output schema, the description covers invocation constraints, filtering behavior, scoring nuances, and optional parameters in depth. Remaining gaps include the source/enumeration of 'published activity keys' and timezone parameter semantics, but the description still gives an agent enough to invoke the tool correctly in most cases.

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

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

With 0% schema description coverage, the description compensates strongly: it specifies start_date format, days range, activity key concept, city versus latitude/longitude, system enums, chandra_mode enums, ayanamsa enums, travel_direction options, and include_night effect. It also explains janma_nakshatras count and purpose, janma_rasis alignment with null allowance, and janma_lagnas for strict Lagna Shuddhi. Only timezone is left without semantic explanation, but the overall coverage is exceptional.

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

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

The opening sentence states a specific verb and resource: 'Find ranked auspicious time slots over the coming days.' This clearly differentiates it from single-day tools like get_muhurta and from general panchangam lookups. The description then details the exact filtering and scoring mechanism, leaving no ambiguity about what the tool computes.

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

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

The description clearly implies use for multi-day auspicious-slot search, but it never names sibling tools or states when to prefer get_muhurta, get_panchangam, or get_special_days instead. No explicit when-not-to-use guidance or alternative routing is provided, though the 'over the coming days' phrase gives useful context.

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

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

With no annotations present, the description carries the full behavioral burden. It clearly discloses the per-day tara names, the good_for_all_dates behavior, the chandra position/verdict values (good | puja | bad), and the rule that good_for_all requires both checks to pass. It does not cover every edge case or validation behavior, but it is substantially transparent.

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

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

The description is dense but front-loaded: it opens with the core purpose, then outputs, then customization, then parameter details. The parameter section is a long run-on sentence, but every part carries necessary information for a 10-parameter tool, so 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?

Given the high parameter count, no annotations, and an existing output schema, the description is remarkably complete. It explains the tool's purpose, behavior, return concepts, optional modes, and all parameter meanings. There is no critical missing context that would prevent an AI agent from invoking it correctly.

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

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

Schema description coverage is 0%, yet the description manually documents every parameter with meaningful details: canonical nakshatra spellings, date format, days range and default, city versus latitude/longitude, system default, timezone IANA expectation, janma_rasis alignment, and chandra_mode variants. This fully compensates for the missing schema descriptions.

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

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

The description clearly states the specific purpose: finding upcoming auspicious days based on janma nakshatras (Tarabalam, optionally Chandrabalam). It also names the key outputs, making the tool's function easy to grasp. However, it does not explicitly compare against or distinguish itself from sibling tools.

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

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

The description implies the tool should be used when an agent needs Tarabalam/Chandrabalam-based auspicious day calculations, and it explains conditional usage such as passing janma_rasis to enable Chandrabalam checks. It gives no explicit when-to-use versus sibling tools or exclusions, but the domain-specific purpose provides reasonable contextual 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?

No annotations are provided, so the description carries the full burden. It discloses accuracy tolerances, a maximum date range of 366 days, and timezone derivation behavior when latitude/longitude are passed. It does not explicitly describe side effects or behavior when the max range is exceeded, but the overall behavioral profile is well covered.

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

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

The description is dense but every sentence earns its place: it defines the resource, clarifies the astronomical criterion and accuracy, states the date-range limit, and summarizes arguments. The core purpose is front-loaded and the helper detail is packed into a compact Args section.

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 7 parameters, optional coordinate-based input, and the presence of an output schema, the description is complete enough for correct invocation. It covers inputs, defaults, limits, accuracy, and the city-or-coordinates alternative. Minor omitted details such as exact error behavior for oversized ranges are not essential for selecting and calling 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 0%, but the description compensates by explaining all relevant parameters: start_date/end_date format, city name or latitude+longitude, timezone derivation, and optional planets subset with default. This adds real meaning beyond the bare schema property names.

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: 'Returns Asta... and Udaya... periods for the five classical planets... over a date range for a given city.' It defines Asta and Udaya and explicitly contrasts with BPHS Maudhya thresholds, so it distinguishes itself from generic panchangam or per-day combustion-flag 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 positions this as the Drik Panchang sky-visibility Asta/Udaya calendar over a date range for a city, and explicitly states it is not the fixed BPHS elongation Maudhya thresholds used in per-day combustion flags. However, it does not explicitly name an alternative sibling tool to use for that per-day case, so the when-not guidance is present but not fully concrete.

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

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

With no annotations provided, the description carries the full behavioral burden, and it delivers: 12 daytime horas start at sunrise, 12 nighttime horas start at sunset, the first hora is ruled by the weekday lord, and timezone is derived if omitted. These are substantive algorithmic disclosures beyond what the schema shows. It stops short of edge cases such as invalid-city handling or polar-region behavior, 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?

Four sentences in roughly 70 words, with the purpose front-loaded in the first sentence. The algorithm details and the compact Args section each earn their place; there is no redundancy 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 moderate-complexity tool with 6 parameters, the description covers purpose, parameter formats, defaults, and core behavior. The presence of an output schema relieves it of explaining return values. The only real gaps are explicit sibling differentiation and failure-mode behavior.

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

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

Schema description coverage is 0%, so the description must compensate — and it does completely. It documents the date format (YYYY-MM-DD), the city name with latitude/longitude alternative, the system enum values (drik|surya_siddhanta|vakya) with default, and the timezone-derivation behavior. Every parameter's semantics are covered in plain language.

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: 'Returns 24 planetary hours (horas) for a date and city as JSON.' The follow-on sentences explaining the daytime/nighttime split and the weekday-lord rule make the tool's function unmistakable and clearly distinct from astrological siblings like get_muhurta or get_panchangam.

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?

When to use the tool is inferable — any request for planetary hours on a given date — but the description never explicitly positions it against alternatives or states exclusion conditions. With 16 sibling tools in the same domain, explicit routing ('use get_muhurta for auspicious time selection') would strengthen this dimension.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does well by stating that Sutak is provided for visible eclipses only, that the range is capped at 730 days, and that timezone is derived if omitted. These are meaningful behavioral traits beyond what the schema shows. It does not mention error handling or rate limits, but those are not clearly needed here.

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

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

The description is compact and well-structured: purpose first, then entry contents, then constraints and argument syntax. Every sentence adds necessary information without padding. The max-range constraint and argument instructions are clearly front-loaded after the core purpose.

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 6-parameter tool with no schema descriptions, the description covers the essential invocation details: date range, city/coordinate options, timezone behavior, max range, and the composition of each returned eclipse entry. Since an output schema exists, return-value documentation is not the description's responsibility. The only minor gap is explicit guidance about sibling-tool selection, but the context is otherwise complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does: it specifies date formats (YYYY-MM-DD), explains that city can be replaced by latitude+longitude, and clarifies timezone derivation when omitted. It does not explicitly mention the city default (Hyderabad) or the exact names of latitude/longitude parameters, but the guidance is sufficient for correct invocation.

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: 'Returns all solar and lunar eclipses in a date range with per-city visibility and Sutak timing.' It clearly distinguishes this tool from the sibling astrological tools by naming the exact domain (eclipses), the output granularity (per-city), and the unique Sutak timing component.

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: when solar/lunar eclipse data with visibility and Sutak timing is needed for a date range and city. It also states a concrete usage constraint ('Max range: 730 days'). It does not explicitly name alternatives or specify when not to use it, which keeps it just below a 5.

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

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

With no annotations provided, the description carries full responsibility and does an excellent job: it discloses the verdict model, source support, unverified areas (e.g., node Vedha remains unverified), limits of the classical references, and that positions are at sunrise. These are genuine behavioral caveats beyond a simple 'returns transit results' statement.

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 primary purpose is front-loaded in the opening sentence, and the arg list is useful. However, the description spends several sentences on detailed verse citations and distinctions among Phaladeepika chapters; these support credibility but are heavier than needed for tool selection and basic invocation.

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

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

The description covers output semantics, sources, and caveats well, and an output schema exists to document returned values. Nonetheless, it leaves four optional parameters undocumented and offers no guidance on defaults or when to override them, making the definition incomplete for a seven-parameter tool in a specialized domain.

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

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

Schema description coverage is 0%, so the description must compensate. It explains date format, daiji rashi spelling expectations, and city lookup, but omits ayanamsa, timezone, latitude, and longitude as separate parameters, despite the schema listing them. The phrase 'latitude+longitude' also loosely conflates two separate schema fields, which could mislead invocation.

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

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

The first sentence clearly states the resource: Gochara transit verdicts per janma rasi, covering nine grahas, house positions, and favourable/vedha/adverse outcomes. This inherently distinguishes it from generic position or panchangam tools, though it does not explicitly name a sibling 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?

The description conveys when to use it via domain language: when transit verdicts relative to the natal Moon sign are needed. However, it never states when not to use it or which sibling tool to choose instead, so the usage guidance remains implied rather than explicit.

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

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

With no annotations, the description carries the full behavioral disclosure burden, and it does so well. It reveals the sidereal frame, the sunrise-based calculation time, the specific output fields, and how timezone is derived when omitted. There are no hidden side effects or ambiguous behaviors relevant to this read-style computation tool.

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

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

The description is dense but efficient, front-loading the main purpose before the argument summary. It is somewhat run-on, with the output list and argument list packed into long clauses, but every piece of information earns its place and no filler is present.

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

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

Given six parameters, no annotations, heavy sibling overlap, and an output schema already covering return shape, the description is remarkably complete. It covers the calculation time, reference frame, ayanamsa choices, location resolution, timezone derivation, and the relationship to gochara — everything an agent needs to 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 0%, so the description must compensate; it does by giving date format, city vs latitude/longitude usage, timezone derivation, ayanamsa allowed values, and the default ayanamsa. It does not individually name the latitude, longitude, and timezone parameters, but their roles are clearly enough inferable from the description.

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

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

The description names a specific verb and resource: get 'sidereal positions of all nine grahas' at sunrise for a given date. It lists concrete outputs (longitude, rasi, nakshatra, pada, retrograde, rasi_until, next_rasi) and clearly differentiates itself from gochara tools by calling itself 'transit/gochara groundwork'.

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 tool is useful as raw positional groundwork for transits/gochara, which hints at when to use it. However, it never explicitly tells the agent when to prefer get_gochara or another sibling tool instead, nor does it state any exclusions or fallback conditions.

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

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

No annotations are provided, so the description carries the full burden, and it does substantial work: it explains the 1° orb rule, latitude-based victor determination, exempt planets, output fields, UTC times, and the maximum date range. It does not discuss error behavior or boundary inclusivity, but the core behavior is clearly disclosed.

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

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

The description is front-loaded with the main result, followed by a compact technical definition, summary of returned data, and argument details. It is longer than minimal, but every sentence carries meaningful information needed to correctly understand and invoke the tool.

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

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

The description covers the concept, calculation rules, output fields, parameter formats, defaults, and a hard constraint on date range. It does not address error handling or whether input dates are inclusive, but for a read-only calculation tool this is a fairly complete picture.

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

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

Schema coverage is 0%, so the description is the only documentation for parameters. It fully compensates by specifying start_date and end_date formats as YYYY-MM-DD, giving a concrete example for the optional planets subset, and explaining the default behavior of all five planets producing 10 pair combinations.

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: 'Returns Graha Yuddha (planetary war) periods in a date range.' It also defines the phenomenon with enough precision that the tool is immediately distinguishable from sibling astrology calculators, even without an explicit contrast.

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

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

The description clearly implies when to use the tool: whenever Graha Yuddha periods are requested, and it provides useful constraints like a 366-day maximum range and optional planet filtering. However, it never names an alternative or states when not to use it, despite related siblings such as get_graha_positions existing.

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

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

With no annotations provided, the description carries the full disclosure burden. It usefully states that output is JSON, the tracking window runs from sunrise to next sunrise, timezone is derived when omitted, and multiple astronomical systems are supported. It does not cover error behavior or coordinate precedence, but these are secondary for a read-only calculation tool.

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

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

Two sentences deliver the core behavior first, then compactly summarize all key arguments and defaults. There is no filler or repetition of schema fields, and every clause adds useful 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 description is reasonably complete for a read-only astrological calculation, especially since an output schema exists for return values. The main gaps are not explaining whether latitude/longitude truly overrides the required city field, and not clarifying the practical differences between the three supported systems.

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

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

The description adds substantial parameter meaning beyond the empty schema coverage: it documents the YYYY-MM-DD date format, city name usage, the latitude/longitude alternative, timezone derivation, and the drik|surya_siddhanta|vakya system choices with default. However, it conflicts with the input schema by implying latitude/longitude can replace the required city parameter, which is confusing for an agent deciding what to pass.

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

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

The description clearly states the tool returns Ascendant (Lagna) sign boundaries for a date and city, with a specific temporal scope of sunrise to next sunrise. It is unambiguous about the resource and output format, though it does not explicitly name sibling tools to distinguish itself from 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?

The intended use is implied by the description: you call this when you need Lagna transition boundaries for a given date and place. However, there is no explicit guidance about when to choose this tool over related siblings like get_rashi_ingresses or get_graha_positions, and no exclusion criteria are 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It explains the JSON return, fields included, the derived-timezone behavior, and the system calculation options. It does not mention error behavior or invalid-input handling, but the output schema and parameter guidance cover most operational 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?

The description is more than a sentence or two but remains well-organized: purpose, use case, output fields, then args. The exhaustive field list adds length but is valuable for an agent deciding whether this tool returns the needed timing data.

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

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

Given no annotations, six parameters, and an output schema that likely documents return structure, this description covers purpose, usage, output scope, and parameter semantics. An agent has enough context to select and call 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 0%, yet the description independently documents all main parameters: date format, city-or-coordinates alternative, timezone derivation, and system enum values with default. This fully compensates for the lack of schema descriptions and adds meaningful usage 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?

State a specific verb ('Returns'), resource ('auspicious and inauspicious time windows'), and scope ('for a date and city'). It also differentiates itself from get_panchangam by saying it is lighter and oriented toward quick queries, so an agent can distinguish sibling tools without opening schemas.

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

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

Explicitly says to use it for quick 'is this a good time?' queries and contrasts it with get_panchangam. It does not enumerate when-not-to-use conditions or mention other relevant siblings like find_muhurta, but the guidance is clear enough for basic routing.

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

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

With no annotations, the description carries the full behavioral burden and does it well: it lists returned field groups, new fields, defaults, and the nuance that SS and Vakya accept ayanamsa but ignore it. This gives an unusually transparent picture of what the tool returns and how its calculation models behave.

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 front-loaded, starting with the core output definition before optional overrides and version notes. Some lists are long, but they are relevant given the breadth of the response. No filler sentences are present.

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

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

For a complex 7-parameter tool with no annotations and an output schema, the description is largely complete: it covers defaults, system variants, and optional overrides. It falls short by never mentioning supported-city constraints or clarifying city/coordinate/timezone semantics. The dateInputFormat/schema mismatch is a minor completeness gap.

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

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

Schema description coverage is 0%, so the description must compensate; it explains system, ayanamsa, dateInputFormat, and latitude/longitude/timezone overrides. However, it does not define the accepted city form, coordinate/timezone formats, or how overrides interact with city lookup. It also mentions dateInputFormat even though that parameter is absent from the input schema.

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

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

States a specific verb and resource: 'Returns full Panchangam JSON for a date and city', then enumerates the main output groups such as Pancha Anga, sky events, and windows. The single-date/city qualifier makes it distinguishable from siblings like get_panchangam_range.

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

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

Provides clear context for when to use it: a date and city for a full Panchangam. It also documents the system and ayanamsa options and optional coordinate/timezone overrides. However, it never explicitly names sibling tools as alternatives or states when not to use them.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses the 31-day limit, the compact summary behavior, the version-dependent field additions, and the detailed output content. It does not cover edge behavior like invalid ranges or city lookup failures, but it provides solid behavioral 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?

The description is front-loaded with the core behavior and then lists output fields and parameters. The long field list is dense but purposeful, since it tells the agent what information can be extracted. It is not overly repetitive, though it could be slightly more 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?

The description is largely complete for a tool of this complexity: it covers the main use case, output contents, parameter formats, and limits, and an output schema exists to document return structure. The main missing context is the optional coordinate/timezone parameters and how they interact with the required city parameter.

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

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

Schema description coverage is 0%, so the description must compensate. It explains date formats, city, system choices, ayanamsa choices, and defaults—valuable information absent from the schema. However, it omits the optional latitude, longitude, and timezone parameters, leaving a noticeable gap.

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

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

The description states a specific verb ('Returns') and a precise resource: a compact Panchangam summary for each day in a date range. This clearly distinguishes it from the single-day sibling `get_panchangam`, and the 'max 31 days' scope adds important specificity.

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 a clear use case: 'planning muhurtas over a week or comparing multiple days.' It does not explicitly name alternatives or say when not to use it, but the range-focused context is enough for an agent to select it appropriately among the siblings.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses the complete verdict set, per-limb quality values, the exact rules for each panchanga limb, the reason per limb, and the important fact that values are taken at sunrise. This is detailed, transparent behavior disclosure beyond the schema.

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

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

The description is front-loaded with the core purpose, then provides the output structure, followed by compact rule summaries and argument formats. Despite its length, every sentence contributes necessary semantic or behavioral content; there is no fluff 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?

The definition is largely complete: it explains the output verdicts, limb-level quality values, all relevant rules, and most parameters, and the output schema covers return-value structure. Remaining gaps are the undocumented timezone parameter and the lack of explicit guidance on choosing between the available astronomical systems, which keep it from being fully complete.

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

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

The input schema has 0% description coverage, but the description compensates for most parameters: date format, city name or latitude/longitude, and the system values ('drik|surya_siddhanta|vakya') with its default are all explained. It does not describe the timezone parameter at all, so it is not fully complete.

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 'five-limb purity assessment for any date' and specifies the exact verdict scale and per-limb breakdown. It is clear about the resource and purpose, but it does not explicitly differentiate from siblings such as get_panchangam or find_muhurta, so it stops short of a 5.

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

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

The phrase 'purity assessment for any date' implies when this tool would be relevant, and the detailed shuddha/ashuddha rules suggest a muhurta-suitability use case. However, there is no explicit guidance on when to use this tool instead of related siblings, and no exclusions or alternatives are named.

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

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

With no annotations provided, the description carries full behavioral burden and meets it: sidereal/ayanamsa-configurable coordinates, retrograde ingresses included, planets without sign changes omitted, exit timestamps may fall outside the requested range, and timestamps are in UTC. This is detailed and directly useful to an agent.

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

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

The description is dense but every sentence earns its place: core function, domain definition, behavioral caveats, exclusions, range limit, and parameter guidance. The Saturn example is illustrative rather than padding, and the structure front-loads the primary purpose.

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?

Despite no annotations, the description covers purpose, input semantics, supported values, edge cases, timezone, entry fields, and range limits. The output schema handles the return shape, so nothing critical is missing for an agent to select and invoke 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 0%, but the description compensates fully: start_date and end_date are given the YYYY-MM-DD format, planets is optional with a default of all eight, and ayanamsa lists its allowed values and default. This adds meaning far beyond the bare schema field names.

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: 'Returns all rashi (sign) ingress events for the classical planets over a date range.' It defines the domain term, lists supported planets, states the Moon exclusion, and clearly distinguishes ingress-event data from the sibling get_gochara/get_graha_positions tools.

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

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

The description gives clear usage context: it is the foundational event for gochara period boundaries, supports a date range up to 366 days, accepts an optional planet subset, and explains why Moon is excluded. It does not explicitly name sibling alternatives or say 'when not to use this tool', but the scope and constraints are evident.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it states the output is deterministic, every line maps to a calculation, and specific conditions affect the content (e.g., Sade Sati shown only when running, janma_nakshatra adds the tara line). It stops short of describing edge-case behavior such as missing city data or invalid rasi names, but the core behavior is clearly disclosed.

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

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

The description is dense but every clause earns its place: the purpose is front-loaded, the behavioral guarantees are stated compactly, and the argument list uses consistent formats and defaults. There is no 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 an 8-parameter tool with no schema descriptions, the description covers most invocation details and the output content is well specified. The main gap is the timezone parameter, which is not explained even though it can affect date-based calculations, and the interaction between city, latitude/longitude, and timezone is left unclear. The output schema exists, so return-value documentation is not required.

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

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

The schema has 0% description coverage, so the description must compensate. It does: date gets an exact format, janma_rasi gets an example, janma_nakshatra gets its purpose, city gets an alternative latitude/longitude form, and ayanamsa gets an explicit enum with a default. However, the timezone parameter is not mentioned at all, and the latitude/longitude guidance is compressed into a shorthand that may be ambiguous about which schema fields to populate.

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 deterministic daily reading for a janma rasi and enumerates the exact components it produces (chandrabalam, gochara verdicts with vedha, Sade Sati/Ashtama Shani, tarabalam). This distinguishes it from sibling tools like get_panchangam or get_gochara, which produce raw astrological data rather than a compiled daily reading.

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

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

The description implies usage through phrases like 'Daily Rasi Phalalu' and 'for a janma rasi,' making it clear this is for personalized daily readings. However, it never explicitly says when to prefer this tool over overlapping siblings such as get_gochara, find_tarabalam_days, or get_panchangam, nor does it mention any exclusions or alternatives.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: the tool returns a JSON list, allows city name or coordinates, derives timezone if omitted, and defaults to the 'drik' system. It does not discuss authentication, rate limits, or error handling, but covers essential behavior for usage.

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

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

The description is a single sentence that efficiently conveys the purpose and major argument details. It is front-loaded with the main function. Although somewhat lengthy, it avoids unnecessary words and is well-structured.

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

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

Given the presence of an output schema (signaled), the description focuses on inputs and behavior. It covers the required parameters and key optional ones, explaining fallbacks. The overall usage context is complete for an agent to invoke the tool correctly.

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

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

The schema has 0% description coverage, so the description must compensate. It adds meaningful context for parameters: city can be name or lat/lon, timezone is derived automatically, system has default and possible values. It provides example values for year and month. While not all 7 parameters are fully detailed, the key ones are addressed.

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 that the tool returns a JSON list of special days for a given month, explicitly listing types like Ekadashi, Amavasya, etc. This differentiates it from sibling tools that focus on other calendar events like eclipses or graha 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 provides clear usage context, specifying required arguments (year, month, city) and optional parameters with defaults. However, it does not explicitly state when to use this tool versus alternatives, though the list of special days implicitly guides 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It clearly states this is a read-only operation returning a JSON list of a fixed set of 22 cities with specific fields, and there are no side effects implied. It does not mention edge cases or errors, but for a zero-argument listing operation this is a minor gap.

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

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

Two sentences, zero filler: the first states the output shape and cardinality, the second gives the critical usage cue. The most important information is front-loaded and every sentence adds value.

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

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

For a zero-parameter discovery tool with an output schema, the description is complete: it states the output format, cardinality, fields, and the intended first-call usage. Nothing an agent needs to invoke it 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?

The tool has zero parameters and a 100% schema coverage, so parameter documentation is trivially complete. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description's mention of discovering valid city names also indirectly explains how the output will be used as input to sibling tools.

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

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

The description opens with a specific verb and resource: it 'Returns a JSON list of 22 pre-configured cities' and enumerates the contained fields. This clearly distinguishes it from the sibling astrological-calculation tools, and 'Call this first to discover valid city names' reinforces its role as a discovery endpoint.

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 instruction 'Call this first to discover valid city names' provides explicit sequencing guidance, telling an agent when to invoke this tool relative to other city-dependent calls. It does not explicitly discuss alternatives or when not to use it, but that is less relevant for a zero-argument discovery tool among calculation siblings.

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