caelus-mcp

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

Discloses key behaviors: maximal pattern reporting (hiding contained patterns), structural details (apex, bodies, orbs), and pure geometry without interpretation. No annotations provided so description carries full burden.

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?

Concise yet comprehensive: two sentences with front-loaded key patterns, each sentence providing necessary detail without redundancy.

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

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

Complete for a complex tool: explains returned pattern structures, maxima property, prerequisites, and delimits scope (no interpretation). No output schema, but description compensates.

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 descriptive parameter descriptions. The tool description adds no further parameter meaning beyond restating needs (date, lat, lon). Baseline 3.

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 lists specific aspect patterns (T-squares, grand trines, etc.) with clear verbs and resources, and distinguishes itself from sibling tools by focusing solely on classical aspect configurations.

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?

Implied usage: when needing aspect pattern detection. But lacks explicit when-not-to-use or alternatives among siblings like 'chart_signature' or 'natal_chart'.

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 clearly discloses that the tool returns only counts and structural data, not interpretation. It mentions the output includes classical chart ruler and distributions. It does not discuss error conditions, permission requirements, or rate limits, but for a data retrieval tool of this nature, the behavior is well-described. A minor improvement would be to note that the tool is read-only and requires valid astronomical coordinates.

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

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

The description is two sentences: the first defines the output concisely, the second clarifies that it's counts-only and specifies required inputs. No redundant phrases, front-loaded with purpose. Every word earns its place.

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

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

Given there is no output schema, the description adequately explains the content of the output: counts of distributions, dominant element/modalitiy/sign, and classical chart ruler. It is complete for a summary tool. However, it could mention that the counts are based on celestial bodies or that it requires valid coordinates within a typical date range. It also lacks any mention of how errors or invalid inputs are handled. Siblings are many, but the description clearly positions this as a compact structural alternative.

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

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

Schema description coverage is 100% (all 5 parameters have descriptions). The tool description adds minimal semantic value beyond the schema, only reiterating that date, lat, lon are needed. It provides no additional context for the optional parameters (zodiac, house_system) beyond what is in the schema. With high schema coverage, baseline 3 is appropriate; the description does not significantly enhance parameter understanding.

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 'a chart's structural signature as plain counts' of specific distributions (element, modality, angularity, quadrant, hemisphere), plus dominant element, modality, most-occupied sign, and classical chart ruler. It explicitly distinguishes from interpretation with 'Counts only, no interpretation — a compact summary for emphasis and comparison.' The verb 'chart_signature' and resource 'structural counts' make it distinct from siblings like natal_chart or aspect_patterns.

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

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

The description specifies required inputs ('Needs date, lat, lon') and states the output is a compact summary without interpretation, implying use for quick comparison vs full chart reading. However, it does not explicitly state when to use this tool over alternatives like natal_chart or yogas, nor does it provide exclusion criteria. The context is clear but not fully prescriptive.

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 fully explains the behavioral traits: it computes midpoint composite (shorter-arc midpoint) and Davison chart (real chart for midpoint). This transparency is comprehensive for a 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 extremely concise at two sentences, front-loading the purpose and key requirements. Every sentence is essential and 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 tool has nested objects and no output schema, the description is fairly complete. It explains the input requirements and the two types of charts computed. Could slightly benefit from mentioning output format, but overall adequate.

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%, baseline 3. The description adds value by explaining that 'a' and 'b' are Person A and Person B birth data, and clarifies the optional zodiac and house_system parameters. This goes beyond the schema's own 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 tool's purpose: generating relationship charts (midpoint composite and Davison chart) for two people. It uses specific verbs and resource names, distinguishing it clearly from sibling tools like synastry.

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 specifies that each person needs date+lat+lon, providing clear input requirements. It does not explicitly state when to use this tool over alternatives, but the purpose is distinct enough to infer 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?

No annotations are provided, so the description carries full burden. It lists output contents (aspects, stations, void-of-course) but does not disclose behavior such as data freshness, ordering, pagination, or computational cost. For a tool with no annotations, this is insufficient.

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

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

The description is concise, using two sentences to convey purpose and content. It could be structured better (e.g., bullet points) but is efficient and avoids redundancy. Every part earns its place.

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

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

Given the absence of annotations and output schema, the description adequately explains the output conceptually but lacks details on exact format, error handling, or limitations. For a tool of moderate complexity, it is minimally viable but not thorough.

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 descriptions for date, zodiac, and window_days. The description adds value by explaining 'window' for stations and the concept of 'void of course', providing context beyond the schema. This enhances understanding despite no explicit parameter mapping.

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 it provides a snapshot of transiting planetary aspects, stations, and void-of-course Moon for a given date. It distinguishes from sibling tools like aspect_patterns and void_of_course by combining multiple features into one 'cosmic weather' overview. The verb 'snapshot' implies retrieval, and the resource is well-defined.

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 for general astrological weather without birth chart or location, which suggests use over personalized tools. However, it does not explicitly name alternatives or provide when-not-to-use guidance, leaving room for ambiguity.

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

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

With no annotations, the description carries full burden. It discloses that default lat/lon make houses and ASC/MC nominal, and lists the return data (positions, houses, retrogrades, aspects). Could mention idempotency or rate limits, but the provided disclosure is sufficient for a read 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 cover purpose, usage, defaults, alternatives, and return types. No unnecessary words, front-loaded with the core action. Highly efficient.

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

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

Given no output schema, the description lists what is returned (positions, houses, retrogrades, aspects). Combined with parameter defaults explanation and sibling tool differentiation, it fully prepares the agent to use 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 coverage is 100%, baseline 3. The description adds value beyond schema: it clarifies longitude east positive, explains the effect of default coordinates (nominal houses), and the date default behavior. This extra context justifies a 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?

The description clearly states it provides the sky for a moment and place, not tied to a person, and explicitly distinguishes from natal_chart. The verb 'use for' and specific resource 'sky/transits right now' make the purpose unambiguous.

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

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

Explicitly tells when to use (current sky, non-birth events) and when not ('for a specific person's birth chart use natal_chart instead'). Also advises to pass a real location if houses matter, providing clear 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 provided, so description carries full burden. Describes input requirements (birth time/place, optional target_date), output details (timeline with UTC start/end, balance, active lords), and defaults (Vimshottari, Lahiri). No mention of destructive actions or authentication; appears to be a read-only computation. No contradictions.

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?

Single paragraph packed with essential information. No wasted words, but slightly dense; could benefit from bullet points for readability. Still efficient and front-loaded with 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?

Covers systems, returns, and prerequisites. Without an output schema, it describes return values adequately. Minor gaps: doesn't explain 'balance of the first period' in detail or the structure of the timeline. Overall sufficient for an experienced user.

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%, but description adds significant value: explains enum values for system (e.g., 'Vimshottari (120-year, the standard)'), clarifies zodiac default ('Sidereal; Lahiri by default'), and describes target_date behavior ('the lords active then — Vimshottari also gives the pratyantardasha'). Greatly enriches parameter understanding.

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

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

Clearly states the tool computes Vedic dasha periods (planetary time-lord cycles) from the Moon's birth nakshatra, specifying three systems (Vimshottari, Yogini, Ashtottari) and what it returns (timeline with UTC start/end, balance, and active lords with target_date). Distinguishes from siblings like firdaria by naming these specific dasha systems.

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?

Does not explicitly state when to use this tool over alternatives (e.g., firdaria, progressions). However, it clarifies prerequisites ('Needs the birth time and place') and describes the scope as Vedic dasha periods, providing implicit context. Lacks exclusion or alternative guidance.

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

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

With no annotations, the description fully discloses behavioral traits: it calculates dignities using Lilly's weighting system, determines planetary sect, and uses Sun altitude for day/night chart. It also clarifies that Mercury's sect is null. This is transparent and consistent.

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 dense paragraph that conveys all necessary information without redundancy. It is front-loaded with the main role, then details output specifics. Minor improvement could be structuring with bullet points, but current form is efficient.

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

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

Given the complexity of astrological calculations and no output schema, the description adequately covers inputs, per-planet outputs, and the day/night determination logic. It omits edge cases (e.g., Sun exactly on horizon) but is sufficiently complete for typical use.

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%, but the description adds semantic value by explaining that 'date' requires UTC ISO 8601, lat/lon are needed to compute day/night, and the 'zodiac' parameter accepts multiple systems. This goes beyond the schema's basic 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 explicitly states it computes essential dignity and sect for the seven traditional planets, detailing per-planet outputs: sign, dignity type, weighted score, peregrine flag, sect, and daytime/nighttime determination. This specificity clearly distinguishes it from sibling tools like natal_chart or aspect_patterns.

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

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

The description explains what the tool does but provides no guidance on when to use it versus alternatives such as chart_signature or yogas. No explicit when-to-use/when-not-to-use criteria or alternative references are given, leaving the agent to infer from context.

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

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

With no annotations, the description carries full burden and discloses key behaviors: time key conversion, output format, optional inter-planetary directions, and condition about circumpolar bodies. Lacks details on error cases but overall 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 a dense but efficient paragraph that front-loads the main purpose and covers mechanism, output, and caveats. Could be slightly better structured but no 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?

Given no output schema, the description describes the return values (arc, age, date) and constraints (circumpolar bodies). It covers the tool's functionality well, though could mention error conditions.

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%, but the description adds meaning beyond schema by explaining the sorting, output details, and the effect of parameters like include_mundane and key.

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 explicitly states that the tool computes primary mundane directions of planets to angles and optionally between planets, which is specific and distinct from sibling tools like transits or progressions.

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 for primary directions but does not explicitly state when to use or not use this tool versus alternatives among 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 discloses sampling, scoring logic (tighter/applying aspects), optional void moon penalty, and return of top moments. It does not detail error handling or performance, but provides sufficient 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?

Three sentences, no redundant information, front-loaded with the core purpose. Every sentence adds value: purpose, method, and limitation. Excellent 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?

Given 7 parameters, no output schema, and no annotations, the description covers the tool's purpose, sampling method, scoring criteria, and a key limitation. It lacks detail on output format but is largely complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond schema by explaining the scoring rationale and how parameters like 'wanted', 'step_hours', and 'avoid_void_moon' are used, justifying a 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?

The description uses a specific verb ('Rank moments') and resource ('window'), clearly distinguishes from sibling tools by stating 'Body-to-body only; for aspects to the angles, compute the chart at a candidate moment.' It fully explains what the tool does.

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

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

The description tells when to use (electional aims) and what not to use for (angle aspects), providing clear context. It does not explicitly name alternatives but implies them by stating to use other means for angles.

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 the key behavior of including retrograde re-hits, which is valuable. However, it does not mention rate limits, side effects, or what happens if no aspects are found.

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

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

The description is two sentences, efficiently stating the purpose, constraint, and additional behavior. No superfluous words, clearly front-loads the key operation.

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

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

For a tool with 7 parameters, high schema coverage, and no output schema, the description covers purpose, parameter choices, retrograde behavior, and naming. It does not describe the return format, but that is partially compensated by the schema. Overall, it is nearly complete given the structured fields.

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

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

Schema coverage is 86% (6 of 7 parameters have descriptions). The description adds important semantic details: the exclusive choice between target_lon and target_body, retrograde inclusion, and naming conventions (snake_case). This goes beyond the schema baseline.

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

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

The description clearly states the tool finds exact dates of aspects by a transiting body to either a fixed longitude or another transiting body. It specifies the action, subject, and targets, distinguishing it from sibling tools like current_sky or transits.

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

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

The description explicitly says 'Provide exactly one of target_lon / target_body' and mentions body naming conventions. It gives clear guidance on the required condition but does not elaborate on when to choose this tool over alternatives like transits.

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

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

With no annotations, the description carries full burden. It transparently discloses that the tool requires lat+lon for sect determination, is purely arithmetic with no zodiac, and returns a timeline. No behavioral surprises.

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 dense paragraph but front-loads the tool's purpose. Every sentence adds value; no redundancy. Could be slightly more structured, but conciseness is appropriate.

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

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

Given no output schema and no annotations, the description adequately covers inputs, behavior, and return expectations. It mentions timeline output and active period lookup. Lacks error or edge case details, but sufficient for typical use.

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%, but the description adds meaningful context: explains why lat+lon are required (sect), that date must be UTC, and target_date looks up active period. Adds value beyond 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 tool computes Firdaria planetary time-lord periods, dividing life into major and sub-periods. It specifies the Persian/medieval origin and differentiates from likely similar tools like 'dasha' by mentioning sect and pure time arithmetic.

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 explains prerequisites (lat+lon for sect) and optional target_date, but does not explicitly guide when to use this tool over siblings like 'dasha' or 'releasing'. Usage context is implied but not explicitly compared.

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 discloses key behaviors: mirror property of Fortune and Spirit, sect-dependent direction reversal, and default zodiac (tropical). It does not describe side effects or permissions, but the tool appears read-only.

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

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

The description is two sentences, front-loading the list of lots and key computation details. Every sentence adds value with 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?

Given no output schema, the description adequately explains the return structure (longitude and zodiacal position per lot). Parameters are well covered. The tool's moderately complex logic is sufficiently described for an AI agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining why lat, lon, and date are required (anchored to Ascendant) and clarifies the zodiac parameter's role. This exceeds what the schema alone provides.

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

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

The description explicitly names all seven Hermetic lots and states that they are cast from the Ascendant with sect-based reversal, clearly distinguishing this tool from other astrological tools like natal_chart or transits.

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

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

It clearly states that an exact time and lat+lon are required because lots are anchored to the Ascendant, providing implicit usage guidance. However, it does not explicitly mention when not to use the tool or suggest alternatives among 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?

No annotations provided; description carries burden. Discloses sidereal by definition and Lahiri default, but does not explicitly state read-only nature or lack of side effects. Provides context on Vimshottari dasha anchoring, but safety implications are unclear.

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?

Single paragraph, front-loaded with definition, each sentence conveys useful information. Could be slightly more structured but is efficient and avoids redundancy.

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

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

No output schema, but description explains return per point in detail. Covers sidereal assumption, default ayanamsa, and significance of Moon's nakshatra. Adequate for an astrological computation tool with moderate complexity.

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

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

Schema coverage 100% means baseline 3. Description adds context that lat/lon/date are needed for Ascendant, but does not elaborate on zodiac parameter beyond schema. Value added is moderate.

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 it computes nakshatra for each classical point (planets and Ascendant), specifying per-point output (name, pada, ruling planet, degrees). It distinguishes from sibling tools like dasha and yogas by focusing on lunar mansion 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?

Explicitly notes sidereal zodiac requirement and Lahiri ayanamsa default. Mentions need for birth time and place for Ascendant. Implicitly guides when to use (nakshatra calculation) vs other tools, but could state alternatives more explicitly.

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?

Even without annotations, the description details the output (positions, aspects, accuracy) and compares accuracy against Swiss Ephemeris, giving agents full understanding of the tool's 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 dense and packed with valuable information, but some structure (e.g., bullet points) could improve readability. However, every sentence serves a 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?

Given no output schema, the description thoroughly covers return values and accuracy. It lacks mention of error handling or date range limits, but overall is highly complete for the complexity.

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

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

All parameters are covered in the schema (100%), and the description adds critical context: conversion of local time to UTC, sign conventions for longitude, and possible values for optional parameters (zodiac ayanamsas, house systems with aliases).

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 for calculating a person's birth chart, distinguishing it from current_sky and listing exactly what it returns (13 bodies, ASC/MC, cusps, aspects). It directly contrasts with the sibling tool current_sky.

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 states 'Use this — not current_sky — whenever the question is about someone's natal/birth chart' and specifies the mandatory inputs (date, lat, lon). Provides clear guidance on when to use.

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

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

No annotations provided, but the description explains the computation method (day/night split, Chaldean order) and discloses the polar circle edge case, providing sufficient behavioral context for a read-only calculation.

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?

Single concise paragraph that front-loads the main purpose and efficiently adds details. Could be slightly more structured, but no unnecessary 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, but description fully covers inputs, output structure, and a critical edge case. For a tool of this complexity, the description is impressively complete.

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

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

Schema coverage is 100%, so baseline is 3. Description adds minor guidance (e.g., convert date to UTC) but does not significantly augment schema meanings.

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 it computes planetary hours for a given moment and place, listing specific outputs (unequal hour ruler, day ruler, full sequence) and distinguishes itself from siblings like current_sky or natal_chart.

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

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

The description implies usage when planetary hours are needed, mentions required parameters (lat+lon) and an edge case (polar circles), but does not explicitly contrast with 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?

No annotations are provided, so the description carries the full burden. It explains the technique's behavior (Ascendant advances one sign per year) and outputs. It does not contradict annotations and adds useful 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 several sentences long but well-structured, front-loading the purpose. Every sentence adds value, though it could be slightly more concise without losing substance.

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

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

Given the complexity of profections and the absence of an output schema, the description adequately explains what is returned and the prerequisites. An agent can correctly invoke the tool based on this description.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema by explaining the significance of Ascendant, whole-sign houses, and lords. It justifies the need for birth time/place.

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 it computes annual and monthly profections at a target date, explaining the technique and what is returned (age, month, profected signs, lords). It distinguishes from sibling time-lord tools like dasha and firdaria.

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 specifies it requires birth time/place for the Ascendant and a target date. It implicitly indicates use for profection computations, but does not explicitly contrast with alternatives or state when not to use.

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

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

With no annotations, the description carries the full burden. It discloses that only longitudes are returned (no houses), and no birthplace is needed, which clarifies computational scope. However, it omits details on potential side effects or required permissions.

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 succinct sentences: first defines purpose and output, second clarifies a limitation. No extraneous words. Highly efficient.

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

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

Without an output schema, the description explains what is returned (three data points per body) and constraints (longitudes only). This is sufficient for an agent to understand the tool's output and requirements, leaving little 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 coverage is 100%, so the schema already describes all parameters adequately. The description adds no new meaning beyond confirming the purpose of each parameter, thus baseline score 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 explicitly states the tool computes secondary progressions and solar-arc directions to a target date, and lists the returned data per body. This clearly distinguishes from siblings like 'transits' or 'directions'.

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 does not provide explicit guidance on when to use this tool versus alternatives like 'transits' or 'returns'. The purpose is clear, but an agent could benefit from context on when progressions are appropriate.

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

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

With no annotations, the description fully explains the sweep behavior: it iterates over UTC hours within a window, ignores the date's time component, and reports ASC sign-change times. It does not mention destructive actions, but given the context, it is read-only. No contradictions.

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 extremely concise: two sentences that front-load the purpose and then provide usage and behavioral details. Every sentence is necessary and informative.

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

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

Given no output schema, the description adequately explains the sweep mechanism and parameter relationships. It does not detail the return format, but the core functionality is clear. For a tool with 6 parameters and no output schema, this is sufficient.

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 clear descriptions for all 6 parameters. The description provides overall context (sweep over window, date ignored) but does not add significant detail beyond the schema for individual parameters. Baseline 3 is appropriate.

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

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

The description clearly states the tool performs a rectification sweep returning ASC/MC positions and ASC sign-change times across a UTC hour window. This distinguishes it from sibling tools like natal_chart or transits, which are for known birth times or other purposes.

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

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

The description explicitly says 'Use when the birth time is unknown and you want candidate times,' providing clear context for usage. It does not explicitly mention when not to use, but the sibling context implies 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?

No annotations provided, so description carries full burden. It explains mechanics: sign-by-sign release, planetary minor-year lengths, 360-day year, levels L1-L4, loop jump rule, and output details for timeline and active lords. Does not mention side effects or destructive actions, but it is a read-only calculation.

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 well-structured, front-loading the technique name and source. Every sentence is informative, though it could be slightly more concise by separating output description. Overall appropriate for the complexity.

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 8 parameters and no output schema, the description covers technique, mechanics, and output (timeline and active lords). It could detail the return structure more, but it provides sufficient context for an agent to understand the tool's operation.

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%, baseline is 3. The description adds valuable context beyond the schema, explaining the technique (e.g., Lot parameter's role, meaning of max_level and target_date) and how parameters interact, such as the loop and jump rule.

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

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

The description clearly states it implements the zodiacal releasing technique from Vettius Valens, with specific verb 'releasing' and resource definition. It distinguishes from siblings by mentioning Hellenistic origin and mechanics different from dasha or firdaria, but does not explicitly contrast 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?

The description implies usage for natal astrology anchored to a Lot, requiring exact time and coordinates. However, it does not provide explicit when-to-use or when-not-to-use guidance compared to sibling time-lord tools like profections or dasha.

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 discloses that it returns instants and the full chart for the first return, and explains location defaults. It is transparent about the output but could mention more about the structure of the chart.

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

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

The description is concise with 4 sentences, no wasted words, and front-loaded with the essential purpose first.

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

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

Given no output schema, the description partially covers return values (instants and full chart) but lacks details on chart format. Adequate but not fully complete for a 10-parameter 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 coverage is 100%, so baseline is 3. The description adds minimal parameter-specific meaning beyond the schema, mainly explaining the concept of returns.

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 it computes solar or lunar returns, specifying the Sun returns yearly and the Moon monthly. It distinguishes from siblings by focusing on return charts.

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 for yearly or monthly returns but lacks explicit when-not-to-use or alternatives among siblings. It provides some context but no exclusion guidance.

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

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

With no annotations, the description carries full burden. It describes the algorithm (cosine similarity, 1.0=identical) and return order (top matches, highest first). It does not disclose rate limits or data source details, but it is reasonably 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?

Three sentences, each serving a distinct purpose: purpose, method, and output. No redundant information. Highly efficient and 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?

No output schema, so the description only vaguely mentions returning top matches with similarity. It does not specify exact fields or what happens if no matches. Adequate but not fully complete for a tool with 5 parameters and no output schema.

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

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

Schema coverage is 100%, so each parameter has a description. The description adds context by explaining how parameters relate (e.g., reference_date as target, start/end as window) but does not add significant meaning beyond the schema.

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

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

The description clearly states the tool's purpose: 'Find when the sky most resembled a reference moment.' It explains the method (feature vector, cosine similarity) and usage scenarios (transit echoes, historical analogues). This distinguishes it from sibling tools like current_sky or sky_events.

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 a clear use case: 'Answers when did the sky last look like this?' It implies when to use but lacks explicit when-not or alternative tools. The context is clear but not comprehensive.

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?

Given no annotations, the description carries the full burden. It discloses accuracy ('times to the second vs Swiss Ephemeris, stations to ~1 min') and the range constraint. It does not cover auth or rate limits, but these are less critical for this tool's nature.

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

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

The description is concise and well-structured, using a bullet-like format with parentheses for conditions. Every sentence adds necessary detail without redundancy, making it easy to scan.

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

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

The description covers event categories, parameter requirements, accuracy, and range limit. However, it lacks details on the output format (e.g., what fields are returned for each event) and does not mention pagination or limits. Given the tool's complexity, additional guidance would be helpful.

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 covers 100% of parameters, baseline 3. The description adds value by explaining which parameters are required for each event type (e.g., lat/lon for rise/set, target_lon for crossing) and clarifies defaults like zodiac. This goes beyond the schema's 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 tool returns sky events in a UTC date range, listing specific event types like rise/set/transits, lunar phases, eclipses, stations, and zodiac degree crossings. It distinguishes from siblings implicitly by focusing on time-range events rather than instant positions or aspects.

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

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

The description provides clear context on when each event type is available, e.g., 'need lat+lon+body' for rise/set/transit, and notes the range limit of 370 days. However, it does not explicitly compare to sibling tools or state when not to use this tool.

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

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

With no annotations, the description carries full burden. It discloses a constraint: 'House overlays always use Placidus (not configurable here)'. However, it does not state whether the tool is read-only, any required permissions, or side effects. Basic behavioral info present but not comprehensive.

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 succinct sentences with key information front-loaded. Every sentence adds value: purpose, requirements, and a constraint. No redundancy or unnecessary details.

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

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

The description covers core functionality but lacks details on return format (no output schema). For a complex tool with multiple outputs (aspects, house overlays), more information on what exactly is returned would complete the picture. Adequate but not exhaustive.

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 each parameter having a description. The tool description adds only a general note about Placidus house system but no extra per-parameter meaning. Baseline 3 is appropriate as 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 clearly states 'Compare two people's birth charts' and specifies outputs: 'inter-chart aspects with orbs, house overlays both ways'. This distinguishes it from siblings like natal_chart (single chart) and transits (transits to a chart), which are different operations.

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 tells when to use (comparing two charts) but does not provide explicit 'when not to use' guidance or mention alternatives like natal_chart or synastry vs. composite charts. Context is clear but lacks exclusions.

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

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

With no annotations, the description must disclose behavioral traits. It states what is computed (aspects and houses) but does not mention side effects, prerequisites (e.g., stored natal chart), rate limits, or whether it is read-only. This is insufficient for a tool with 7 parameters.

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, front-loaded sentence of 14 words. Every word adds meaning, and there is no redundancy or wasted content.

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

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

Given the complexity (7 params, no output schema, astrology domain), the description adequately outlines the main outputs (aspects and houses) but lacks detail on exact return structure, aspect types, or whether house cusps are included. It is minimally complete.

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

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

Schema coverage is 100% with detailed descriptions. The description adds value by clarifying that 'transit_date' should be omitted for now, and by explaining the output (aspects and houses) which grounds param usage. This goes beyond the baseline 3.

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 it computes aspects between transiting planets and a natal chart, including applying/separating orbs and natal house placements. This distinguishes it from siblings like synastry (two natal charts) or current_sky (current positions only).

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 explicit guidance on when to use this tool vs alternatives like returns or progressions. Usage is implied by the name and description, but sibling tools exist (e.g., directions, returns) that could overlap, and no exclusions or prerequisites are mentioned.

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 adequately discloses output format (divisional sign and division number per point), sidereal nature, and dependency on birth data. Does not cover edge cases like missing time but is generally 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?

Information is front-loaded and covers key aspects, but the single paragraph is slightly long. Could be tightened without losing clarity.

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 complexity (multiple charts, no output schema), the description explains output format and essential prerequisites. Adequate for an agent to understand what the tool returns and needs.

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 is fully described, but description adds value by naming the vargas (e.g., D9 navamsa) and emphasizing the need for birth data for Ascendant, enhancing parameter understanding beyond the schema.

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

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

The description explicitly states it returns Parashari divisional chart data for seven planets and Ascendant across specific D-charts (D1 to D30), which clearly differentiates it from sibling tools like natal_chart.

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

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

Provides context that navamsa (D9) is most consulted, mentions default ayanamsa (Lahiri), and prerequisites (birth time/place for Ascendant). Lacks explicit when-not-to-use or alternative tools, but clear enough.

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

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

No annotations are provided, so the description carries the full burden. It explains what the tool returns and the default zodiac, but does not discuss potential errors, authentication, or side effects. Adequate but not exhaustive.

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

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

The description is concise, with three sentences that efficiently convey the tool's purpose, return values, and default setting. No unnecessary words.

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 output schema, the description clearly states what is returned (Moon's sign, UTC times). The input schema is fully covered. The description is sufficient for an agent to understand 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 coverage is 100%, so the baseline is 3. The description adds context about the tool's purpose but does not enhance parameter descriptions beyond what the schema provides.

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

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

The description clearly defines the tool's purpose: determining if the Moon is void-of-course at a given moment, and specifies the return values. It distinguishes itself from sibling tools by focusing on a specific astrological concept.

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 does not provide guidance on when to use this tool versus alternatives (e.g., find_aspect_dates, sky_events). No explicit when-to-use or when-not-to-use advice is given.

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 full burden. It describes what the tool computes but does not disclose behavioral traits like whether it is read-only, requires authentication, or has side effects. For a computation tool, at least stating it is non-destructive would be helpful.

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 moderately long but efficient; lists yogas without excess words. It is front-loaded with the main purpose. Could be slightly more structured but overall concise.

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 complexity (4 params, many yoga types, no output schema), the description covers the input and computation well but lacks description of the output format or what the response contains. This is a gap for an agent to understand return value.

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 baseline is 3. The description adds context about sidereal and Lahiri default (matching the zodiac param) but does not elaborate on other params beyond the schema. It adds marginal value.

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 explicitly states the tool computes Vedic yogas (planetary combinations) on the sidereal rasi chart, listing specific yogas such as Pancha Mahapurusha, Gajakesari, etc. It clearly distinguishes from sibling tools like natal_chart or dasha by focusing on yoga calculations.

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

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

The description mentions the tool needs birth time and place, which aligns with required parameters. However, it does not explicitly advise when to use this tool vs. alternatives like natal_chart or dasha, nor does it state when not to use it.

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