AstroWay Relationships

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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact not in the annotations: the 10-credit Tier 1 cost. However it says nothing about what the computed genogram contains or how the three generation datasets interact.

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 terse lines with metadata brackets. It is front-loaded and waste-free, but six substantive words is under-specification for a tool requiring three nested birth-data objects, not true 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 a tool with three required nested objects, an output schema, and several near-identical family siblings, the description omits what the genogram analysis returns and what distinguishes it from the other family pattern tools. An agent could call it correctly from the schema alone but cannot judge relevance.

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 schemas are exceptionally detailed, so the baseline is 3. The description adds no parameter meaning beyond that, but it also does not need to.

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 phrase 'Multi-generational family pattern map' names the artifact produced but contains no verb and does not differentiate from close siblings such as astroway_family_system_pattern or astroway_family_parent_child_deep. An agent can guess it builds a genogram, but must infer that from the tool name rather than the description.

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. The only context is a group tag and a credit cost, which tells the agent nothing about selecting this tool over the other family-astrology 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, closed-world and non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioral fact (10 credits, Tier 1 cost), but says nothing about what 'deep' entails, response shape, or whether both charts must have exact birth times.

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 plus two bracketed metadata lines; nothing is padded or buried. It is terse to the point of being sparse, but every line earns its place.

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

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

An output schema exists, so return values need not be explained, and the input schema is rich. However, for a two-chart, 10-credit analysis the description omits what distinguishes it from sibling family tools and any indication of the scope of the result, leaving it minimally complete.

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

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

Schema description coverage is 100% and the nested parent/child objects are documented in detail (date/time formats, coordinates, houseSystem letters, timezone handling), so the schema carries the load. The description adds no parameter meaning of its own, 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 names a specific pairing and technique (parent-child synastry), which is more than the bare name conveys, but 'Deep ... analysis' largely restates the title 'Parent-Child Deep'. It never distinguishes this from the many adjacent family/relational tools, so the boundary is left to the reader.

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 naming of alternatives such as astroway_family_system_pattern, astroway_family_genogram, or astroway_relational_synastry. The only routing hint is the '[Group: Family Astrology]' tag, which is implied usage at best.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful operational context by disclosing the credit cost (10 credits, Tier 1) and its group, but says nothing about the 2-8 member cohort bounds, batching behavior, 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?

The description is a single front-loaded sentence plus bracketed metadata, with zero padding or redundancy. It is efficient, though the extreme brevity is part of why other dimensions are weak.

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 omits essential calling context: the required cohort of 2-8 birth records, that each member needs full birth data plus optional role, and how Saturn return timing is reported per member. For a multi-member cohort tool this leaves too much to the schema 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?

The description contributes no parameter information whatsoever; it does not mention members, fields, or precision. With schema description coverage at only 67%, the description should compensate for the undocumented parameter surface, 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 astrological technique (Saturn return timing) and a specific scope (a family cohort), which is enough to tell it apart from generic family tools like astroway_family_genogram. However, it never explicitly distinguishes itself from the other family-astrology siblings (parent_child_deep, sibling_dynamics, system_pattern), so the differentiation is implied rather than stated.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as the other family tools. The 'Family Astrology' group tag is metadata, not routing guidance, so an agent must infer when this technique applies versus the sibling family analyses.

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 without the description's help. The definition does add non-obvious operational context in the form of a credit cost and tier, which is genuinely useful for budgeting tool calls, but says nothing about the two-chart inputs, computation weight, 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?

Two lines with zero filler and the core subject front-loaded, so nothing wastes space. However the brevity is under-specification rather than tightness — there is simply too little content 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?

This is a heavy tool: three nested birth-data objects, a compact-mode fields parameter, and a precision control. An output schema exists so return values need no explanation, but the description never mentions that two complete birth charts are required or how this differs from the other family/relational synastry tools, leaving a significant gap.

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

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

Schema description coverage is 100% and the nested birth-data objects are documented in detail, so the baseline is 3. The description contributes nothing about sibling1/sibling2, the optional parent chart, precision, or fields, leaving all parameter meaning 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?

States a recognizable scope — synastry between siblings — but 'dynamics' is vague and the definition never distinguishes this from siblings such as astroway_family_parent_child_deep or astroway_relational_synastry. An agent gets the general subject but not the specific output this tool produces.

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

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

There is no when-to-use guidance, no exclusions, and no named alternative among the many family/relational synastry siblings. The [Group: Family Astrology] tag implies taxonomy but gives no routing logic, so an agent must guess between this and the other family 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 the full safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely useful metadata not present in structured fields: the 10-credit Tier 1 cost and the Family Astrology grouping. Beyond cost, it discloses nothing about what the analysis returns or requires.

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 lines that are short because they are under-specified rather than economical. Bracket tags are present but the core sentence is too thin to guide a call.

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 an output schema and full annotations, a multi-member relational astrology tool surrounded by nine family siblings needs more than a noun phrase. The description leaves the agent unable to know what a "family system pattern" computes or when to prefer it over the other family tools.

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

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

The schema is richly annotated (67% coverage), especially the nested member birth-data object. The description contributes nothing to parameter meaning, not even that members is a 2-8 chart array or what role values do, so it fails to compensate for the uncovered third.

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?

"System-level family astrological signatures" largely restates the title (Family System Pattern) without a verb or concrete output. It never distinguishes itself from the nine sibling family tools (genogram, parent_child_deep, sibling_dynamics, saturn_return_cycles), so an agent cannot tell what unique computation this performs.

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

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

There is no when-to-use guidance, no exclusions, and no named alternative. With so many overlapping Family Astrology siblings, the total absence of routing guidance leaves the agent to guess.

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, and destructiveHint=false, so the safety profile is covered. The description adds value the annotations do not: an explicit cost of 10 credits (Tier 1) and the Pet Astrology grouping, which matters for a paid metered API. It still says nothing about rate limits, latency, or output shape, so it sits at a solid middle.

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 terse fragments with the core capability front-loaded and zero waste; the bracketed group and cost metadata are compact and skimmable. It is efficient rather than padded, though the brevity edges toward under-specification.

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

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

An output schema exists, so return values need not be described, and the 100% schema coverage plus safety annotations carry most of the weight for this simple read-only tool. The remaining gap is the absent usage routing versus siblings, which leaves the description only minimally complete.

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

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

Schema description coverage is 100%, so the schema already documents the birth-data body, fields, precision, and the nested gender filter thoroughly. The description only echoes the gender filter and adds no date/time/coordinate or precision meaning beyond the schema, which is the expected baseline 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 names a concrete output (sign-aligned name suggestions) and an input modifier (optional gender filter), which is more informative than a tautology. However, it does not distinguish this tool from the large set of sibling pet tools (e.g. astroway_pet_sun_sign_meaning, astroway_pet_temperament), so an agent cannot tell from the text alone why it would pick this over them.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the ~30 sibling tools. The only actionable hint is that the gender filter is optional, which is a parameter note 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 the safety profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower. The description adds useful context by naming the returned content and disclosing a 'disclaimer' and a 10-credit Tier 1 cost, but says nothing about computation behavior, precision defaults, or what the sidereal/house-system options actually change.

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 lines with the core content front-loaded and no filler; the metadata tags are boilerplate but harmless. It is efficient, though its brevity is partly under-specification rather than pure 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 values need not be explained, but for a 15-parameter astrological calculation tool with 33% param coverage and no usage guidance, the description is too thin. It omits what the numerous chart-configuration parameters do and when to reach for this tool over its 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 33% across 15 parameters, and the description adds no parameter meaning at all. Several inputs (city, date, name, latitude, longitude, cosmogram, zodiacType, houseSystem) are undocumented in both schema and description, so the description 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?

States a specific verb and resource ('Full natal chart for the pet') and enumerates its contents (sun, moon, ASC + planets), which is more concrete than a bare restatement of the title. It does not, however, explicitly distinguish itself from the many other pet-astrology siblings (pet_personality, pet_sun_sign_meaning), leaving the agent to infer that this is the comprehensive chart.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The only framing is a group tag and cost, which does not tell an agent which of the ~13 pet-astrology siblings to pick.

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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful billing context ('Cost: 10 credits (Tier 1)') that is not in the structured fields, but says nothing about required birth data or what the output contains.

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

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

The description is two short lines, front-loaded with the purpose followed by metadata tags, with no filler. It is efficient, though its brevity is part of the under-specification problem rather than a virtue.

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 15-parameter chart tool with low schema coverage and a crowded sibling set, the description omits input expectations, usage conditions, and sibling differentiation, leaving the agent under-equipped to invoke 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?

With 15 parameters and only 33% schema description coverage, the description carries a heavy burden but contributes zero parameter information. Required inputs (date, time, latitude, longitude) and undocumented fields such as city, name, cosmogram, zodiacType and houseSystem get no explanation from either source.

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 phrase 'How best to communicate with this pet' conveys the general purpose, but it lacks an explicit verb and does not differentiate itself from near-identical siblings like astroway_pet_training_style, astroway_pet_personality, or astroway_pet_temperament. An agent cannot tell from the text whether this returns advice, a chart-derived classification, 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many pet_* siblings. The [Group: Pet Astrology] tag only categorizes the tool; it does not tell the agent when to select this over pet_training_style or pet_personality.

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, non-destructive and closed-world, so the safety profile is covered. The description's only contribution is the cost line (10 credits, Tier 1), which is mildly useful but not behavioral context about the computation, required inputs, or chart dependency. With annotations doing the heavy lifting, this is thin.

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, but the brevity reflects under-specification rather than economy — the one content sentence carries almost no information. The bracket tags consume roughly half of the visible text without helping the agent act.

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 four required positional/time parameters and a cost, the description omits essentially everything an agent needs: no input prerequisites, no mention of the birth-data requirement, no scope or interpretation of the returned diet guidance. The existence of an output schema excuses it from describing return values, but nothing else is covered.

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% (15 parameters, required date/time/latitude/longitude undocumented in the schema), so the description is expected to compensate and it does not mention a single parameter. It never explains that birth date, time, and coordinates are needed for the pet's chart, nor references ayanamsa, houseSystem, or the compact-mode fields.

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 is a noun phrase, 'Element-based dietary focus,' with no verb and no indication of what the tool actually returns or requires. It largely restates the title 'Diet by Sign' while substituting 'element' for 'sign,' which muddies rather than clarifies the basis of the output. Nothing distinguishes it from siblings such as astroway_pet_health_tips or astroway_pet_exercise_needs.

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 alternative among the many pet_* siblings. The '[Group: Pet Astrology]' and '[Cost: 10 credits (Tier 1)]' tags are metadata, not usage instruction. An agent gets no basis for choosing this over pet_health_tips or pet_grooming_by_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, idempotentHint, destructiveHint=false and closed-world behavior, so safety is covered. The description's one added behavioral fact is the cost model (10 credits, Tier 1), which is real operational context not present in structured fields. Beyond pricing it says nothing about determinism per date or rate limits.

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, purpose front-loaded ahead of the bracketed metadata, with no filler. It is appropriately sized for a terse API tool, though the extreme brevity is part of the problem rather than a virtue in the later dimensions.

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 annotations are rich, so return values need not be described. What is missing is the input intent: an agent must guess that the four required birth-data fields must describe the pet, and that date/time are the chart moment rather than the day whose exercise is being computed. For a 15-parameter tool that inference gap is a meaningful shortfall.

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 is expected to compensate, and it does not. It never explains that date/time/latitude/longitude should be the pet's birth data, nor does it touch city, name, cosmogram, zodiacType, or houseSystem — all of which lack any schema description of their own. The word 'Element' hints at the astrological logic but not at any parameter.

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 output: 'Element-based daily exercise minutes + recommended activities.' That is specific enough to separate it from sibling pet tools like play_style or training_style, which focus on behavior rather than quantified exercise. However it never states a verb or the input basis (presumably the pet's natal chart), so the differentiation is partial.

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. The tool sits among many overlapping pet-astrology siblings (pet_play_style, pet_training_style, pet_health_tips, pet_temperament) and the description does nothing to say which question routes here versus there. Only the [Group] and [Cost] tags are present.

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 fully covered. The description's one genuinely additive piece of information is the cost line ('10 credits, Tier 1'), which is billing behavior not present in the annotations. It says nothing about how the chart is computed, what happens with missing optional fields, or any latency/credit-consuming behavior beyond the flat fee.

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 two short lines, front-loaded with the purpose statement and followed by bracketed metadata, with no filler or repetition. It is efficiently structured, though the bracketed tags are tooling boilerplate rather than descriptive content.

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

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

An output schema exists so return values need not be explained, but for a 15-parameter astrological calculation tool with four required inputs the description is far too thin: it omits the input requirements, the derivation logic (birth data to element), and the meaning of the many optional astrology knobs. An agent would have to infer nearly everything from the schema 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 33% across 15 parameters, so the schema does not carry the load, and the description compensates with nothing. It never mentions that date, time, latitude and longitude are required, nor does it clarify the interaction of timezone vs timezoneOffset, the zodiacType/ayanamsa choice, or the compact-mode fields/precision pair.

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 phrase 'Grooming focus + frequency by element' names the resource (pet grooming guidance) and its organizing axis (elemental astrology), but gives no verb and never explains that the element is derived from the birth-chart inputs rather than supplied directly. It does not distinguish itself from close siblings such as astroway_pet_diet_by_sign, astroway_pet_health_tips, or astroway_pet_training_style, all of which produce parallel 'advice by astrological factor' outputs.

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 prerequisite information (e.g., that a pet's birth date/time/place is needed), and no mention of any alternative sibling tool. The only contextual text is a group tag and a credit-cost tag, which do not help an agent decide whether this is the right tool for a grooming question.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a non-veterinary-use disclaimer and the credit cost, but does not disclose output behavior or limitations beyond that.

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 and front-loads the tool's purpose and disclaimer. The group and cost metadata are compact, though the description is arguably too terse given the tool's input 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?

An output schema exists and annotations cover the safety profile, but the description is still incomplete for a 15-parameter tool with low schema description coverage. It does not explain what birth data is required, how the sign is derived, or when to use this tool versus sibling pet-astrology tools.

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

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

The schema has 15 parameters with only 33% description coverage, and the required birth data parameters (date, time, latitude, longitude) have no schema descriptions. The tool description mentions no input parameters at all, so it does not compensate for the low schema coverage.

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 output: sign-specific health vulnerabilities for pets, plus a clear disclaimer that it is not veterinary advice. It is understandable in context, but it does not explicitly differentiate itself from the many sibling pet-astrology 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 call this tool versus alternatives such as astroway_pet_birth_chart or astroway_pet_temperament. The only boundary given is the disclaimer 'NOT veterinary advice', which is important but not usage routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the operational detail of cost (10 credits, Tier 1), which is genuinely useful and not in annotations, but discloses nothing about computation, determinism vs. transit-dependence, or rate behavior.

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

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

The content is short and front-loaded with no wasted words, which is good, but it is terse to the point of under-specification. Brevity here reflects missing content rather than efficient editing.

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, 4-required-parameter tool, the description omits the essential context that the caller must supply a pet's birth date, time, and coordinates, and which sign is being referenced. An output schema exists so return values need not be explained, but the input-side gap is large.

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 carries a heavy burden and adds no parameter meaning at all. The four required params (date, time, latitude, longitude) are completely undocumented in both the schema and the description, so an agent gets no help on how to supply the birth data that drives the result.

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

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

The phrase 'Days of week traditionally aligned with the sign' describes the output resource (weekdays tied to a zodiac sign) but is a noun fragment with no verb, so it never states what the tool actually does or computes. It gives no differentiation from the many other astroway_pet_* siblings beyond the '[Group: Pet Astrology]' tag.

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 (e.g., that a pet birth chart's date/time/place drive the result), and no mention of alternatives among the 15+ pet tools. Only the group tag hints at 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 establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description earns credit by disclosing the pricing tier (10 credits, Tier 1) and the deterministic scoring basis, which are real cost/behavior facts an agent needs before calling. It stops short of stating that both owner and pet charts are mandatory inputs.

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

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

Two short lines, outcome front-loaded before the group and cost metadata. Nothing is padding given how little it says.

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 nested birth-data schema is exhaustively documented. Still, for a two-chart nested-input tool the description never confirms that both owner and pet charts are required or what the score means interpretively (e.g., what counts as compatible).

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 100% schema description coverage, the schema already documents the owner/pet birth-data objects, timezone handling, fields and precision in depth. The description adds nothing about inputs, which is acceptable at baseline but not additive.

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 deliverable (a 0-100 compatibility score) and the method (element + sign distance), which is concrete. It does not explicitly contrast with the many relational synastry/match siblings, though the pet-scoped name and the phrase 'owner-pet' implicitly separate it.

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 choose this over alternatives such as astroway_relational_match_score or the pet temperament tools, and no prerequisite guidance. The reader must infer usage entirely from the name and the scoring formula.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description does add genuinely useful non-schema context that annotations omit: a credit cost of 10 (Tier 1) and the Pet Astrology grouping. It says nothing about return shape or limits, but with an output schema present and annotations covering safety, 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, front-loaded with the core statement, with no filler. The metadata lines are compact and arguably useful. It is efficient, though its brevity shades into under-specification rather than pure 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 a 15-parameter tool in a dense family of near-identical pet-analysis siblings, the description omits what makes it distinct, what the breakdown contains, and what the required birth data represents. The output schema relieves it of describing return values, and annotations cover safety, but the differentiation and input-orientation gaps are significant for this complexity level.

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 for the undocumented ones (city, name, date, time, latitude, longitude, cosmogram, zodiacType, houseSystem, ayanamsaId). It supplies zero parameter information – not even that a pet's birth date, time, and coordinates are required. The schema does document fields/ayanamsa/timezone/precision/timezoneOffset well, but the description leaves the coverage gap entirely unaddressed.

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 phrase "Full personality breakdown" names a resource (pet personality) and implies a verb (produce an analysis), so the general purpose is discernible. However, it never distinguishes itself from close siblings like astroway_pet_temperament, astroway_pet_sun_sign_meaning, or astroway_pet_communication_style, which all read as personality-adjacent. The word "Full" hints at breadth but no concrete scope is given.

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 contains no when-to-use guidance, no prerequisites, and no routing to alternatives, despite thirteen sibling pet tools that could plausibly be chosen instead. The only bracketed metadata is group and cost, which is not usage guidance. An agent must guess based on 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The only added behavioral fact is the 10-credit Tier 1 cost, which is real but boilerplate. Nothing about what the reading contains, how heavy the computation is, or failure modes is disclosed.

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

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

The purpose line is front-loaded and wastes no words, and the bracketed metadata is compact. However its brevity here reflects under-specification rather than efficient communication, since a single fragment cannot carry the load of a 15-parameter 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?

An output schema exists, so return values need no explanation, and annotations cover safety. But for a 15-parameter, credit-costed chart computation, the description supplies neither usage context nor parameter help, leaving the agent with substantially less than it needs to call the tool correctly.

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

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

15 parameters with only 33% schema description coverage, and the description explains none of them. Required fields (date, time, latitude, longitude) and the many optional astrological controls (ayanamsa, zodiacType, houseSystem, timezone) are left entirely to the schema, which itself is sparse. The description does not compensate for the coverage gap at all.

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 "Preferred play and toy types" essentially restates the title "Play Style + Toys" and the name astroway_pet_play_style without adding a distinct verb, scope, or output framing. It does not distinguish this from near-neighbors such as astroway_pet_exercise_needs or astroway_pet_temperament. This is close to tautology.

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 routing is provided. With ~25 pet-related siblings, an agent has no textual basis for choosing this tool over astroway_pet_exercise_needs, astroway_pet_training_style, or astroway_pet_temperament. The group/cost metadata 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, and closed-world, so the safety profile is covered. The description adds genuine behavioral value by disclosing the cost (10 credits, Tier 1), which is not in any structured field, but it says nothing about computation, auth, or what happens with missing inputs.

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

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

It is short and the group/cost tags are front-loaded, but the body is an under-specified fragment rather than a complete statement, so brevity comes at the cost of information rather than from efficient editing.

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 15-parameter chart-calculation tool requiring date, time, and coordinates, the description omits input requirements, timezone handling, and any usage context. An agent has almost nothing to act on beyond the cost tag.

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

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

Schema description coverage is only 33%, so the description is expected to compensate, and it does not mention a single parameter. The four required inputs (date, time, latitude, longitude) carry no descriptions anywhere, and complex fields like timezone vs timezoneOffset 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 is a noun fragment listing output categories ("Personality + temperament + best-suited household") rather than a verb+resource statement of what the tool computes. It never says it derives meaning from the pet's Sun sign, and it fails to distinguish itself from siblings astroway_pet_personality and astroway_pet_temperament, whose names overlap directly with the stated outputs.

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, despite many near-identical pet siblings. The [Group: Pet Astrology] tag gives domain placement only, which is not usage direction.

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 closed-world, so the safety profile is covered. The description usefully adds billing context (10 credits, Tier 1) that annotations do not carry. It stops short of explaining anything about the computation or data dependencies, so it adds moderate value only.

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

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

The description is tightly front-loaded: the core purpose leads and group/cost tags follow as metadata. No sentence is wasted. It is perhaps overly terse, but the dimension rewards efficiency and it delivers that.

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 astrological computation tool embedded among ~14 similar pet_* tools, a single-line description is inadequate. The output schema covers return values, so that is not the gap; the gap is that nothing explains inputs, computation basis, or how it differs from sibling pet reports. An agent lacks enough 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 carries a compensation burden it does not meet. It mentions no parameters at all (not date, time, coordinates, ayanamsa, or houseSystem), leaving required inputs like latitude/longitude undocumented in prose. The low coverage plus zero description contribution yields a 2.

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 phrase 'Short temperament-only summary' names the resource (a temperament summary) but gives no verb and no scope detail. It fails to distinguish itself from the close sibling astroway_pet_personality, which an agent could easily confuse with it. Purpose is implied but not sharp.

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

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

There is no statement of when to use this tool versus the many pet_* siblings (pet_personality, pet_play_style, pet_communication_style, pet_birth_chart). The only extra context is group/cost metadata, which does not guide selection. An agent must guess 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds only the cost disclosure (10 credits, Tier 1) and group tag, which is genuinely useful budget information but says nothing about what data is consumed or how results are shaped.

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

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

The text is short and front-loaded with the deliverable, which is good, but it is under-specified rather than efficient — the single content line does not carry enough information to justify the omission of usage and input guidance.

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 15-parameter chart tool with 33% schema coverage the description should at least indicate that a birth date/time/place is required and how this result differs from the other pet tools. It does not.

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

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

Schema description coverage is only 33% across 15 parameters, and the description compensates for none of it. The four required parameters (date, time, latitude, longitude) are undocumented in both places, and the enums and compact-mode options 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 names the deliverable ('Preferred training style + 3 tips'), so an agent knows roughly what content comes back, but there is no verb and no mention that it derives from birth-chart data, which is the tool's actual operation. It sits adjacent to siblings like astroway_pet_play_style and astroway_pet_temperament without stating how it differs from them.

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

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

There is no when-to-use statement, no prerequisites (e.g. that date/time/lat/long are required), and no routing to or away from sibling tools such as astroway_pet_play_style. The agent must infer everything about invocation 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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds two things those fields do not carry: the operational cost (100 credits, Tier 4) and the shape of the result (all pairwise cross-chart aspect matrices), which tells the agent the output volume scales quadratically with input count.

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 tightly packed lines: the capability statement first, then bracketed group and cost metadata. No filler, no restatement of the title, and the scoping constraint ('2–8 charts simultaneously') is front-loaded where it matters.

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 line covers the main operational unknown. Still, for a tool taking an array of full birth-data objects the description omits that inputs are per-chart natal birth data, gives no guidance against the pairwise sibling, and its 2–8 claim conflicts with the schema's maxItems of 10.

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 description adds nothing about `fields` or `precision`, so it neither compensates nor extends the schema there. Worse, it states a chart range of '2–8' while the schema's inputs array declares minItems 2 and maxItems 10, so an agent trusting the prose would wrongly refuse a 9- or 10-chart request.

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

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

States a specific verb and resource ('Calculate synastry aspects') plus the distinguishing scope ('among 2–8 charts simultaneously', 'all pairwise cross-chart aspect matrices'), which separates it from the two-chart astroway_relational_synastry sibling. It never names that sibling or any other alternative, so the differentiation is implied by scope rather than stated.

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

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

The description says what the tool computes but gives no when-to-use or when-not-to-use guidance: nothing about preferring this over astroway_relational_synastry for a pair, over astroway_relational_synastry_aspect_grid, or over the composite/Davison tools. The credit tier hints at cost sensitivity but stops short of any routing advice.

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, non-destructive and closed-world, so the safety profile is fully covered. The description adds the aggregation behavior and the credit tier (50 credits, Tier 3), which is genuinely useful, but it largely enumerates return contents that the output schema already documents, so the net addition is moderate.

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

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

Front-loads the aggregate purpose and the return payload, then the routing guidance, with little waste. The trailing 'Same TwoChart in…' is truncated mid-sentence, which slightly hurts structure but the delivered content is efficient.

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

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

For a read-only aggregate with a full output schema and thoroughly documented nested input objects, the description covers what an agent needs: what it computes, why to prefer it over composing siblings, and the cost. No major gap remains, though the truncated final sentence leaves a small hole.

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 chart1/chart2 objects are richly documented in-schema (timezone handling, houseSystem letters, rejected short forms). The description says nothing about the parameters, so it adds no meaning beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('one-call dating-compatibility aggregate over the synastry engine') and enumerates exactly what it returns: overall score, label, harmony/tension, attraction score, influential cross-aspects, and green/red flags. This clearly distinguishes it from narrower siblings like astroway_relational_synastry_attraction_score or astroway_relational_synastry_aspect_grid.

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 frames the use case and the alternative: 'Built for dating apps that want a single call instead of synastry + attraction + their own flag logic.' That routes the agent between this tool and composing the narrower siblings. It lacks an explicit when-not-to-use statement or named sibling tools, keeping it below a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: with timeUnknown the cross-aspects are still returned while that partner's houses, angles and sect come back null, and it discloses the 50-credit Tier 3 cost.

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 purpose and the timeUnknown caveat are front-loaded in two tight sentences, and the bracketed group/cost metadata is compact. Slight redundancy with the schema's own timeUnknown text keeps it from a 5.

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 four-parameter, nested-object tool with a full output schema present, the description covers the operation and its most important edge case. The main gap is sibling differentiation, since several relational tools overlap in apparent function.

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 chart objects carry their own detailed descriptions (timezone, ayanamsa, timezoneOffset, timeUnknown), so the schema does the heavy lifting. The description's timeUnknown sentence largely restates what the chart1/chart2 schema already says, adding no syntax or format detail beyond it.

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

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

The description gives a specific verb+resource ('Calculate cross-chart aspects between two natal charts') and a use case ('relationship analysis'), which separates it from composite/davison siblings that derive a single merged chart. It does not, however, distinguish itself from the very similarly named astroway_relational_synastry_aspect_grid, which an agent could easily confuse with it.

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

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

There is no statement of when to use this tool versus astroway_relational_synastry_aspect_grid, astroway_relational_match_score, or the composite/davison alternatives. The timeUnknown note describes an input edge case rather than usage routing, so an agent gets no explicit selection guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds useful output-shape context (cells contain an aspect or null; default 13x13 covering Sun..Pluto plus nodes, Lilith and Chiron) and a cost signal (50 credits, Tier 3), but says nothing about error behavior or limits beyond what annotations already give.

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 tightly written sentences: the core behavior and its default dimensions are front-loaded, and the group/cost tags are compact structured metadata. Nothing is wasted and nothing important is 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?

For a read-only computed tool with a full output schema and 100% param coverage, the description adequately explains what is produced, and an output schema removes the need to document return values. However, given the crowded relational-tool family and two large nested chart inputs, the absence of any routing or usage guidance leaves it only minimally complete.

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

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

Schema description coverage is 100%, so the rich nested chart1/chart2 schemas do the heavy lifting and the baseline is 3. The description's mention of the default body set relates to the output matrix rather than to any input parameter, so it adds little parameter-level meaning beyond the schema.

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

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

The description names a specific resource (an NxM cross-chart aspect matrix between two charts) and even specifies the default grid composition, so an agent knows exactly what artifact this returns. It does not explicitly distinguish itself from neighboring relational tools such as astroway_relational_synastry or astroway_relational_synastry_house_overlay, so it stops short of a 5.

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

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

There is no when-to-use guidance and no named alternative. With many sibling relational tools (synastry, house_overlay, element_balance, match_score), an agent gets no help deciding when the aspect grid is the right pick versus those overlaps.

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. The description adds genuinely non-redundant context: the cost (50 credits, Tier 3) and the fact that the output is a weighted composite over a fixed set of contact types, which tells the agent the result is deterministic for a given pair of charts. It stops short of describing latency or credit-refund 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?

A single front-loaded sentence names the weighting and the constituent contacts, followed by two compact metadata tags for group and cost. Nothing is padded or repeated, though the tags are terse enough that they read as structured metadata rather 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?

With an output schema present, the description need not explain return values, and annotations cover the safety profile. What remains missing is routing guidance against the many sibling synastry/relationship tools. Given the rich nested input schema and cost disclosure, the definition is close to complete but leaves sibling disambiguation to the caller.

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%, with chart1/chart2 carrying extensive prose about timezone handling, house-system letters, and rejected shorthand field names, plus the fields and precision compact-mode parameters. The description adds nothing beyond what the schema already says, 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 states a precise verb-and-resource outcome: a weighted 0–100 attraction score derived from named synastry contacts (Sun-Moon, Mars-Venus, ASC/DSC, etc.) and the 5th-house overlay. That is far more specific than the title alone. It does not, however, differentiate itself from the near-identically named sibling astroway_rel_synastry_attraction_score or from astroway_relational_match_score, so an agent cannot tell which of the two attraction/match variants 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 when-to-use guidance, no prerequisites, and no alternatives named despite several overlapping siblings (relational_match_score, rel_synastry_attraction_score, relational_synastry). The agent must infer the selection criteria entirely from the tool name and score composition.

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