AstroWay Platform

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds the useful guarantee that the emitted schema is the schema the endpoint validates and that the objects carry no vendor-specific fields, but says nothing about cost, rate limits, or response size behavior beyond what the schema states.

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 visible portion is front-loaded on what is returned and the two format shapes, with no filler. It is somewhat terse for a tool with six parameters and a listed default/select semantics, but every visible sentence carries information.

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

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

With an output schema present, the description need not explain return values, and annotations cover the read-only/idempotent profile. The remaining gap is routing: nothing tells the agent when to choose this over astroway_mcp_tools_list or similar listing tools.

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

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

Schema description coverage is 100%, so every one of the six parameters is already documented in the schema, including the format enum and the select/fields/precision semantics. The description restates the format option rather than adding new meaning, so the baseline 3 for full schema coverage 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 states a specific verb and resource: returning agent tool definitions generated from the live OpenAPI document, in either OpenAI or Anthropic shape. That is clear enough to differentiate it from report/chart tools in the namespace, but it never names the closest sibling (astroway_mcp_tools_list) or explains the distinction, so it falls 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?

There is no explicit when-to-use guidance and no stated alternative. The mention of `format=openai` as the default is parameter behavior, not a usage rule, and the agent is left to infer whether this is for building an agent, curated retrieval, or an MCP tool listing.

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 idempotentHint=false, so the safety profile is covered. The description adds genuinely useful non-schema context: the cost (100 credits, Tier 4) and the AI-interpretation group, but says nothing about rate limits, determinism of the generated text, or latency.

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

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

Front-loaded with the core purpose in the first clause, followed by a short use-case note and two compact metadata tags. No wasted prose, though the group/cost tags are structured metadata rather than prose value.

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

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

An output schema exists, so return values need no explanation, and cost/group are disclosed. But the description claims the tool interprets 'a single chart element (planet/house/aspect)' while the schema exposes no field for selecting which element — the description leaves that mechanism unexplained.

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

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

Schema description coverage is 100% and the body/fields/precision parameters are thoroughly documented in the schema itself, so the description carries no additional parameter burden. Baseline 3 is appropriate; the description adds nothing about how the target element is identified.

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 ('AI interpretation of a single chart element (planet/house/aspect) in context'), and the 'single element' scope implicitly separates it from whole-chart siblings like ai_interpret_natal and synastry. However, it never names those siblings, so an agent must infer the boundary itself.

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 'Useful for chart-detail pages,' which is a context hint rather than routing guidance. With four near-identical AI-interpretation siblings (natal, placement, synastry, transits), the description gives no explicit when-to-use/when-not or alternative selection rule.

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, non-destructive, openWorld). The description goes beyond them by disclosing cost (100 credits, Tier 4) and result caching for repeated inputs — both materially affect whether an agent calls it, and repeated calls are hinted non-idempotent yet cached, which is worth knowing. It does not say anything about latency despite the AI-generation nature of the call.

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: purpose first, then language support, caching, cost. The bracket tags ([Group], [Cost]) are functional but slightly metadata-ish rather than prose; still, nothing is wasted or buried.

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 the input schema is fully documented. It covers what the interpretation contains, language options, caching and credit cost for a paid AI-generation endpoint. The remaining gap is the absence of any latency/streaming or failure-mode note for a long-running generative call.

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 nested birth-data schema is exhaustively documented (field names, timezone rules, houseSystem letters, compact-mode fields/precision). The description adds nothing about parameters, which is acceptable given the schema carries the full burden — this lands on 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?

States a specific verb+resource ('Generate AI interpretation of a natal chart') and enumerates the output content (personality traits, life themes, strongest archetypes). The natal-chart scope implicitly separates it from astroway_ai_interpret_synastry, _transits, _element and _placement, but those siblings are never named, so the agent must infer the division of labor from the tool name alone.

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 choose this over astroway_ai_interpret_placement or astroway_ai_interpret_synastry, nor what prerequisites exist (a computed chart?). 'Multi-language' and 'token-cached for repeats' are properties, not usage conditions, so selection guidance 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, openWorld, non-idempotent, and non-destructive behavior. The description adds useful billing context (100 credits, Tier 4) and scope conciseness, but does not disclose credit deduction timing, latency, or preconditions beyond what the schema covers.

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

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

Two compact sentences put the purpose and scope first, followed by terse Group and Cost brackets. Every element earns its place with no filler.

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

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

Given the rich input schema and an output schema, the description covers purpose, scope, group, and cost adequately. It could be more complete about prerequisites or AI-call behavior, but nothing critical for correct invocation 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 the body, fields, and precision parameters thoroughly. The description adds domain framing around 'planet+sign+house' but no parameter-level syntax or constraints beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb+resource ('AI interpretation of a specific planet+sign+house combination') and scopes it to the placement only, which distinguishes it from broader natal or synastry interpretations. However, it does not explicitly name the sibling alternatives it differs from.

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

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

The phrase 'focused on the placement only' implies usage for a single planet+sign+house reading, but there is no explicit when-to-use guidance, no exclusions, and no named alternatives such as interpret_natal or interpret_element.

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 idempotentHint=false, so the safety profile is covered. The description usefully adds the cost (100 credits, Tier 4), which matters for budget-aware agents, but says nothing about latency, whether the interpretation is cached, or the consequences of the non-idempotent hint.

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 naming the resource and its output facets, plus two bracketed metadata lines for group and cost. Nothing is wasted, though the facet list is slightly padded and no sentence is spent on usage or behavior.

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 input schema is exhaustively documented. However, for a paid (100-credit) non-idempotent AI call, the description omits any note on when to prefer it over the other interpretation tools, leaving a gap in routing guidance.

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 nested chart objects are richly documented (timezone handling, ayanamsa, houseSystem letters, rejected short forms), so the schema does the heavy lifting. The description adds only 'between two charts', which loosely maps to chart1/chart2 but contributes no new parameter meaning.

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

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

States a specific verb (AI interpretation) and resource (synastry between two charts), and enumerates what the output covers: relationship dynamics, attractions, friction points, long-term outlook. The phrase 'between two charts' implicitly separates it from single-chart siblings like astroway_ai_interpret_natal, though no sibling is named.

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 guidance, no prerequisites, and no named alternative among the many interpret_* siblings. The '[Group: AI Interpretations]' tag gives taxonomy context but not selection criteria; an agent must infer usage entirely from the tool name.

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

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

Annotations already declare readOnly=true, destructive=false, and importantly idempotent=false. The description adds genuinely useful behavioral context via the cost line ('100 credits (Tier 4)'), which annotations do not convey. It stops short of noting that output is LLM-generated and non-deterministic (consistent with idempotentHint=false) or any latency/rate-limit expectation.

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

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

A single front-loaded sentence states the purpose, followed by compact metadata tags. Nothing is redundant or padded, though the group/cost tags are more structured metadata 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?

The tool takes a two-part input (natal birth data plus a required transitDate/time), and the description never surfaces that both halves are needed or that the transit date drives the interpretation window. An output schema exists so return values need not be explained, but for a Tier-4 credit-consuming interpretation tool the description would benefit from a note on the required transit date and non-determinism.

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 nested birth-data object, fields, and precision parameters are already fully documented in the schema, including the rejected short-form names and the timezone/timezoneOffset rules. The description adds no parameter-level information, so the baseline of 3 applies.

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

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

States a specific verb ('AI interpretation') and resource ('current/upcoming transits to a natal chart') plus the scope of output ('what each major transit means in life context'). It is clear on its own, but it does not differentiate itself from close siblings such as astroway_ai_interpret_natal or astroway_mcp_ai_explain_transit, leaving the agent to infer the boundary.

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

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

No when-to-use or when-not-to-use guidance, and no alternative tool is named. The '[Group: AI Interpretations]' tag offers weak categorization but no condition that tells an agent when to pick this over the natal, placement, or synastry interpreters. The cost tier is stated but 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 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 establish readOnly, idempotent and non-destructive behaviour, so the safety bar is low. The description adds genuinely useful operational facts the annotations do not carry: the tool is an MCP Advanced feature costing 100 credits (Tier 4). It still says nothing about how rounds affect runtime or output, or whether chart context is mandatory for a meaningful debate.

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

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

Two short lines, front-loaded with the core purpose followed by group and cost metadata; there is no filler or repetition. The brevity is somewhat a result of under-specification rather than disciplined editing, but structurally it is clean.

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?

This is a high-complexity tool: 8 parameters, a nested chart object with detailed validation rules, and an output schema. The description covers none of that complexity and omits the astrological framing entirely, leaving an agent to infer from the schema alone what inputs matter. Output format is covered by the output schema, so that omission is acceptable, but the rest is 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 only 38% and several parameters (topic, agentA, agentB, rounds, language) carry no schema description, so the description is expected to compensate — and it does not, adding no parameter meaning whatsoever. 'multi-round' only obliquely hints at the rounds parameter, and nothing explains what agentA/agentB strings should contain or how chart is consumed.

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 concrete verb and output ('2 personas debate a topic, multi-round transcript'), so an agent knows this produces a debate transcript rather than a single answer. However, it never differentiates itself from near-neighbours like astroway_mcp_ai_chat or astroway_mcp_multi_agent_coordinate, and it omits that the debate is anchored to an astrological chart, which the schema makes clear.

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 statement of what situation calls for a two-persona debate over a single-shot chat, no prerequisites, and no mention of alternatives. The only extra text is group and cost metadata, which is billing context rather than 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, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely new context by disclosing a 10-credit Tier 1 cost, but omits what the status payload represents or whether it reflects live pool state.

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 very short and front-loads the one substantive fact, but the first sentence is a dangling fragment rather than a complete statement of purpose, and the bracket tags read as metadata padding rather than 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 explained, and annotations cover safety, so the description's remaining burden is small. It is still thin on what 'pool status' reports and when it should be invoked, leaving a minor gap for a zero-required-parameter status tool.

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

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

Schema description coverage is 100% and both optional compaction parameters (fields, precision) are thoroughly documented in the schema with examples. The description adds nothing about parameters, so the baseline 3 applies.

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

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

The description '8 personas with specialties' is a noun fragment that hints at the returned content but never states what the tool does or what 'pool status' means. It does not distinguish this from siblings like astroway_agent_tools or astroway_mcp_tools_list, which also concern agent/persona inventory.

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 indication of when to call this versus the many sibling agent/tools-listing tools, and no prerequisites or exclusions. The only guidance offered is the cost tag '[Cost: 10 credits (Tier 1)]', which helps budget decisions but says nothing about selection.

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

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

Annotations already declare the safety profile (readOnly, non-destructive, openWorld, non-idempotent), and the description usefully adds context beyond that: a 10-turn history cap, 21 supported languages, four persona voices, and a cost behavior where sending your own provider key drops the turn to 5 credits. It stops short of describing failure modes or what the chart object must contain to succeed.

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 differentiator ('answered from the positions we computed') before secondary facts about history, languages, and pricing. The trailing group/cost tags are metadata rather than prose, so there is minimal 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 explained, and the description covers the AI-behavioral surface (grounding, history, language, persona, cost). For a 7-parameter tool with nested objects and low schema coverage, it could say more about the chart input contract, but the essentials are present.

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 43%, so the description should compensate, and it partly does by explaining history (10 turns), language (21), and persona (four voices). However, it says nothing about the required `message`, the complex nested `chart`, or the compact-mode `fields`/`precision` parameters, leaving those to the schema.

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

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

The description states a specific verb and resource — a chat grounded in computed chart positions rather than the model's sun-sign memory — which is clearly distinguishable from report-generation siblings. It does not explicitly name an alternative among the many AI siblings (explain_aspect, explain_transit, comparison_coach), so it falls short of a 5.

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

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

The description explains what the tool is but never says when to reach for it versus the other AI siblings or the narrative-report tools. No prerequisites or selection conditions are given; the agent must infer usage from the name alone.

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 a safe read-only, non-destructive, open-world operation. The description adds useful cost context (100 credits, Tier 4) and group membership, but does not disclose rate limits, auth requirements, or what the AI coach actually returns. With annotations covering safety, this partial extra context merits a 3.

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-loaded, with cost and group metadata placed clearly after the core sentence. It wastes no words, although it is arguably too sparse for a tool of this 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?

For a 6-parameter tool with nested chart objects and multiple AI/synastry siblings, the description is far too thin. The output schema covers return values, but the description does not explain what 'coaching' entails or when to select this tool over alternatives, leaving a substantial contextual 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 67%, and the description adds no parameter-level meaning beyond the schema. It says 'two charts' but does not clarify the role of the required question field, language, precision, or fields parameters, nor does it help compensate for the less-documented 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?

The description names the resource (two charts) and domain (relationship dynamics), but the verb 'Coach' is vague about what the tool actually produces. It does not distinguish this from sibling reports like astroway_reports_ai_synastry_narrative, leaving an agent unsure whether this is an interactive coaching session, a report, or something else.

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

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

No when-to-use guidance is provided. The description does not mention when this tool should be chosen over similar two-chart tools such as synastry reports or multi-chart context, nor are any preconditions or exclusions stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description's only added behavioral fact is the cost (100 credits, Tier 4), which is genuinely useful for an agent budgeting calls, but nothing is said about latency, auth, or output shape.

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-loaded, but the terseness here reflects under-specification rather than efficient communication. The metadata lines consume half the length without adding invocation help.

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 no prose, but the description leaves key input questions open: how planets must be named, which chart object is required for a natal calculation, and what the aspectType enum means in context. For a 7-parameter tool with a nested birth-data object, this is thin.

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 43%, and the undescribed parameters include the three required ones (planet1, planet2, aspectType). The phrase 'between two planets' loosely implies planet1/planet2 but gives no naming convention or accepted values, and aspectType, language, fields and precision get nothing despite the 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 and resource: an explanation of an aspect between two planets. An agent can tell what it does, though it never contrasts itself with the sibling astroway_mcp_ai_explain_transit, which is the nearest alternative.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as explain_transit or the report tools. The agent must infer usage entirely from the name.

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, destructiveHint=false, openWorldHint=true and idempotentHint=false. The description adds genuinely useful operational context by disclosing the cost (100 credits, Tier 4) and the AI grouping, which helps an agent budget. It does not explain the non-idempotent nature of an AI-generated explanation or any latency/rate behavior, so it adds some but not rich 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?

A single front-loaded sentence carries the core purpose, with the group and cost tags kept as structured metadata rather than prose. It is tight and waste-free, though its brevity edges into under-specification rather than model 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?

For an 8-parameter tool with a nested chart object and five required fields, the description omits routing guidance against several plausible siblings and says nothing about the transit inputs. The presence of an output schema excuses it from describing return values, but the selection and input story is still incomplete.

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 38% and the five required parameters (chart, transitDate, transitPlanet, natalPlanet, aspectType) carry no schema descriptions at all. The description only obliquely implies a transit/natal pairing and says nothing about expected values or formats for those required fields, so it does not 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?

The description states a specific verb and resource: 'Explain' applied to 'a current transit hitting your natal chart.' An agent can tell what the tool produces. It stops short of distinguishing itself from close siblings such as astroway_mcp_ai_explain_aspect or astroway_reports_ai_transit_narrative, so it is clear but not sibling-differentiating.

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, when-not-to-use, or named alternative. The sentence implies the context (a transit to your natal chart) but gives no condition that would route an agent here instead of the aspect explainer or the transit narrative report. This matches the 'no guidance' band.

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 safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description only needs to add context. It does add parallel execution and a 100-credit Tier 4 cost, which is useful. However, it omits latency implications from LLM synthesis, auth requirements, and any detail about valid agent choices.

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 very short and front-loads the core action before the group and cost tags. No sentence is wasted, though the brevity reflects under-specification rather than thorough contextual completeness.

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?

This is a complex tool with a nested chart object, six parameters, required agent and question fields, and many sibling tools. The description explains almost none of that beyond a two-line summary and cost, leaving significant gaps even though an output schema exists for return values.

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 50%, and the description adds no parameter-level meaning for question, agents, chart, fields, language, or precision. In particular, the required 'agents' array and its 2-4 item constraint, as well as how 'chart' relates to the question, are left entirely to the schema.

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

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

The description gives a high-level verb and resource ('Run N personas in parallel + LLM synthesis') but does not define what a persona is, what is being coordinated, or how this differs from siblings such as astroway_mcp_agent_debate. The [Group] and [Cost] tags are metadata rather than purpose clarification.

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, when-not-to-use, or alternative-tool guidance. The closest sibling, astroway_mcp_agent_debate, is not mentioned, and the cost tier alone does not tell an agent when this tool should be selected.

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 safety is covered elsewhere. The description adds only the cost tag (10 credits, Tier 1); it says nothing about batch limits, what the compact response excludes, or the idempotentHint=false implication that repeated calls may vary.

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 sentence plus metadata tags are front-loaded and free of padding, so it is structurally clean. However, the brevity here is under-specification rather than conciseness: the sentence carries almost no callable 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?

An output schema exists, so return values need not be described, but for a tool with an enum-driven intent, a compact-mode fields selector and a 6-item batch cap, the description omits nearly everything an agent needs to choose and configure it.

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 50%, so the description is expected to compensate — and it does not. The compact-mode controls (fields, precision) and the intent enum are never mentioned in the description, leaving the agent to discover their meaning entirely from 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?

"Compact context for MCP agents working across multiple charts" restates the tool name (multi-chart context) without a concrete verb or resource for what is actually produced. It never says it computes natal chart data for multiple subjects, nor does it distinguish this tool from sibling report/chart tools like astroway_reports_natal or astroway_reports_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 only usage signal is the implied "working across multiple charts," from which an agent might infer batch multi-subject use. There is no explicit when-to-use, no exclusions, and no mention of when a single-chart or report sibling is preferable, despite ~40 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?

The annotations already declare this as a read-only, idempotent, closed-world, non-destructive operation. The description adds cost and group context, which is useful, but does not disclose any operational behavior such as result format, ranking details, or rate-limit implications.

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 definition is very short and front-loads the core phrase before the bracketed metadata. There is no wasted prose, though the concision contributes to the broader underspecification problem rather than being a structural flaw itself.

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

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

The tool takes five parameters including a nested chart object, exists among many siblings, and has an output schema. Despite that complexity, the description does not explain selection criteria, query semantics, or how this differs from report-generation tools, leaving it materially incomplete for agent routing.

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 moderate at 60%, and the description adds no parameter meaning at all. It does not clarify what 'query' should contain, how 'topK' affects results, or how 'chart' is used, so key semantics remain dependent on the schema alone.

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 says 'Keyword-tag scoring over chart chunks,' which reveals the mechanism and resource type, but it never states the core action as a verb such as 'search' and does not distinguish this tool from the many sibling retrieval/report tools. An agent can infer it is a retrieval tool, but the purpose remains vague.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternatives to consider. It only supplies group and cost metadata, leaving the agent with no routing signal among the sibling 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 cover the safety profile (readOnly, non-destructive, open-world, non-idempotent). The description adds two genuinely useful behavioral facts beyond them: the response arrives as Server-Sent Events, and each call costs 100 credits (Tier 4). It says nothing about auth requirements, rate limits, or what the stream events look like, so it is adequate but not rich.

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

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

One front-loaded sentence that states the core capability, followed by two bracketed metadata tags. Very tight, though the group/cost tags sit after the payload rather than being folded in naturally.

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 birth-chart object, no output schema, and only 60% schema description coverage, the definition is thin. It does not describe the streamed response shape, streaming lifecycle, or the required message parameter, and gives no guidance on how chart context should be formed.

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 60% and the nested chart object carries extensive inline documentation that the description does not repeat. The 'optional chart context' phrase confirms the chart parameter exists but adds no semantics for message, language, fields, or precision, so it does not 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 and resource: an SSE streaming chat completion, with the chart-context option noted. It is clearer than a bare 'chat', but it never distinguishes itself from sibling astroway_mcp_ai_chat (presumably the non-streaming counterpart) or astroway_mcp_tool_call_stream, so the agent must guess which chat entry point to pick.

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, when-not-to-use, or alternative guidance is given. The description notes that chart context is optional but never says when you should supply it or how it changes the answer, and it never mentions the sibling chat tools as 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description. The description does add one genuinely useful behavioral fact not in annotations: the 10-credit Tier 1 cost. However, for a streaming tool it says nothing about stream termination, error semantics, or partial delivery, which is the behavior an agent most needs 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?

It is short and the core statement is front-loaded, so nothing is wasted. But the two bracketed metadata lines are boilerplate and the resulting length is too thin for the tool's complexity, so brevity here reads as under-specification rather than tightness.

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 5 parameters (including a nested arbitrary 'args' object), no output schema, and an opaque streaming return, the definition is far too thin: it never explains what the streamed envelope contains, how the stream ends, or how 'args' maps to the target tool. An agent must guess at most of the call contract.

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%: 'tool' (the sole required parameter) and 'args' carry no description, and 'language' has only an enum. The description supplies zero parameter guidance, so it fails to compensate for the coverage gap on a 5-parameter tool with a nested free-form object.

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?

It pairs a specific verb ('SSE-stream') with a resource ('tool call envelope'), which is more than a tautology, but 'tool call envelope' is unexplained jargon and the definition does nothing to separate it from close siblings like astroway_mcp_streaming or astroway_mcp_tools_list. An agent cannot tell from this text which one to pick.

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, when not to, or what alternative exists for the same need. The only context is the group/cost tag, which tells the agent a price but not a use case.

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, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds a spec version and notes that cost is not in the public credit manifest, which is useful behavioral context. However, it does not explain what the manifest contains, how it is scoped, or any other operational behavior beyond what annotations provide.

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 its main claim about being an auto-generated manifest. The bracketed group and cost lines add metadata without excessive verbosity. It is efficient, though the bracket metadata is only marginally useful for tool selection.

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 and the input schema is fully documented, so return values and parameters do not need explanation in the description. However, the description remains thin on purpose and usage guidance, making it only minimally complete for an agent deciding whether to call this tool. The low complexity of the tool keeps it from being inadequate, but notable gaps remain.

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 parameters (fields and precision) are already fully documented in the schema. The description adds no parameter-level meaning beyond what is in the input schema. With complete schema coverage and no additional description detail, a 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 says it is an auto-generated tool manifest for MCP clients, which identifies the general resource but uses no action verb and does not explicitly state that it lists available MCP tools. It also does not distinguish this tool from nearby siblings such as astroway_agent_tools or the MCP-related tools. Purpose is therefore implied rather than clearly 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 only usage context is the phrase 'for MCP clients,' which implies an audience but gives no guidance on when to call this tool versus alternatives. It does not mention prerequisites, exclusions, or sibling tools. This is the same level as a definition that provides only an implied 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?

Annotations declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the write-ish, non-idempotent, live-data character is already signaled. The description adds useful context the annotations lack — that this is a Real-time Streaming tool and that it costs 10 credits (Tier 1) — but says nothing about stream duration, termination, or what triggers an update, which matters for a streaming endpoint.

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

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

Front-loaded with the core purpose and kept to a single content sentence plus two bracketed metadata tags. Nothing is wasted, though the metadata lines are formatting rather than explanation.

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 no explanation, and the cost/streaming tags cover part of the operational picture. Still missing for a streaming, credit-consuming tool: how long the stream runs, how it ends, and when to choose it over the eclipse webhook or totals 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?

Both optional parameters (fields, precision) are fully documented in the schema at 100% coverage, including example paths and rounding semantics, so the schema carries the burden. The description adds nothing about the compact-mode convention, 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 resource and output ('Countdown to next 5 eclipses'), which is concrete enough for an agent to know what it returns. It does not, however, distinguish itself from nearby siblings like astroway_stream_eclipse_totality or astroway_webhooks_eclipse_alert, so the boundary between eclipse-related tools 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?

The description gives no when-to-use, when-not-to-use, or alternative guidance. An agent cannot tell from the text whether this should be preferred over the eclipse webhook or eclipse_totality tools, or under what conditions the streaming variant is 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?

Annotations already declare readOnlyHint=false, openWorldHint=true, non-idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful context the annotations lack — the 10-credit Tier 1 cost — but says nothing about streaming semantics, latency, or whether the call is a one-shot snapshot or a subscription.

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

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

A single front-loaded sentence plus two bracketed metadata tags — no filler. It is efficient, though the bracketed cost/group lines carry more weight than the actual capability sentence.

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 location-aware streaming tool with four parameters and a nearly identical sibling, the definition omits location semantics, streaming behavior, and any disambiguation, leaving the agent under-equipped to call it correctly.

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

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

Latitude and longitude carry no schema descriptions, so half the parameters are undocumented in both schema and description. The description never explains whether a location is required for totality visibility, nor what fields/precision do beyond the schema's own text.

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 concrete resource (next solar+lunar eclipses) and a distinctive attribute (totality info), which is more specific than the typical eclipse sibling. However, it does not distinguish itself from astroway_stream_eclipse_incoming, which almost certainly also returns upcoming eclipses, leaving the agent to guess which eclipse tool to pick.

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 statement, no prerequisites, and no reference to alternatives such as astroway_stream_eclipse_incoming or the webhook-based astroway_webhooks_eclipse_alert. The only context given is a group tag and a cost tier, 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 supply the safety profile (openWorldHint=true, destructiveHint=false, idempotentHint=false), so the bar is lower. The description adds genuinely useful context in the cost tag (10 credits, Tier 1), but says nothing about the forecast window's default, pagination, or why readOnlyHint is false for what reads like a query.

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 compact and front-loaded: purpose first, then the group and cost metadata. Nothing is wasted, though the terse phrasing leaves real gaps rather than being optimally economical.

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. However, for a 3-parameter tool with an undocumented `days` parameter and no usage or window-default guidance, the definition is only minimally sufficient for correct 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 coverage is 67% and the undocumented parameter is `days`, which the description only restates as 'N days' without units, default, or maximum. The compact-mode params (fields, precision) are documented in the schema but receive no mention here, so the description adds little beyond structured data.

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

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

States a specific resource (planet sign-ingresses) and a temporal scope (next N days), which lets an agent distinguish it from siblings like astroway_stream_positions or astroway_stream_retrograde_alerts. It is clear but offers no explicit contrast with those 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, no prerequisites, and no named alternatives among the many astroway_stream_* siblings. The group/cost tags describe billing, not invocation 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?

With annotations present, the description adds useful context beyond structured fields: the real-time streaming group and the 10-credit cost. However, it does not explain operational behavior such as whether the stream is a persistent connection, how data is consumed, or what authentication or rate limits apply. No annotation contradiction 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?

The description is extremely concise and front-loads the core output before appending group and cost metadata. Every element earns its place, though '8-phase' is slightly cryptic without the lunar context from the title. It avoids waste and is 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?

An output schema exists, so return values need not be explained; annotations and 100% schema coverage handle safety and parameters. The description still leaves the usage decision underspecified relative to the many sibling stream tools. It is adequate but not fully complete for an agent selecting among alternatives.

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 optional parameters (fields and precision) are already fully documented in the input schema. The description contributes no additional parameter meaning, which is appropriate for the baseline score when the schema does the heavy lifting.

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

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

The description states the specific output: current lunar phase expressed as an 8-phase value plus a countdown to the next major phase. This makes the resource and scope clear, though it lacks an explicit verb like 'streams' or 'retrieves'. It is distinguishable from sibling stream tools by its lunar-phase focus.

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

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

No when-to-use guidance is provided. The group tag '[Group: Real-time Streaming]' implies a context, but it does not tell the agent when to choose this tool over alternatives such as astroway_stream_void_of_course or astroway_stream_ingress. There are no exclusions or alternative-routing 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 declare the safety/lifecycle profile (not read-only, not idempotent, open-world, non-destructive), so the description need not restate it. It does add context the annotations lack – group membership and a 10-credit Tier 1 cost – but says nothing about how the stream behaves (push vs. poll, cadence, termination). Modest value-add over structured data.

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?

Extremely short and front-loaded, with group and cost metadata cleanly bracketed. Nothing is padded, though the terseness shades into under-specification rather than true economy.

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 is covered, but for a 5-parameter streaming tool with minimal annotations the description omits usage routing, streaming behavior, and meaning for the required coordinates. Too thin for correct 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 only 60%, and critically the two REQUIRED parameters (latitude, longitude) have no schema description at all. The description supplies no coordinate semantics, no units, and no guidance on timezoneOffset interplay, so it fails to compensate for the coverage gap on the most important inputs.

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?

"Current planetary hour + next 24" names the resource (planetary hour) and the window (next 24), and the group tag confirms it is a streaming tool. But "next 24" is ambiguous (24 hours vs. 24 changes) and there is no verb framing what is returned. It identifies the subject without cleanly differentiating it from siblings like astroway_stream_positions or astroway_webhooks_planetary_hour_tick.

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, no when-not-to-use, and no named alternative among the many stream/webhook siblings. The agent must infer from the group tag that this is a live-feed tool and cannot tell when to prefer it over a webhook subscription or a positions stream.

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

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

The description adds two behavioral facts the annotations do not carry: a 30-second tick cadence and a 10-credit (Tier 1) cost. However, with readOnlyHint=false and idempotentHint=false, the annotations leave open whether this opens a persistent stream, how it is terminated, or whether credits are charged per call or per tick, and the description does not resolve any of that; the word 'snapshot' also sits in mild tension with readOnlyHint=false.

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?

Extremely compact and front-loaded: the purpose is the first clause, followed by the cadence and bracketed group/cost metadata. Nothing is wasted, though the bracketed tags are metadata 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?

An output schema exists, so return values need not be described, and both parameters are covered. But for a streaming tool the description omits how the stream behaves, how long it runs, and how to stop it, and offers no routing against the many similar stream siblings, leaving real gaps for an agent deciding to invoke it.

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 parameters (fields, precision) are fully documented with examples and defaults in the schema itself. The description adds nothing about parameters, and tickSeconds=30 is not one of the declared parameters, so this sits at the baseline of 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 names a specific resource and scope: 'Current planetary positions snapshot', which is concrete enough that an agent knows it retrieves a point-in-time set of planetary positions. It does not, however, differentiate itself from the many sibling stream_* tools (transit alerts, ingress, lunar phase), which is the main missing piece for a 5.

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

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

There is no when-to-use guidance and no mention of alternatives such as astroway_mcp_streaming, astroway_stream_transit_alerts, or the webhook subscribe tools. The only operational cue, tickSeconds=30, hints at a recurring cadence but does not explain when this snapshot is preferable to a one-off chart calculation or a subscription.

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 supply a safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), but they are puzzling for an alerting tool and the description does nothing to resolve that. The "[Group: Real-time Streaming]" and 10-credit cost tags are useful metadata, yet the description never explains what streaming means here, whether it blocks, or how alerts are delivered.

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?

Extremely compact and front-loaded: the functional sentence comes first, followed by two bracketed metadata tags that each carry real information (grouping and cost). Nothing is padded, though the terseness borders on 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 no prose, but for a paid (10 credits), streaming, alert-oriented tool sitting among many near-identical stream/webhook siblings, the definition omits the usage and behavior context an agent needs to select it correctly.

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

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

Schema description coverage is 100%, so `fields` (dotted-path compaction) and `precision` (decimal rounding) are already fully documented with examples in the schema. The description adds no parameter information, so the baseline 3 applies.

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

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

"All planets retro state + next stations" names a concrete resource (planetary retrograde/direct stations) with a specific scope (all planets), which is distinguishable from siblings like astroway_stream_void_of_course and astroway_stream_ingress. It is verb-less and telegraphic, but the subject matter 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?

There is no indication of when to call this versus the closely related astroway_webhooks_retrograde_start/end or astroway_stream_transit_alerts. Whether this is a one-shot snapshot of current retrograde state or an actual continuous stream is never clarified, which is exactly the decision an agent needs to make.

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 openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is covered. For a streaming tool the critical undisclosed behavior is how the stream is delivered (polling, SSE, cadence, termination), which the description omits entirely. It does add the cost (10 credits, Tier 1) and time scope, which is genuine value beyond annotations.

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

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

The description is extremely short and front-loads the scope ("Today + tomorrow sun events") before the structured cost/group tags. Nothing is wasted, though the brevity comes at the cost of substance rather than being lean-but-complete.

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. However, for a 5-parameter streaming tool, the description omits the single most important thing an agent needs — how the stream behaves and how to consume it — leaving it inadequate for the tool's complexity.

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

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

Schema coverage is 60%: fields, precision, and timezoneOffset are documented in the schema, while the two required parameters (latitude/longitude) are undocumented in both places. The description adds nothing about parameters, but latitude/longitude are self-evident by name, so 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?

"Today + tomorrow sun events" names the resource (sun events) and a scope (today + tomorrow), but is a noun fragment with no verb — the streaming action is only implied by the title/name. It loosely distinguishes from siblings like stream_lunar_phase or stream_positions by resource, but never says it returns sunrise/sunset times specifically.

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 routing to alternatives such as astroway_webhooks_eclipse_alert or other stream_* tools. The "[Group: Real-time Streaming]" tag categorizes but does not tell an agent when to select this tool over its 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 openWorldHint=true, readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is covered. The description adds only billing metadata (10 credits, Tier 1); it discloses nothing about whether the tool polls or streams, whether the alert window is one-shot, or how hits are delivered.

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 line, front-loaded with the actual function, with no padding or repetition. It loses a point because half the text is bracketed group/cost metadata rather than task-relevant instruction.

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?

Placeholder mismatch check: an output schema exists, so return values need no prose. The input schema itself is exhaustively documented, including birth-data rules and compact-mode fields, so the definition is not the bottleneck 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 100%, so the schema carries the parameter docs and the baseline is 3. 'Next N hours' does lightly bind to the nested 'hours' knob, but the description adds no syntax, limits, or defaults beyond what the schema already states.

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

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

The description names the resource (natal-transit hits) and the window (next N hours), so an agent can tell this computes upcoming transits to a natal chart. It stops short of a verb and gives no differentiation from near-neighbours like astroway_webhooks_transit_trigger or astroway_ai_interpret_transits, so the agent cannot confidently route on this text alone.

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, no when-not-to-use, and no named alternative. The '[Group: Real-time Streaming]' tag implies a streaming/alerts context, but the agent gets no guidance on choosing this over the webhook or interpretation 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 declare `readOnlyHint: false`, `idempotentHint: false`, and `openWorldHint: true`, but the description does not explain what the stream does, how it is consumed, what triggers emissions, or why the annotations show a non-idempotent, non-readonly profile for what looks like a read of ephemeris data. It adds only the cost/credit tier, not 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?

Extremely short and front-loaded — one line plus two bracketed metadata tags. Nothing wasted, though the brevity itself is part of the problem since more disclosure is needed.

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 real-time streaming tool with a non-trivial annotation profile and many siblings, the description is too thin. It does not explain stream semantics, emission triggers, or how consumption differs from the webhook sibling; the presence of an output schema covers return values but not stream behavior.

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

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

Both parameters (`fields`, `precision`) are fully documented in the schema with examples and defaults. Baseline 3 applies since schema coverage is 100% and the description adds nothing parameter-related.

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 the resource (Moon void-of-course) and the payload (current VOC + next ingress). It is understandable but terse and does not distinguish this streaming endpoint from siblings like `astroway_stream_ingress` or `astroway_webhooks_void_of_course_start`, which cover closely related 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?

No guidance on when to use this versus `astroway_webhooks_void_of_course_start` (webhook for the start event) or `astroway_stream_ingress` (other streamed ingresses). The agent must infer the streaming-vs-webhook distinction from the group tag alone.

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 write profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false), so the safety bar is lower. The description usefully adds cost ('10 credits (Tier 1)') and the group tag, but says nothing about delivery behavior, payload shape, auth, or whether the registration persists — meaningful gaps for a subscription-creating mutation.

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: the trigger condition comes first, followed by compact group/cost metadata tags. Nothing is padded, though the terseness borders on under-specification rather than disciplined 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?

An output schema exists, so return values needn't be explained. But for a webhook-registration mutation with a required undocumented parameter and no annotations covering the subscription lifecycle, the description should say more about what registering actually does, the delivery target, and any limits — none of which is present.

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 67%, and the single required parameter 'url' has no description at all in the schema. The description adds no parameter meaning whatsoever, so it fails to compensate for the undocumented required field. It neither clarifies what URL is expected nor references fields/precision.

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 event ('Vedic Vimshottari dasha period transitions'), which does distinguish it from siblings like mahadasha_end or retrograde_start. However, it describes the trigger, not the action — it never states that the tool registers/creates a webhook. The verb only appears in the title, so the description alone leaves the actual operation implicit.

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

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

There is no when-to-use guidance, no prerequisites, and no reference to alternatives, despite a large family of sibling webhook tools (mahadasha_end, sign_ingress, transit_trigger, etc.) that an agent must choose between. The agent gets no help deciding when a dasha-change subscription is the right choice versus a streaming 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?

Annotations already declare this is a non-readonly, non-destructive, non-idempotent, open-world operation. The description adds genuinely useful context the annotations do not carry: the credit cost (10 credits, Tier 1) and the default lead time of 7 days before the event. It does not disclose delivery format, retry/duplicate behavior implied by idempotentHint=false, or any auth/verification requirement.

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

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

Two short lines with the action front-loaded and no wasted prose. The bracketed [Group]/[Cost] metadata is terse and informative rather than padding.

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

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

An output schema exists, so return values need no explanation. However, for a webhook registration tool the description omits practical essentials: whether the endpoint must be publicly reachable, whether registration can be duplicated, and how it relates to the many sibling webhook and streaming tools.

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

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

Schema coverage is 67%: 'fields' and 'precision' are well documented in the schema, while the required 'url' has no description. The description adds nothing about any parameter, and its '7 days before' default implies a configurable lead time that does not exist as a parameter, which may mildly mislead.

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

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

The description states a specific verb and resource: subscribing to eclipse alerts, with a concrete behavioral detail (default 7 days before). It is clear what the tool does, but it does not distinguish itself from the generic astroway_webhooks_subscribe or the streaming eclipse tools (astroway_stream_eclipse_incoming), so an agent cannot route between them from the text alone.

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 mention of when to prefer this over astroway_webhooks_subscribe or the stream_* eclipse siblings, and no stated prerequisites (e.g. whether a public URL or account is required). The 'default 7 days before' hint is a behavior detail, 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?

The description says 'Fetch a single webhook subscription', which is a read operation, yet the annotations declare readOnlyHint=false and idempotentHint=false. That mismatch means an agent relying on annotations would expect this call to mutate state; the description does not correct this or explain any side effects, so it contradicts the annotation profile.

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 group/cost metadata is compact. The cost note is genuinely useful since it flags that pricing is not in the public manifest.

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 need not explain return values, and it correctly covers the ownership scope. It is largely complete, though the annotation inconsistency leaves the safety profile unresolved.

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 three parameters (id, fields, precision) are already documented with examples and semantics. The description adds no parameter meaning beyond the schema, which is the baseline 3 case.

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

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

States a specific verb (fetch), resource (webhook subscription), and scope (single, owned by the authenticated user), which distinguishes it from the many event-specific webhook tools. It does not explicitly distinguish itself from the sibling astroway_webhooks_webhooks, presumably the list endpoint, but 'single' implies the difference.

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 tool is named. An agent must infer that this is the detail-lookup counterpart to the list endpoint rather than being told.

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=false, idempotentHint=false, destructiveHint=false, openWorld=false). The description goes beyond them by disclosing the exact synthetic payload and the side effect that the result is recorded in failure_count / last_status_code — a non-obvious mutation of the webhook's health stats. It still doesn't say whether the test counts toward rate limits or affects real subscribers.

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 what happens, then why, then the side effect. The trailing cost/group tags are boilerplate but short and clearly separated; nothing in the core prose 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 values need not be explained, and annotations cover the safety profile. Between them the description covers action, payload, and side effect; the main lingering gap is cost, which is flagged as unknown rather than resolved.

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 `id`, `fields`, and `precision` are fully documented in the schema. The description adds only the framing that `id` resolves to a registered URL with a fixed payload; it says nothing about the compact-mode params, 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: it fires a synthetic test delivery to the webhook's registered URL with a fixed `{"test": true}` payload. That distinguishes it from the list/get sibling `astroway_webhooks_id`, though no sibling is named explicitly and the registry of webhook tools is large.

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?

"Useful when validating endpoint signature handling" gives one genuine use case, but there is no when-not guidance (e.g. that this is a smoke test, not a real event trigger) and no mention of how it relates to siblings like `astroway_webhooks_subscribe` or the specific event webhooks. Usage is implied rather than routed.

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=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations: the event timing and a cost of 10 credits (Tier 1). It omits auth requirements, delivery behavior, and how N is set, but with annotation coverage a 3 is appropriate.

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, front-loads the event trigger, and uses bracketed tags for group and cost without wasting words. It is appropriately sized, though the unexplained 'N days' is an unresolved detail rather than structural clutter.

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 webhook registration tool with three parameters and 67% schema coverage, the description omits how N is configured, what registration entails, and any auth or delivery context, leaving it incomplete.

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%, with fields and precision documented in the schema but url undocumented. The description adds no parameter meaning and introduces 'N days,' which has no corresponding parameter, so it neither compensates for the coverage gap nor helps the agent understand inputs.

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 event trigger: fires N days before a Vimshottari mahadasha ends. That distinguishes it from sibling webhooks like astroway_webhooks_dasha_change or astroway_webhooks_retrograde_end. However, it does not explicitly say it registers a webhook or mention the required url, leaving the registration action to the title.

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

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

There is no explicit when-to-use guidance, no mention of alternatives among the many webhook siblings, and no prerequisites. The description also references an undefined 'N days' lead time without explaining how it is configured.

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=false, idempotentHint=false, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds two genuinely useful facts beyond structured data: expected frequency (24/day) and cost (10 credits, Tier 1). It does not disclose auth requirements, or what happens on duplicate registration for a non-idempotent create.

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 compact and front-loaded: the trigger frequency leads, followed by terse Group and Cost metadata. No wasted prose, though the cost/group tags are bracketed metadata rather than explanatory text.

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 non-idempotent registration mutation with 40+ sibling tools, the description omits what the tool actually creates, auth/prerequisite needs, and any differentiation from sibling webhook tools. An output schema exists so return values need no explanation, but the missing action verb and usage routing leave real gaps.

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

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

Schema coverage is 67%; the required 'url' parameter has no description in either the schema or the description. 'fields' and 'precision' are well documented in the schema itself, so the description adds no parameter value and leaves the one mandatory argument completely unspecified.

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 the event trigger ('Fires at every planetary hour boundary (24/day)') but never states the action the tool performs, which is registering a webhook. The verb is only implied by the tool name and title. An agent can infer it from 'astroway_webhooks_*' naming, but the description itself describes the webhook's firing behavior rather than what this call 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?

No guidance on when to use this versus the many sibling webhook/subscription tools, including the near-neighbor astroway_stream_planetary_hour_changes. No prerequisites (auth, existing subscription, deduplication) are mentioned. The Group tag hints at the family but routes nothing.

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 write/idempotency profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true). The description adds two genuinely useful behavioral facts not in the annotations: the event scope (all planets Mercury through Pluto) and the cost (10 credits, Tier 1). It says nothing about delivery semantics, persistence, retry behavior, or how to remove the webhook.

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

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

Two short, front-loaded lines with no filler; the trigger condition comes first and the metadata brackets are compact. The cost/group metadata is arguably structured data rather than description prose, but it costs little 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 explained, but for a stateful webhook registration the description omits the essentials: whether the endpoint must be publicly reachable, what HTTP payload is delivered, whether multiple registrations are allowed, and how the subscription is cancelled. Given the dense webhook/stream sibling set, this is 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 coverage is 67%: fields and precision are well documented in the schema, while the required url parameter carries only format/maxLength constraints and no description. The description adds no parameter meaning at all, so it neither compensates for the url gap nor improves on the documented params. Baseline 3 is appropriate at this coverage level.

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?

Combined with the title, the description identifies a specific event source ('Mercury–Pluto stations direct'), which distinguishes it from the sibling astroway_webhooks_retrograde_start. However, the sentence describes the event rather than the tool action ('registers a webhook'), so the agent must rely on the name to know what the tool actually 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?

There is no when-to-use guidance, no prerequisites (auth, endpoint requirements), and no routing to alternatives such as astroway_webhooks_retrograde_start or astroway_stream_retrograde_alerts, even though the sibling list shows several near-overlapping event subscription 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=false, idempotentHint=false, and openWorldHint=true, so the mutation profile is covered. The description adds genuinely useful context beyond that: the exact event that fires it and the 10-credit Tier 1 cost. It still omits auth requirements, payload shape, and whether duplicate registrations are allowed — notable given idempotentHint=false.

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

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

Two short lines, front-loaded with the triggering condition and followed by compact group/cost metadata. Nothing is wasted, though the single event sentence is doing less than it could.

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. However, for an open-world, non-idempotent registration tool, the description leaves out how the registration behaves (delivery, dedup, auth), which is the main remaining gap.

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

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

Schema coverage is 67%: 'fields' and 'precision' are well documented in the schema while 'url' relies on its uri format alone. The description adds nothing about any parameter, so with the schema doing most of the work, baseline 3 applies.

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

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

The description states the trigger event (Mercury–Pluto stationing retrograde) but never says the tool registers a webhook, so the action itself is only inferable from the name and title. It does implicitly distinguish itself from astroway_webhooks_retrograde_end via 'start', but the verb+resource framing is missing.

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

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

No guidance on when to register this webhook versus polling alternatives such as astroway_stream_retrograde_alerts, nor any note about prerequisites, auth, or how it relates to the retrograde_end sibling. The agent must guess the usage 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?

Annotations declare readOnlyHint=false, openWorldHint=true, and non-idempotent, so the safety profile is partly covered. The description adds useful context in cost (10 credits, Tier 1) and grouping, but discloses nothing about delivery behavior, retries, or subscription lifecycle, which matters for a non-idempotent external webhook.

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 core sentence plus two compact metadata tags; nothing is wasted and the trigger condition is front-loaded. It is short but arguably under-specified rather than bloated.

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 no explanation, and cost/group context is supplied. However, for a non-idempotent webhook registration the description leaves the 'N days' lead-time and delivery semantics unexplained, and the required URL's role in registration is unaddressed.

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%; 'fields' and 'precision' are well documented in the schema, while 'url' relies on format=uri. The description adds no parameter meaning, and its 'N days before' phrasing implies a lead-time setting that no parameter actually exposes, which is mildly misleading.

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 the triggering event ('Fires N days before a solar/lunar/planetary return is exact'), which conveys what the webhook reacts to, but it describes the event rather than the registration action implied by the title 'Register Return-Due Webhook'. It offers no differentiation from the dozen or so sibling webhook 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 webhook versus the many sibling webhooks (eclipse_alert, retrograde_start, transit_trigger, etc.), nor any prerequisites for registration. The agent must infer selection entirely from the name.

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=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the mutation/open-world profile is covered. The description adds event semantics and a credit cost, but says nothing about delivery method, what happens on duplicate registration (relevant given idempotentHint=false), or rate/limit 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?

Two short, front-loaded lines with no filler; the trigger condition comes first and the group/cost metadata is compact. Nothing is wasted, though it is arguably under-specified rather than tight.

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 webhook registration tool the description omits what registration actually does, delivery expectations, and how the required URL is used. Adequate as an event label, incomplete as a tool definition.

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%: fields and precision are documented in the schema, but the required 'url' parameter has no description anywhere, and the description does not compensate. With a required, undocumented parameter, this falls below the baseline-3 case.

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

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

The description names the concrete event ('any tracked planet ingresses a new sign'), which cleanly distinguishes it from sibling webhooks like retrograde_start, eclipse_alert, and void_of_course_start. However, it never states the action the tool performs — that it registers a subscription to a URL — leaving that to the title.

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 choose this webhook over astroway_stream_ingress or other streaming/webhook siblings, nor any prerequisites (auth, URL requirements, duplicate registration). The only implicit signal is the event name itself.

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 this is a write (readOnlyHint=false), non-idempotent, and open-world. The description adds genuinely useful context beyond that: the returned signing_secret, the X-AstroWay-Signature HMAC-SHA256 verification scheme, and a 10-credit cost. It stops short of disclosing lifecycle behavior (update vs duplicate subscription, cancellation).

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

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

Two tight sentences with the core action front-loaded, followed by compact group/cost tags. Every element is relevant, though the partial event list wastes space by being incomplete rather than illustrative.

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 structure need not be explained), and the description still usefully surfaces the signing_secret and cost. But for a write/subscription tool it omits usage routing against the many webhook siblings and gives an incomplete event enumeration, leaving real gaps.

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

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

Schema coverage is only 50%, and the description's event list is misleading: it names three events (report-ready, transit-alert, eclipse-alert) while the schema enum allows twelve, so an agent may wrongly assume those are the only valid values. The fields/precision semantics are already documented in the schema, so the description adds little and arguably introduces confusion.

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 ('Subscribe to outbound webhook deliveries') and names the triggering events, so the agent knows this creates a subscription rather than consuming one. However, it never distinguishes itself from the many per-event webhook siblings (e.g. astroway_webhooks_transit_trigger, astroway_webhooks_retrograde_start), which look like overlapping routes to the same 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?

There is no when-to-use guidance at all: no prerequisites, no statement of when to prefer this generic subscribe over the event-specific sibling tools, and no note on whether re-subscribing to the same event is expected. The agent must infer usage entirely.

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 disclose that this is a non-read-only, open-world, non-idempotent, non-destructive operation. The description adds useful cost context ('10 credits (Tier 1)') and grouping, but does not cover authentication needs, delivery behavior, duplicate handling, or what happens on repeated subscription calls.

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 and front-loaded, with purpose first and metadata tags after. Every sentence and tag carries information without unnecessary wording.

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 that an output schema exists, return-value semantics need not be explained. The annotations cover the safety profile, and the description provides cost and group context, but it leaves usage routing and parameter purpose gaps for a webhook-registration tool with many 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?

The description adds no parameter-level meaning beyond the schema. Schema coverage is 67%, and the required 'url' parameter has no schema description, so the description could help by explaining the callback URL or compact-field usage, but it does not.

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

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

The description states a specific verb and resource: 'Subscribe to natal-transit aspect threshold-crossings.' This clearly identifies the tool as a webhook registration for a particular type of transit event, but it does not explicitly differentiate from nearby siblings such as astroway_stream_transit_alerts or the generic astroway_webhooks_subscribe.

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 or alternatives are given. With many webhook and streaming siblings available, the description does not explain when an agent should choose this tool over astroway_stream_transit_alerts, astroway_webhooks_subscribe, or other webhook variants.

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=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the mutation and side-effect profile is covered. The description usefully adds the trigger timing and a cost (10 credits, Tier 1), but does not explain that registering persists an endpoint, whether repeated calls duplicate subscriptions, or any auth requirement.

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?

Extremely short and front-loaded with no filler; the group and cost tags are compact. It is terse rather than verbose, though the brevity contributes to the missing action verb.

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 the description leaves the core action (registering a webhook endpoint) implicit and offers no guidance on duplicate registration or lifecycle. Adequate but with a notable gap for a state-creating 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 67%: the 'fields' and 'precision' parameters are well documented in the schema, while 'url' relies on format=uri. The description adds nothing about parameters, so it does not compensate for the undocumented required 'url' beyond what the schema conveys.

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 the trigger event ('Fires at the start of every VOC Moon period') but never says what the tool itself does — namely, register a persistent webhook. An agent reading only the description could mistake it for an event stream rather than a subscription-registration call. The name/title disambiguate, but the description itself only partially conveys the purpose.

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 mention of alternatives among the many webhook/stream siblings (e.g. astroway_stream_void_of_course vs astroway_webhooks_subscribe). The only supplementary info is group and credit cost.

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

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

The description describes a read/inventory operation ('List all active...'), yet annotations declare readOnlyHint=false and idempotentHint=false, which assert a non-read, non-idempotent operation. That is an annotation contradiction: an agent relying on the hints would assume listing mutates state. The only behavioral value added is the explicit 10-credit (Tier 1) cost, which is real but does not offset the inconsistency.

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

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

A single tight sentence with the scope qualifiers front-loaded, plus compact [Group] and [Cost] tags that carry genuinely useful operational metadata. Nothing is wasted, though the single sentence is arguably thin for a listing tool that may paginate or return large result sets.

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 the cost tag covers billing. However, for a list endpoint there is no mention of pagination, result limits, or ordering, and the read-only/annotations conflict leaves the agent unsure whether the call is safe — a meaningful gap given the tool's sibling set.

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

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

Schema description coverage is 100%, so the schema already fully documents `fields` (compact-mode dotted paths) and `precision` (decimal rounding). The description adds nothing about either parameter, so the baseline 3 is appropriate; no parameter meaning is lost, but none is contributed either.

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 ('List') and resource ('webhook subscriptions') and narrows scope to 'active' subscriptions 'for the authenticated user', which distinguishes it from siblings like astroway_webhooks_subscribe (create) and astroway_webhooks_id (single record). It is clear and specific, though it never names those siblings explicitly.

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 / when-not-to-use guidance and no alternative named, even though the sibling set contains an obvious complement (astroway_webhooks_subscribe to create, astroway_webhooks_id to fetch one, astroway_webhooks_id_test to test). The agent must infer that this is the discovery/inventory call. Scope of 'active' is stated but not what makes a subscription inactive.

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