AstroWay Applied readings

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 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description's only added behavioral facts are the cost (10 credits, Tier 1) and the no-write data nature — real value, but thin; it says nothing about rate limits, caching, or what happens if the date range is omitted.

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 that lead with the actual data content, followed by a compact metadata block for group and cost. Nothing is redundant, though the bracketed metadata is bolted on rather than integrated into the 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-value shape needn't be explained. But for a date-range-driven tool the description fails to state the default window when rangeStart/rangeEnd are absent, and it does not clarify the required vs optional inputs — gaps an agent cannot resolve from the structured fields alone.

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% and the description adds nothing about any of the five parameters. Crucially it never explains that birthDate is required nor what rangeStart/rangeEnd do or what the default range is when they are omitted, and it is silent on the compact-mode fields/precision options that the schema only partially documents.

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

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

Names the exact resource (biorhythm), the three cycles with their period lengths (23d/28d/33d), and the extra output (critical zero-crossing days). It also distinguishes itself from the sibling astroway_render_biorhythm by calling itself the 'data twin of POST /render/biorhythm', so an agent can route between JSON data and rendered image without opening either schema.

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

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

The 'data twin' phrasing implies this is the structural-data counterpart to the render tool, which is a useful implicit routing cue. However, there is no explicit when-to-use statement, no mention of the other wellness siblings (astroway_wellness_cycle, astroway_wellness_sleep_cycles), and no stated preconditions such as whether a natal chart must exist first.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context: the 10-credit Tier 1 cost and the Wellness grouping. It says nothing about latency, whether results are cached, or how the sign is derived, but with annotations carrying the behavioral burden a 3 is fair.

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, no filler, and the payload is front-loaded ahead of the group/cost tags. But the brevity is under-specification rather than efficiency: at 15 parameters and 33% schema coverage, this tool needed more sentences, not fewer.

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. Everything else is missing: no usage routing against a near-identical sibling, no explanation of why birth data is required for a sign-based lookup, and no parameter detail to offset the 33% schema coverage. For a 15-parameter, 10-credit call, the description is not sufficient to invoke it confidently.

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

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

Schema description coverage is only 33% across 15 parameters, so the description is obligated to compensate and it does not. It explains zero parameters. Most notably, a tool billed as 'by sign' requires date, time, latitude and longitude, and the description never explains that the sign is computed from natal data rather than passed directly — a significant semantic gap for the caller.

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 payload (primary + supportive crystals + intentions) and the scoping dimension (per zodiac sign), so the resource is identifiable. However, it uses a noun fragment rather than a verb, and it does nothing to distinguish itself from the near-duplicate sibling astroway_esoteric_crystals_by_zodiac_sign, nor from the broader astroway_esoteric_crystals family. That omission is costly given how crowded this namespace is.

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 routing at all. The '[Group: Wellness]' and cost tags are metadata, not guidance. The absence is especially damaging because an agent has no way to decide between this tool and astroway_esoteric_crystals_by_zodiac_sign, astroway_esoteric_crystals_recommend, or astroway_wellness_herbs.

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

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), and the output schema covers return values. The description adds useful operational context by disclosing the group and the 10-credit Tier 1 cost, but says nothing about auth, rate limits, or what 'nearby' means operationally.

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 one compact sentence with the core purpose front-loaded, followed by scoped metadata lines for group and cost. Every element earns its place, though the parenthetical examples slightly lengthen the opener without changing agent 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?

For a read-only, output-schema-backed tool, the description adequately conveys purpose and output scope. However, it leaves usage routing and the roles of birthDate/targetDate unstated, which are the remaining gaps an agent needs to call this correctly versus 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?

Schema description coverage is only 50%: birthDate and targetDate have no descriptions, only patterns. The description's 'age-based' and 'nearby' wording hints that birthDate drives the computation and targetDate anchors 'nearby', but it never explains these two undocumented parameters or their format, so it fails to 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 names a specific resource ('age-based wellness milestones') and gives concrete examples (Saturn return, Uranus opposition, hormonal shifts), plus the output scope ('nearby + full list'). It is clear what the tool returns, but it does not explicitly differentiate itself from overlapping siblings like astroway_family_saturn_return_cycles or astroway_wellness_sleep_cycles.

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 which sibling to prefer for overlapping age-cycle content. The 'nearby + full list' clause describes output scope but gives no selection guidance, leaving usage 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely behavioral fact not in the annotations, the billing cost (10 credits, Tier 1), but says nothing about computation source, latency, or whether the element basis is derived from the supplied birth 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?

The single substantive sentence is front-loaded and waste-free, and the grouped metadata lines are compact. The only minor inefficiency is that the bracketed metadata occupies space without helping selection much, but nothing is redundant or padded.

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

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

An output schema exists, so return values need not be described. However, for a 15-parameter tool with three enums and a terse schema, the description omits everything an agent needs to call it correctly: that a full birth moment and coordinates are required, what the element basis is, and how sidereal vs tropical selection affects the result.

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

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

With 15 parameters and only 33% schema description coverage, the description supplies no parameter guidance at all: it never explains that date/time/latitude/longitude are required birth data, nor what ayanamsa, zodiacType, houseSystem, or the compact-mode 'fields'/'precision' options do. For a low-coverage schema the description is expected to compensate, and 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 names a specific domain (diet) and concrete output content ('emphasize/avoid foods + cooking style'), with the 'element-based' qualifier indicating the astrological derivation. It is clear what the tool returns, but it does not distinguish itself from wellness siblings like herbs, crystals, or exercise that could plausibly be requested in the same context.

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 astroway_wellness_herbs or astroway_pet_diet_by_sign. The agent must infer from the name alone that this tool applies to a person's natal/element profile rather than a pet or a general wellness query.

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=false, idempotentHint=true, and destructiveHint=false, so the safety and idempotency profile is fully covered. The description adds only the cost (10 credits, Tier 1) and group, which is useful but doesn't disclose return format, computation basis, or limits beyond what structured fields provide. With annotations carrying the main behavioral load, 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 a single terse fragment plus two bracketed metadata lines. It is short, which is good, but it is under-specified rather than concise; it lacks the front-loaded clarity an agent needs to select the tool.

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

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

For a 15-parameter (many undocumented) tool with an output schema and rich annotations, the description is far too sparse. It doesn't explain the element-based logic, what 'recommended/avoid activities' contains, or how intensity is derived, leaving the agent without enough context to use it confidently.

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

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

Schema description coverage is only 33% and there are 15 parameters. The description mentions nothing about any parameter, leaving many (city, name, date, time, latitude, longitude, zodiacType, houseSystem, etc.) undocumented in both schema and text. It fails to compensate for the low coverage, so it scores below 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 states the resource (exercise activities and intensity) tied to elements, which is a specific concept, but it doesn't clearly distinguish this from siblings like astroway_wellness_yoga, astroway_wellness_diet, or astroway_pet_exercise_needs. It's a vague fragment rather than a clear verb+resource statement, leaving the agent to infer the tool's exact purpose from the 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?

There is no guidance about when to use this tool versus alternatives like astroway_wellness_yoga or astroway_wellness_diet, nor any mention of prerequisites or exclusions. The agent gets no routing help among the many wellness 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 readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful billing context (Group: Wellness, 10 credits Tier 1), but says nothing about how the chart inputs are consumed or what the herbs output is keyed to.

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 prose is two tight sentences with the core fact (Culpeper rulership, 7 classical planets) front-loaded, followed by compact metadata lines. Nothing is padded, but the structure leaves no room for the input explanation the tool needs.

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, but the description omits the essential framing that this is a chart-derived lookup requiring location and time. For a 15-parameter tool with 4 required chart inputs, that omission is significant.

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

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

Schema description coverage is only 33% across 15 parameters, so the description is expected to compensate, and it does not mention a single parameter. Critically, it gives no hint that date/time/latitude/longitude are required or that they are birth-chart inputs for a herb lookup, which is the most confusing aspect of this tool.

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

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

The description names a specific resource and provenance: herbs keyed to a sign's traditional planetary lord per Culpeper, covering the 7 classical planets. That distinguishes it from wellness siblings like diet, yoga, or crystals. However, it never states that the tool is chart-driven (it reads as a static lookup despite requiring date/time/lat/long), leaving the purpose slightly ambiguous.

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

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

No when-to-use condition, no prerequisites, and no alternatives are named despite dozens of wellness siblings. The agent is left to infer that this should be called after or alongside a natal chart calculation.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds output shape (primary, secondary, vulnerabilities) and cost/tier, which is genuine extra context, but says nothing about how the chart is derived or any auth/rate constraints.

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

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

Two sentences plus compact metadata tags, front-loaded with what is returned. No filler, though the tags consume space without aiding invocation.

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

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

For a complex 15-parameter natal-chart-derived tool with low schema coverage, the description is thin. Output-schema coverage excuses not explaining return values, but the birth-data prerequisite, timezone handling, and sidereal vs tropical choice are left entirely to the schema.

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

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

Schema description coverage is only 33% across 15 parameters, so the description is expected to compensate and does not. It adds no meaning for date/time/latitude/longitude (the required core inputs) nor for ayanamsa/zodiacType/houseSystem, all of which materially change the output.

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 result: body parts ruled by sun-sign per Melothesia, returning primary + secondary + vulnerabilities. An agent can distinguish it from wellness_herbs or wellness_diet, though the description never names a sibling 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?

No when-to-use guidance, no prerequisites, no alternatives. Critically, it never tells the agent that a full birth moment (date, time, latitude, longitude) is required even though the tool is framed as sun-sign-based, so the caller could easily invoke it with the wrong mental model.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds the price tier (10 credits, Tier 1), which is genuinely useful behavior not present in annotations, but says nothing about determinism, latency, or what the profile contains beyond a one-line summary.

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 tightly written sentence that front-loads the computed content, followed by short group/cost metadata lines. Nothing is padded, though the metadata lines are boilerplate rather than substance.

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

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

An output schema exists, so return values need not be explained, and the annotations cover the safety profile. Still, for a 15-parameter calculation tool with low schema coverage, the definition leaves the input side thin and provides no guidance on the tropical/sidereal, house-system or timezone choices an agent must make before calling.

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

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

Schema description coverage is only 33% across 15 parameters, so the description carries a compensation burden it does not meet: it mentions no inputs at all. Several parameters (timezone, timezoneOffset, ayanamsa, precision, fields) carry their own schema prose, but the description adds no semantics, defaults, or hints about which inputs matter for this profile.

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

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

The description names a specific computed artifact: an element profile over the luminaries plus Mercury/Venus/Mars, with a dominant element and strengths/vulnerabilities/coping. That is a clear verb+resource, and it is distinguishable from a generic chart call. It does not, however, differentiate itself from the many sibling element-balance tools (psya_element_balance, arroyo_element_balance, bazi_element_balance), 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 statement of when to reach for this tool versus the other element or wellness siblings, and no prerequisites or exclusions. The only orienting information is the group tag (Wellness) and the credit cost, which tells cost but not applicability.

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 fully covered structurally. The description's real added value is the cost disclosure (10 credits, Tier 1) and the phase-pairing requirement, but it says nothing about return shape or whether recommendations vary by hemisphere/location.

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

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

Two front-loaded sentences with no filler; the core function is stated first and the prerequisite second. The group/cost tags are structured metadata rather than prose 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 not be explained, and annotations cover the safety profile. However, the description leaves the meaning of the required date and the sleep_cycles/moon-phase naming mismatch unaddressed, which an agent would need in order to invoke it confidently.

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%; the 'fields' and 'precision' params are self-documented, but the required 'date' param has no schema description and the description never clarifies whether it is the night of sleep or the date of phase lookup. With the schema doing most of the work, this sits at the baseline rather than compensating for 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?

The description states a specific resource and output type ('Sleep recommendations per moon phase'), which is clear enough to distinguish it from the many other wellness siblings (diet, exercise, herbs, biorhythm). It does not, however, explicitly contrast itself with the closest alternative, astroway_calendar_moon_phase, or explain the 'cycles' framing in the tool name.

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

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

It gives a chaining hint ('Pair with /sun-times to find current phase'), which implies the required workflow context. But it never states when to choose this over related wellness or moon-phase tools, nor any exclusion conditions, so usage is only partially guided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that: it doesn't disclose that output is sign-derived, whether it is deterministic for a given chart, or how the credit cost relates to execution. Given the low bar enabled by annotations, this is a weak addition.

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 very short (one line plus two bracketed metadata tags). Nothing is wasted, but it is under-specified rather than concise: the content is so sparse that 'front-loaded' barely applies.

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

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

For a 15-parameter tool with 33% schema coverage, an output schema, and a dense sibling toolset, the description is far too thin. It omits how the required chart inputs map to a sign, what the result contains, and why this tool is chosen over adjacent Wellness tools. The annotations and output schema lighten the safety/return-format burden, but the purpose and parameter context remain 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 only 33%; 15 parameters exist and the description explains none of them. It gives no hint that date/time/latitude/longitude define a chart whose sign drives the yoga output, nor any guidance on the many optional astrological parameters (zodiacType, ayanamsa, houseSystem). This is a significant gap the description should compensate for.

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

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

The description names a specific domain (yoga) and its content (sign-specific asanas and pranayama), so the purpose is identifiable. However, it is a fragment rather than a stated verb+resource, and it never explains that the output is derived from the input chart or distinguishes it from siblings like astroway_wellness_exercise or astroway_wellness_diet.

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 alternatives (exercise, diet, herbs within the Wellness group), and no statement of prerequisites or how the required date/time/coords relate to getting sign-specific yoga. The agent must infer applicability 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.