AstroWay Human Design

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds that it returns a 'plain-text human-readable summary' and clarifies the budget-checking purpose, providing useful context beyond annotations.

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

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

Three efficient sentences: purpose, usage guidance, and return format. Front-loaded with key information, no wasted 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 lacking an output schema, the description specifies the return format (plain-text human-readable summary). For a simple status check tool, this is complete and 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?

Tool has zero parameters, so schema coverage is 100%. Description does not need to explain parameters, and it adds value by hinting at the output format.

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?

Description clearly states the verb 'Check' and the resource 'API key status' with specific attributes (tier, credit balance, rate limits, monthly cycle reset). It distinguishes itself from the many sibling astrology calculation 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?

Explicitly instructs to run this tool BEFORE invoking expensive endpoints, providing credit thresholds (Tier 4+ at 100+ credits, Tier 6/7 at 500-5000 credits) to confirm budget.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds genuine behavioral context beyond them: executors are kept out of the vendor objects because an unexpected key causes a 400 on the vendor side, and cost is flagged as not in the public credit manifest. That is real operational value.

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?

Roughly three sentences, front-loaded with the purpose before the format and executor caveats. It is dense but each sentence carries information, though the format explanation partially duplicates the schema's own enum description.

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

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

With an output schema present and full annotation coverage, the description need not explain return values, and it appropriately focuses on the vendor-shape contract and the executors/400 gotcha. It is nearly complete, with the only gap being sibling disambiguation rather than missing operational detail.

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

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

Schema description coverage is 100%, so the schema already documents every parameter in depth (limit ceiling rationale, select values, precision semantics). The description only restates format and its default, adding no parameter meaning the schema lacks. Baseline 3 is correct.

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 what the tool returns: tool definitions for an agent framework, generated from the live OpenAPI document. It is specific about the resource and the vendor-shape variants (openai vs anthropic objects). However, it never distinguishes this from the near-identical sibling astroway_mcp_tools_list, which an agent would plausibly confuse it with.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative-naming guidance. The mention that openai objects 'spread straight into a chat completion' implies a use case, but the agent is left to infer when this endpoint is preferable to astroway_mcp_tools_list or the MCP tool-call streaming siblings.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety bar is low; the description still adds real value by clarifying that endpoints are NOT invoked and that results are cached with a 5-minute TTL. It also discloses the return shape (total + per-endpoint breakdown with tier annotations), which is meaningful since no output schema exists.

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

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

Three tight sentences, front-loaded with the core capability and the non-invocation guarantee, followed by workflow guidance and the cache note. Nothing is wasted.

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

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

Despite having no output schema, the description explains the return value, and the invocation-free and cache behaviors are covered. For a one-parameter, read-only estimator this is fully 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 description coverage is 100% and the single 'endpoints' parameter is fully documented with examples and the leading-slash rule in the schema. The description only restates 'one or more endpoints' without adding format or constraint detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Estimate the credit cost of one or more endpoints') and immediately pins the scope with 'WITHOUT invoking them', which no sibling tool does. An agent can distinguish this from the many invocation/report siblings at a glance.

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

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

Gives explicit workflow guidance: 'estimate first, ask user confirmation, then invoke' for multi-step planning. This is clear when-to-use context, though it names no alternative tool or when-not-to-use condition.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the POST endpoint, credit cost (20 credits, Tier 2), and grouping, letting the agent reason about budget and scope. It does not describe computation nuances, but the output schema covers return values.

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

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

Front-loaded single sentence stating the purpose, followed by compact metadata lines (group, endpoint, required, cost). Nothing is padded, though the bracketed metadata is boilerplate rather than description prose.

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

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

With 15 parameters and low schema description coverage, a complex HD computation tool, and many sibling tools, the description is thin: it omits which optional parameters matter, how chart inputs interact, and how this output relates to other HD endpoints. The existing output schema and annotations cover returns and safety, but the parameter and routing gaps leave it under-specified.

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

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

Schema description coverage is only 33% across 15 parameters, so the description should compensate. Instead it merely restates the four required parameters (date, time, latitude, longitude) that the schema already marks required, adding no meaning for the 11 optional parameters (ayanamsa, timezone, fields, precision, houseSystem, zodiacType, etc.).

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 ('Analyze') and resource ('Circuits and Sub-circuits activated in a Human Design chart'), including the enumeration of 3 circuits and 6 sub-circuits and the basis ('defined channels'). It is distinguishable from related HD siblings, though it does not name which sibling reads the underlying channels/hologenetic data, so the boundary is implicit rather than explicit.

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

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

No when-to-use guidance, no statement of when this is preferable to siblings such as astroway_hd_hologenetic or astroway_hd_human_design, and no prerequisites or exclusions. The only situational information is the required-parameter and cost metadata, which is not usage guidance.

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

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is not carrying that burden. It adds the credit cost (10 credits, Tier 1) and the HTTP endpoint, which are genuinely useful decision inputs not present in structured fields. It does not describe latency, failure modes, or what the returned date/body looks like.

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 concept is front-loaded in one dense, well-formed sentence, followed by a compact bracketed metadata block. There is little wasted text, though the required-parameters line duplicates the schema's required array and adds no information.

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

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

With 15 parameters, three enums of non-obvious values, and only 33% schema coverage, the definition is thin for a tool of this complexity. An output schema exists, so return values need not be explained, but the description never clarifies how the many optional configuration parameters affect the computed Design date, nor whether they matter for this endpoint at all.

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

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

Schema description coverage is only 33%, so the description must compensate, and it does not. It merely repeats the four required parameters already declared in the schema's required array, leaving cryptic optional inputs such as houseSystem (single-letter enum values P, K, R...), zodiacType, cosmogram, ayanamsaId and fields unexplained.

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

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

The description gives a specific verb (Find) plus a precisely defined resource: the Design date, explicitly glossed as 'the moment 88° of solar arc before birth' and 'the unconscious imprinting point'. That is far more than a restatement of the name. It does not, however, distinguish this from siblings such as astroway_hd_human_design, which likely also surfaces a Design date.

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

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

There is no statement of when to use this tool versus the many HD siblings, nor any prerequisites or exclusions. The bracketed block lists required params and cost, which is operational metadata rather than usage guidance. An agent must infer the use case entirely from the concept definition.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, closed world), so the bar is lower. The description adds genuinely useful non-annotation context: the POST endpoint, the credit cost (50 credits, Tier 3), and which inputs are mandatory, which matters for budgeting and for a metered API.

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 one-sentence purpose is front-loaded and followed by compact bracketed metadata; nothing is padded. The metadata lines are terse and skimmable, though they could be folded more tightly.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. However, for a 15-parameter metered tool at 33% schema coverage, the definition leaves the agent without guidance on which optional parameters matter for a Dream Rave computation or when this chart is the right call, making it minimally viable rather than complete.

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

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

Schema description coverage is only 33% across 15 parameters, so the description is expected to compensate. It only restates the four required fields, which the schema's own 'required' array already conveys, and says nothing about timezone/timezoneOffset handling, ayanamsa, houseSystem, fields, or precision for this chart type.

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 ('Calculate the Dream Rave chart') and enumerates the distinctive outputs (sleep type, active gates in lower centers, dream themes), which separates it from neighboring HD tools like astroway_hd_human_design or astroway_hd_hologenetic. It stops short of explicitly naming when a sibling is the better choice, so it is clear-but-not-disambiguating.

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

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

The only operational guidance is the [Required] and [Cost] metadata lines; there is no statement of when to reach for Dream Rave versus other HD charts, no prerequisites, and no exclusions. The '[Group: Human Design]' tag groups it but does not route the agent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful non-schema facts—endpoint, credit cost of 100 (Tier 4)—but says nothing about auth, rate limits, or how the collective overlay is derived from the inputs.

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

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

One front-loaded sentence followed by a compact metadata block (group, endpoint, required, cost) that earns its space by carrying cost and routing information. No filler or restated boilerplate.

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

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

An output schema exists, so return-shape explanation is not required, and cost/endpoint are covered. What is missing is the decision context for a tool that sits among several multi-person HD tools: no trigger conditions, no contrast with compatibility or penta, and only a vague hand-wave at what 'collectively defined centers and channels' means in the result.

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 67% and the nested birth-data object is documented in depth by the schema itself. The description contributes only '2 or more people', which matches the array's minItems: 2, and '[Required: inputs]'; it explains nothing about fields, precision, or the per-person parameters.

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

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

States a specific verb+resource ('Calculate a combined HD group overlay chart') and scopes it to '2 or more people, showing collectively defined centers and channels', which is enough to separate it from single-chart siblings. It does not explicitly name the nearest alternatives (compatibility, penta), so sibling differentiation is implied rather than stated.

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

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

The description never says when to pick this over astroway_hd_human_design_compatibility, astroway_hd_penta, or astroway_hd_hologenetic for a multi-person reading. The only adjacent guidance is the bracketed '[Required: inputs]' and cost tag, which are prerequisites, not usage 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-derived operational context: the endpoint, the credit cost (50 credits, Tier 3), and the mandatory inputs — the cost tier in particular is a real selection signal an agent would not otherwise have.

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: purpose first, structured metadata second. Zero filler. The bracket block is dense but each line (group, endpoint, required, cost) carries information, so nothing is wasted.

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

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

For a 15-parameter, high-complexity domain calculation, the description covers purpose and cost but leaves the parameter space largely unexplained and gives no guidance on how the hologenetic profile relates to the other HD tools. An output schema exists, so return-shape detail is fairly excused, but the usage and parameter gaps keep this at minimum-viable.

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

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

Schema description coverage is only 33% across 15 parameters, and the description compensates only by restating the four required fields that the schema already marks required. It adds nothing about ayanamsa, zodiacType, houseSystem, fields, precision, or the timezone vs timezoneOffset tradeoff, which are the parameters most likely to be misused.

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 ('Calculate the Gene Keys hologenetic profile') and names the concrete sub-outputs (Activation, Venus, Pearl Sequence) and the input basis (HD gate activations). An agent can tell this apart from astroway_hd_human_design or astroway_hd_circuitry without opening the schema.

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

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

No when-to-use guidance, no conditions or prerequisites, and no explicit routing to or away from any of the many sibling HD tools. The bracketed block lists required inputs and cost, which are facts about invocation rather than selection guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds genuinely new operational context: cost (50 credits, Tier 3), the POST endpoint, the required inputs, and a stability guarantee for the centre identifiers. The identifier-stability promise in particular is behavior the schema cannot express.

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 purpose is correctly front-loaded in the first sentence, but the second and third sentences spend most of the budget on output identifier spelling and a tangent about localised names on an unrelated /public/moon-phase endpoint, which does not help an agent invoke this tool. The bracketed metadata block is dense but useful.

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

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

An output schema exists, so the description need not explain return values, yet it largely re-explains them (centre names) instead of covering the gaps: sibling routing and the semantics of the 11 undocumented optional inputs. Required parameters and cost are covered, so it is adequate but not complete for a 15-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 description coverage is only 33% across 15 parameters, so the description must compensate and it does not. It documents output identifiers rather than inputs, saying nothing about ayanamsa, ayanamsaId, zodiacType, houseSystem, precision, fields, cosmogram, timezone vs timezoneOffset precedence, or name/city defaults.

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 ('Calculate a full Human Design BodyGraph chart') and then enumerates the exact outputs: type, strategy, authority, profile, definition, incarnation cross, centers, channels, gate activations. An agent can distinguish this from the focused siblings (circuitry, incarnation cross, compatibility) without opening any schema.

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

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

The word 'full' weakly implies this is the comprehensive base chart versus the narrower hd_* siblings, but there is no explicit when-to-use statement, no named alternative, and no exclusion. With 14+ sibling tools in the same Human Design family, the agent is left to infer routing entirely on its own.

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

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

The annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful operational context not in annotations: the HTTP endpoint and a credit cost (100 credits, Tier 4). It does not add anything about latency, rate limits, or failure modes, so it falls short of 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?

The purpose sentence is front-loaded and dense with specifics, and the bracketed metadata lines are short and scannable rather than prose filler. Slightly more framing than strictly necessary, but nothing wastes the agent's attention.

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

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

With a rich input schema, an output schema (so return values need no explanation), and full annotations, the description only needs to establish purpose, cost, and endpoint — which it does. The main remaining gap is routing guidance relative to sibling HD tools, which is what keeps it from a 5.

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

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

Schema coverage is 100%, including very rich nested descriptions for chart1/chart2 (date/time formats, lat/lon, timezone handling, houseSystem letters) plus fields and precision. The description only restates the two required params, adding no meaning beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb (calculate), a specific artifact (Human Design connection chart), and the exact scope (between two people), then enumerates the four channel types returned. This distinguishes it clearly from sibling overlay/group tools such as astroway_hd_group_overlay and astroway_hd_penta, which are not pairwise.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative. The description tells the agent what the tool computes but leaves it to infer that this is the pairwise-compatibility tool rather than, say, a group overlay, and says nothing about prerequisites beyond the required-params note.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful operational context the annotations cannot: the cost (50 credits, Tier 3) and the underlying endpoint. It still says nothing about latency, size of the returned activation set, or whether the transit moment defaults to now.

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 front-loaded sentences carry the whole functional story, with the optional overlay stated second. The bracketed metadata lines are compact and each adds information (group, endpoint, cost) rather than restating the name, so nothing is wasted.

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

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

With a rich nested input schema at 100% coverage, an output schema for return values, and annotations covering the safety profile, the description only needed to state purpose, optional overlay, and cost — which it does. It is marginally thin on when the tool should be preferred over the adjacent HD tools, but nothing required to call 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?

Schema description coverage is 100%, so the schema already documents date/time/lat/lon, timezone handling, ayanamsa, houseSystem and the natal overlay fields. The description only echoes the overlay capability and adds no syntax, format, or defaulting detail beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb and resource ('Calculate ... Human Design transit activations') and adds scope ('optionally overlay on natal chart to show combined defined centers and channels'), which separates the overlay mode from a plain transit read. It does not name any sibling such as astroway_hd_design_date or astroway_hd_group_overlay, so an agent must infer the boundary itself. The word 'current' is also slightly at odds with a tool whose body requires an explicit date and time.

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

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

'Optionally overlay on natal chart' implies the two modes of use, so the agent can infer when to supply natalDate/natalTime. However, there is no explicit when-to-use guidance, no exclusion (e.g. group vs single-chart overlays), and no pointer to the sibling tools that cover adjacent Human Design operations.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for adding operational facts beyond them: the 50-credit Tier 3 cost, the POST endpoint, and the deterministic line/profile rule that decides right-angle vs juxtaposition vs left-angle. It does not describe failure modes or what happens when conflicting inputs (birth data plus gates) are supplied.

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

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

Two tight sentences front-load the outcome, the input modes, and the returned components, followed by a compact bracketed metadata block for group, endpoint, required fields, and cost. Nothing is padded or repeated.

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 15 parameters and low schema description coverage, this is thin, but the presence of an output schema removes the obligation to explain return values, and the metadata block supplies cost/endpoint/required fields. The gate-number input path mentioned in prose but absent from the schema is a real 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 only 33% across 15 parameters, so the description would need to carry weight, and it does not — it names the four required fields and nothing else. Worse, it references inputs ('gate numbers', 'personalitySunLine', 'designSunLine') that do not appear anywhere in the input schema, which risks confusing an agent about how to trigger the alternate mode.

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 gives a specific verb and resource ('Return the Incarnation Cross') and names the two input modes (birth data or gate numbers), plus what the result contains (name, type, theme). It does not explicitly differentiate itself from nearby siblings such as astroway_hd_human_design or astroway_hd_hologenetic, which presumably also derive from birth data, but the resource itself is 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?

It implies two usage paths ('from birth data (or directly from gate numbers)'), which is a useful fork, but never states when to prefer this tool over the other Human Design endpoints or any exclusions/preconditions. Usage has to be inferred from the domain.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds behaviorally relevant metadata the annotations do not carry: the credit cost (100 credits, Tier 4), the POST endpoint, and the required parameter set, all of which help an agent decide whether the call is worth making.

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

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

The core sentence is front-loaded and wastes no words, and the bracketed metadata lines are compact and skimmable. The bracketed block is somewhat boilerplate-heavy, but it does not bury the functional description.

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

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

With an output schema present, return values need not be described, and the description covers scope, cost, endpoint and required input adequately for a computation tool. The remaining gap is sibling disambiguation against the other group/overlay tools, which leaves an agent to infer the boundary.

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

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

Schema description coverage is 67% and the nested input-object schema is unusually detailed (timezone vs timezoneOffset semantics, houseSystem letter codes, whitespace/alias rejections). The description only restates that inputs is required and that the list holds 3–5 people, both already encoded in required/minItems/maxItems, so it adds little beyond the schema.

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

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

States a specific verb and resource ("Calculate the Penta (group) chart") plus a concrete scope constraint ("3–5 people") and what it produces ("combined BodyGraph showing group dynamics and collective conditioning"). It stops short of differentiating itself from close siblings like astroway_hd_group_overlay, which an agent could easily confuse with a group-chart tool.

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

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

The 3–5 person constraint implicitly tells the agent when this tool is applicable, but there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as astroway_hd_group_overlay or astroway_hd_human_design_compatibility, which also handle multiple people.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the 50-year range limit, the credit cost (10 credits, Tier 1), and the endpoint. It stops short of describing failure behavior for out-of-range requests, 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?

Front-loads the purpose sentence, then uses a compact bracketed metadata block for group, endpoint, required fields, and cost. No wasted prose. Slightly fragmentary but every element earns its place.

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

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

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description supplies purpose, cost, range constraint, and required inputs, leaving only year-input semantics unstated. Complete enough for correct invocation of a simple two-parameter range calculator.

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

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

Schema coverage is 50%: fields and precision are documented in the schema, while startYear/endYear carry no field-level description. The description names them as required and ties them to the 50-year range cap, but adds no format or boundary semantics (accepted year range, BC handling, ordering). Adequate but does not fully compensate for the coverage gap.

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

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

States a specific verb ("Calculate") and resource ("Rave New Year dates"), then pins the concept precisely as "the exact moment Sun enters Gate 41". That definition clearly distinguishes it from sibling design-date and transit tools without needing to name them.

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

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

The "Max range: 50 years" constraint gives a usable boundary, but there is no explicit when-to-use or when-not-to-use guidance relative to siblings like astroway_hd_design_date or astroway_hd_dream_rave. Usage is only implied by the distinctive purpose statement.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is low; the description adds the useful facts that the result is a stability/transition window analysis and that the call costs 50 credits (Tier 3) at POST /v1/hd/sensitivity. It stops short of saying how the perturbation is performed (step size, range of minutes), which is the one behavior an agent would want to know.

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

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

Two tight sentences with the purpose front-loaded, followed by compact metadata lines for group, endpoint, required fields and cost. The required-fields line duplicates the schema's required array, a minor redundancy, but nothing else is wasted.

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

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

An output schema exists, so return-value explanation is not needed, and the safety profile is covered by annotations. However, for a 15-parameter tool at 33% schema coverage, the description leaves the agent unable to tell which optional parameters matter for an HD-type sensitivity run, and it never defines what a 'window' or 'transition' means quantitatively.

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?

15 parameters with only 33% schema description coverage, and the description adds no parameter meaning at all beyond restating the four required fields already declared in the schema's required array. The many optional astrology parameters (zodiacType, houseSystem, ayanamsa/ayanamsaId, cosmogram, precision, fields) are left undocumented here, and the description gives no hint which of them actually influence an HD sensitivity result.

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: analyzing HD chart type/authority sensitivity to birth-time changes, and even previews the return shape ('windows where the chart is stable vs. in transition'). It is clearly distinct from sibling chart-computation tools like astroway_hd_human_design, though it never names an alternative to differentiate against.

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

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

Usage is implied rather than stated: an agent can infer this is for validating whether a known birth time is precise enough to fix HD type/authority, but there is no explicit when-to-use, when-not-to-use, or pointer to a sibling when sensitivity is irrelevant.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful operational context — cost (100 credits, Tier 4), the required-parameter set, and the endpoint. It stays silent on runtime behavior an agent might care about, such as whether the multi-round debate is long-running, streamed, or bounded in output size. The POST endpoint is not a contradiction of readOnlyHint, but it is worth noting.

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?

Tight and well front-loaded: the core operation comes first, then compact bracketed metadata. Every line carries information (endpoint, required fields, cost) rather than filler. Its brevity is a virtue, though it edges into under-specification.

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

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

An output schema exists, so return values need not be described. But for an 8-parameter tool with a nested chart object, aless-than-40% coverage, and a cost of 100 credits, the description leaves critical gaps — most importantly the semantics of agentA/agentB and the effect of rounds/language.

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

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

Schema description coverage is only 38%, so the description carries a heavier burden, and it does not meet it. It restates the three required parameters that the schema already marks as required, but never explains what agentA/agentB actually are (persona strings? model IDs?) or what topic expects. Optional params like rounds, language, and fields get no mention.

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?

Uses a specific verb-and-resource phrasing: '2 personas debate a topic, multi-round transcript.' An agent can grasp the operation immediately. However it does not differentiate itself from close siblings such as astroway_mcp_multi_agent_coordinate, astroway_mcp_ai_chat, or astroway_mcp_ai_comparison_coach, which plausibly overlap.

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

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

There is no when-to-use guidance and no named alternative. The bracketed metadata lists required fields and cost but never says when this debate tool is preferable to multi-agent coordination or AI chat. The [Group: MCP Advanced] tag is organizational, not decision-supporting.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false, and openWorldHint false. The description adds useful behavioral context in the form of the cost (10 credits, Tier 1) and HTTP method (GET), but does not describe what the status output contains or any auth/rate-limit details.

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

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

The text is short but poorly structured: a vague fragment followed by bracketed metadata lines. It is under-specified rather than concise, and the opening line does not front-load a clear 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?

Although an output schema exists and annotations cover the safety profile, the description still leaves the agent without a clear statement of what the tool does or when to call it. For a status endpoint in a large sibling set, this is a significant omission.

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

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

Schema description coverage is 100%, so the two optional parameters (fields, precision) are fully documented in the schema itself. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description gives only a fragment, '8 personas with specialties,' which hints at pool composition but never states that this tool returns agent pool status or what that status contains. It lacks a clear verb and resource, and does not distinguish itself from siblings like astroway_mcp_multi_agent_coordinate or astroway_agent_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?

There is no guidance on when to use this tool, when not to use it, or which sibling tool is the alternative. The description contains only metadata tags, not usage instructions.

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

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

Annotations already declare read-only, non-destructive, open-world behavior, so the bar is lower; the description still adds real behavioral facts beyond them — a 10-turn history ceiling, 21 output languages, four selectable voices via persona, and a concrete pricing rule (5 credits with your own provider key vs. the endpoint price). It stops short of stating auth requirements or what happens when the history limit is exceeded. No contradiction with annotations.

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

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

Three tight sentences: the differentiator first, capabilities second, pricing last, followed by a compact metadata block (group, endpoint, required param, tier cost). Every clause carries new information and nothing is repeated from the schema.

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

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

With an output schema present the description needn't explain return values, and annotations cover the safety profile, so what remains — what the tool is for, its capability envelope, and its cost model — is covered. The main gap is that nothing tells an agent when this endpoint should be picked over the other AI/agent siblings.

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

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

Top-level schema description coverage is only 43% (chart, fields and precision documented; message, persona, language and history not), so the description must compensate and partially does — it explains persona (four voices), history (~10 turns) and language (21 options). It says nothing about chart, fields compact-mode paths, or precision, though the nested chart schema does carry unusually rich self-documentation for those.

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 — an AI chat answered from computed natal-chart positions rather than the model's prior knowledge of a sun sign — and quantifies scope (10 turns, 21 languages, 4 personas). It clearly implies a different product from sibling AI utilities such as astroway_mcp_ai_explain_aspect or astroway_mcp_ai_comparison_coach, but never names them, so the differentiation is by tone rather than 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?

Usage context is implied rather than stated: the credit-price note ('send your own provider key and the turn costs 5 credits instead of the endpoint price') hints this is a paid, higher-tier call, and 'chart-grounded' hints the input needs birth data. There is no explicit when-to-use-it, when-not-to, or routing rule against the other chat/agent endpoints in the sibling list.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely useful operational context (the 100-credit Tier 4 cost and the POST endpoint), but says nothing about the fact that an LLM-backed coach may return non-deterministic prose, what latency to expect, or what deprecates the idempotentHint=false signal.

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 four lines are tight and the purpose sentence is front-loaded ahead of the bracketed metadata block. Nothing is padded, though the metadata lines are boilerplate rather than definitional 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?

An output schema exists, so return values need not be explained, and the cost/endpoint block is present. But for a six-parameter AI tool embedded among dozens of similar compatibility siblings, the description lacks any hint of what the coaching output contains or what makes a good 'question', leaving the agent to guess at scope.

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

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

Schema description coverage is 67% and the nested chart objects carry extensive inline documentation (formats, rejected short names, timezone semantics, houseSystem letters), so the schema does the heavy lifting. The description only restates the required parameters (chart1, chart2, question), adding no meaning for question, language, fields or precision. 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 names a specific verb (coach), the resources (two charts) and the domain (relationship dynamics), so the agent knows this produces interpretive guidance rather than raw chart data. It does not, however, distinguish itself from the many sibling compatibility tools (ashtakoot, dashakoota, compatibility_full) or from astroway_mcp_ai_chat, so sibling differentiation is left to inference.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative is named. A reader cannot tell whether to reach for this AI coach versus the deterministic Vedic compatibility endpoints or multi_chart_context. The only constraints given are required parameters and cost, which are not usage guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false, so the safety profile is covered without the description. The description does add genuinely useful operational context not present in the annotations: the credit cost (100 credits, Tier 4) and the endpoint. However it never explains why a read-only operation is flagged non-idempotent (repeated calls likely yield differently worded narrative), which is the one behavioral trait an agent would most want 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 purpose sentence is front-loaded and the payload is small. The '[Required: planet1, planet2, aspectType]' line duplicates the schema's required array, but the cost and endpoint lines justify their space.

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

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

An output schema exists, so return values need not be described. But for a 7-parameter tool with a nested chart object and LLM-backed generation, the description omits the valid domain for planet1/planet2, any usage guidance versus explain_transit, and any hint about generation latency or variable output.

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 lists the three required parameters, but schema coverage is only 43% and planet1/planet2 carry no description, no enum and no example anywhere in the schema, so the agent must guess the accepted form (planet names such as 'Mars'?). The description does not compensate for that gap, which is the weakest part of the definition.

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

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

Names a specific verb and resource: 'explanation of an aspect between two planets.' An agent can tell it apart from the sibling astroway_mcp_ai_explain_transit by the resource alone, but the description never makes that contrast explicit nor states what kind of explanation is produced.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the sibling explain_transit as an alternative. The only contextual cues are bracketed metadata (endpoint, required fields, credit cost), which tell the agent what it costs but not when it should be chosen.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds the cost (100 credits, Tier 4) and the endpoint, which annotations do not provide. It does not explain why idempotentHint is false for a read-only call, nor what the AI explanation entails.

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 short and front-loads the purpose before the bracketed metadata. The bracketed group/endpoint/required/cost lines are slightly noisy but each carries compact information, so there is little 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?

An output schema exists, so return values need not be described. But for a 5-required-parameter tool with a near-twin sibling, the description omits the disambiguation, parameter usage, and cost implications an agent needs before committing. It is minimally adequate rather than complete.

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

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

Schema description coverage is only 38%, so the description should compensate, but it merely restates the five required parameter names that the schema already marks required and says nothing about what transitPlanet, natalPlanet, aspectType accept or how the optional fields/precision/language parameters behave. It adds no 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?

States a specific verb and resource: 'Explain a current transit hitting your natal chart.' An agent can grasp the purpose immediately. However, it never distinguishes itself from the close sibling astroway_mcp_ai_explain_aspect, leaving the borderline case ambiguous.

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

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

There is no when-to-use guidance, no exclusions, and no comparison to the near-identical sibling astroway_mcp_ai_explain_aspect. The '[Required: ...]' and '[Cost: ...]' lines are metadata, not routing guidance. The agent gets no help deciding between this and other AI tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description usefully adds the cost (100 credits, Tier 4) and the endpoint/group, but says nothing about latency, response shape of the synthesis, or how many personas are permitted (schema caps at 4).

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

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

Front-loaded with the operative sentence, followed by compact bracketed metadata; there is no filler prose. The brevity is close to under-specification rather than pure conciseness, keeping it out of the top band.

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

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

An output schema exists so return values need not be described, and cost is disclosed. However, for a tool whose whole contract is choosing personas and a question, the description never explains what the agents array should contain, leaving the most decision-relevant input undocumented across both description and schema.

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

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

Schema coverage is only 50% and the description adds no meaning beyond listing the two required names. Critically, the 'agents' array is the defining parameter and neither the schema nor the description explains what identifiers it accepts, and 'question' semantics are equally unexplained.

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

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

States a specific verb (Run), resource (N personas) and mechanism (parallel + LLM synthesis), which is more informative than a tautology. It does not name or distinguish itself from the obvious sibling astroway_mcp_agent_debate, so the agent must infer the difference between coordinated parallel personas and a debate.

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

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

No when-to-use guidance, no prerequisites, and no alternatives are named despite several closely related siblings (agent_debate, multi_chart_context, ai_chat). The '[Required: question, agents]' line just restates the schema's required array rather than telling the agent when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful non-annotation behavior: a 10-credit (Tier 1) cost and the POST endpoint. It says nothing about what the operation returns or how it behaves across the 1-6 chart array, so it earns only partial credit.

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

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

It is short and front-loads the one-sentence purpose, with well-organized bracketed metadata. But that metadata is machine-oriented boilerplate (group/endpoint/required) and the prose line is largely redundant with the title, so the brevity reflects under-specification as much as discipline.

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

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

An output schema exists, so return values need not be explained, but for a tool taking up to six nested chart objects with four intent modes and compact-mode fields/precision, the description is far too thin. It gives an agent no way to know what a "compatibility" vs "forecast" run produces or why to pick it over the many neighbouring multi-chart tools.

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

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

The only parameter content is "[Required: charts]", which merely repeats the schema's required array, adding zero meaning. The description says nothing about `fields`, `precision`, or the four `intent` modes — the latter has no schema description at all despite being the main selector. At 50% schema coverage this is a real gap it fails to fill.

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?

"Compact context for MCP agents working across multiple charts" largely restates the name/title (multi-chart context) without naming an action or an output. The word "context" is undefined — it never says whether this computes cross-chart aspects, comparison summaries, or group forecasts. Only the bare notion "multiple charts" distinguishes it from the many single-chart siblings.

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

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

There is no when-to-use guidance at all: no trigger conditions, no prerequisites, and no routing against the large sibling set (e.g. astroway_mcp_multi_agent_coordinate or astroway_mcp_ai_comparison_coach). The `intent` enum (compatibility/family/group/forecast) suggests several distinct use cases, but the description never explains when to choose which.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful context the annotations do not: the endpoint, the 10-credit Tier 1 cost, and the group. It does not disclose result ordering, chunk granularity, or hit limits, so it stops short of rich 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?

Four short, front-loaded lines with no prose padding; the core purpose statement leads. The "Required" line is redundant with the schema, which is the only real waste.

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

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

For a tool taking a deeply nested chart object plus three tuning parameters, the description is thin: no sense of ranking/scoring semantics, no indication of what the chunks are drawn from, and no guidance on choosing topK. An output schema exists so return format need not be explained, but the retrieval behavior itself is left entirely to inference.

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 a middling 60%. The description adds no parameter meaning at all — it only echoes the two required names already enforced by the schema — and says nothing about topK's default/range, the fields compact projection, or precision, the parameter most likely to be misused.

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

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

Names the mechanism (keyword-tag scoring) and the corpus (chart chunks), which goes beyond simply restating the tool name. However, it never says what the tool returns or what a "chunk" is, so an agent cannot tell whether this is a document retriever over interpretive text or a query over computed chart data.

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

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

The only usage-adjacent line is "[Required: query, chart]", which merely restates the schema's required list. There is no statement of when to reach for this tool rather than a direct retrieval sibling (e.g. astroway_mcp_multi_chart_context), and no prerequisites or 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely non-derivable behavior: the response is delivered as an SSE stream rather than one payload, crediting at 100 credits (Tier 4), and the concrete endpoint. It omits auth requirements and why idempotentHint=false, which keeps it out of 5 territory.

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?

Short and front-loaded: the core capability leads, with bracketed metadata (group, endpoint, required param, cost) following compactly. Every line carries information, though the template-style [Group:]/[Endpoint:] format is more machine header than prose.

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

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

For a streaming tool with no output schema and a nested chart parameter, the definition covers the essential facts (SSE transport, required message, optional chart, cost). It does not describe what the stream emits or how chart context influences the completion, leaving gaps an agent would notice mid-invocation.

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 60%, with the nested chart object heavily documented in the schema itself (timezone, houseSystem letters, lat/lon full names, ayanamsa). The description adds only 'optional chart context', which restates the schema's required list. Baseline 3 is appropriate when the schema does most of the work.

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

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

States a specific verb+resource+mechanism: 'Server-Sent Events streaming chat completion with optional chart context.' An agent can tell this is a streaming chat tool rather than a static computation. It does not explicitly name or contrast with the closest sibling astroway_mcp_ai_chat, 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?

No when-to-use or when-not-to-use guidance. Nothing tells the agent to prefer this over astroway_mcp_ai_chat (non-streaming chat) or astroway_mcp_tool_call_stream; the streaming qualifier implies a context but the choice is left entirely to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds two genuinely useful behavioral facts annotations cannot express: delivery is server-sent events rather than a single response, and the call costs 10 credits (Tier 1). It still omits stream termination, error-over-stream behavior, and whether partial results can be replayed.

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?

Very short and front-loaded: one sentence of purpose followed by structured metadata brackets. Nothing is wasted, though the single sentence is so compressed that the core mechanics of the tool are never actually spelled out.

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

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

For a 5-parameter tool with a nested free-form args object, a free-text tool selector, compact-mode options, and no output schema, this is under-specified. An agent cannot tell what the stream emits, how to consume it, or what valid values for tool are (presumably must match astroway_mcp_tools_list entries), all of which are load-bearing here.

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

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

Schema description coverage is only 40% across 5 parameters, and the description adds nothing beyond confirming that tool is required. args (arbitrary nested object forwarded to the target tool), language, and the compact-mode interplay of fields/precision are left entirely to the schema; the description should explain that args are passed through verbatim to the named tool.

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?

"SSE-stream of a tool call envelope" names a delivery mechanism and an artifact, so the agent knows this is a streaming wrapper that executes a named tool. However, "tool call envelope" is opaque jargon and the definition never states the key fact that this proxies/executes another MCP tool by name, nor how it differs from the sibling astroway_mcp_streaming or astroway_mcp_tools_list.

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

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

The only usage cue is the bracketed "[Required: tool]" — there is no when-to-use, no when-not-to-use, and no routing to an alternative despite multiple plausible siblings (astroway_mcp_streaming, astroway_mcp_tools_list, astroway_agent_tools). The agent must guess whether streaming is preferred over a plain call.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations do not: the concrete GET endpoint and a cost caveat that this scope is not in the public credit manifest. It does not explain response size or pagination for a manifest that presumably enumerates all tools.

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

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

The single purpose sentence is front-loaded and the metadata tags are compact, but the bracketed group/endpoint/cost lines are boilerplate scaffolding rather than description content. Nothing is wasted, yet very little informational payload is delivered.

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

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

An output schema exists so return-value documentation is not required, but for a meta-tool that enumerates the entire tool surface, the description never explains the scenario in which an agent would reach for it instead of directly invoking a domain tool. Given the enormous sibling set, this leaves a real gap.

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

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

Schema description coverage is 100%, so both `fields` and `precision` are already documented in the schema with examples and constraints. The description contributes no additional parameter meaning; the 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?

"Auto-generated tool manifest for MCP clients" largely restates the name 'MCP Tools List' without a distinct verb or an explanation of what the response actually contains. It gives an endpoint and spec version but no functional description that would distinguish its purpose from any other listing 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?

There is no statement of when an agent should call this tool, what problem it solves, or how it relates to the ~190 sibling tools. The only contextual cues are the bracketed [Group]/[Endpoint]/[Cost] metadata tags, which are not usage guidance.

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