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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Despite having no output schema, the description explains the return value, and the invocation-free and cache behaviors are covered. For a one-parameter, read-only estimator this is fully sufficient.

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

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

Schema description coverage is 100% and the single 'endpoints' parameter is fully documented with examples and the leading-slash rule in the schema. The description only restates 'one or more endpoints' without adding format or constraint detail beyond the schema, so baseline 3 applies.

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

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

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

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

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

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

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

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

Annotations already declare the full safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower. The description usefully adds the billing trait (10 credits, Tier 1) and the endpoint, which are real behavioral context an agent cannot get from annotations. It adds nothing about latency, auth, or what the result contains, but no contradiction exists with POST + readOnlyHint.

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 content sentence is front-loaded and waste-free, but the remaining four bracketed tag lines are metadata fragments (group, endpoint, required, cost) rather than prose, making the definition feel like a stub. Nothing is verbose, yet the brevity is under-specification rather than disciplined conciseness.

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

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

This is a high-complexity tool: three nested birth-data objects with timezone, ayanamsa, house-system and precision options. Output schema exists so return values need not be explained, but the description never says what a genogram computes or how the three generations relate, leaving an agent guessing about the tool's actual output intent.

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%, including rich nested per-field docs (tz handling, houseSystem letters, rejected short forms), so the schema does the heavy lifting and baseline is 3. The description only restates the three required parameter names, adding no new semantics for grandparent/parent/child, fields, or precision.

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

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

"Multi-generational family pattern map" names a resource but no verb — it does not say whether it computes charts, draws a diagram, or interprets patterns. It is also not distinguished from close siblings such as astroway_family_system_pattern, astroway_family_parent_child_deep, or astroway_family_sibling_dynamics. Purpose is inferable but 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?

There is no when-to-use guidance and no mention of alternatives, despite four sibling family tools that overlap conceptually. The bracketed [Required: grandparent, parent, child] is input requirements, not usage routing, and duplicates the schema's required array.

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 genuinely new behavioral context not present in structured fields: the HTTP endpoint and the cost of 10 credits at Tier 1, which matters for budget-aware agents. It says nothing further about latency, output shape, or limitations.

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 sentence plus four compact metadata lines, front-loaded with the purpose. Nothing is padded, though the 'Required' line duplicates what the schema already enforces, so it is not quite maximally lean.

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 two-chart synastry tool with nested birth objects, an output schema, and many close siblings, the description is minimally adequate. Because an output schema exists, return values need not be explained, but the 'deep' qualifier is never contrasted with any shallower or alternative family analysis, leaving the agent without routing context.

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 carry extensive inline documentation (coordinate rules, timezone behavior, houseSystem letters). The description only repeats the two required parameter names already declared in the schema, adding no semantics of its own. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'Deep parent-child synastry analysis.' Adding 'synastry' tells the agent this is a two-chart comparison rather than a single natal read, which is more than the name alone conveys. However, it does not distinguish this from sibling family tools such as astroway_family_system_pattern, astroway_family_sibling_dynamics, or the relational synastry tools, so the boundary is left to inference.

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

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

The only routing information is the bracketed metadata block: group, endpoint, required params, and cost. There is no statement of when to choose this over the other family or relational synastry tools, and no exclusions or prerequisites. 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 readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds genuinely useful non-schema context in the cost line (10 credits, Tier 1) and the transport shape (POST endpoint). It says nothing about cohort limits, processing behavior, or how many charts are computed, which a 10-credit multi-member call would warrant.

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 delivers the purpose, and the bracketed metadata lines are compact and scannable rather than prose padding. Nothing is wasted, though the metadata block is presented without any explanatory framing.

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 annotations cover the safety profile. However, for a paid multi-chart family tool the description never explains what defines a cohort (2-8 members), why role assignments matter, or what the credit charge buys, leaving meaningful gaps an agent cannot resolve from structured fields alone.

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

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

Schema description coverage is 67% and the nested birth-data object is documented in exceptional depth, so the schema carries most of the burden. The description only restates '[Required: members]', adding no semantics for the fields or precision compact-mode parameters and no explanation of the members array's 2-8 size constraint or what the optional role enum means for output.

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

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

States a specific resource (Saturn return timing) and a specific scope (across a family cohort), which separates it from the individual-return sibling astroway_prognostics_planetary_return and from other family tools like genogram or sibling_dynamics. It stops short of naming any sibling explicitly, so it is clear but not fully differentiated.

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 when a family-cohort Saturn return is the right call versus a single-chart planetary return, the family genogram, or the family system-pattern tools. The bracketed metadata (endpoint, required param, credit cost) is operational context, 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, closed-world and non-destructive, so the safety profile is covered without the description. The description adds genuinely new operational context the annotations lack — the endpoint and the 10-credit (Tier 1) cost — but says nothing about what is computed, whether both siblings need full birth data, or what the analysis depends on.

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

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

Extremely short and front-loaded, with structured metadata that is easy to scan. It is efficient, though the one-line gloss is close to a restatement of the title "Sibling Dynamics."

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 nested birth-data objects and a parent chart option, a single noun phrase is thin. The output schema covers return values, but the description leaves open what the analysis yields, whether parent is optional, and why one would pick this over the other family or relational endpoints.

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 heavily documented (timezone rules, houseSystem letters, rejected short forms), so the schema carries the load. The description only repeats the required sibling1/sibling2 fields and adds no semantics for parent, fields, or precision, which is the baseline-3 case.

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

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

"Inter-sibling synastry and dynamics" names the resource (synastry between siblings) but uses no verb and never says what is produced or how it differs from close siblings such as astroway_relational_synastry, astroway_family_genogram, or astroway_family_parent_child_deep. An agent can guess the domain but not the output or the boundary against the relational family of 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 when-to-use, when-not-to-use, or alternative-tool guidance at all. The bracketed block gives group, endpoint, required fields and cost, but nothing that helps an agent choose this tool over the many other synastry/relational endpoints.

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, destructiveHint=false, closed-world), so the description needn't restate safety. It adds the endpoint, the credit cost (10 credits, Tier 1) and the required-parameter flag, which are genuinely useful operational facts, but says nothing about what the computation returns or any constraints on the member set beyond the schema.

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

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

Four short bracketed lines, purpose front-loaded, no filler or repetition. It is appropriately sized, though the metadata-block style means very little substance is packed into that compact form.

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 tool that takes 2–8 full natal charts and sits among four other family tools, the description omits what a 'system pattern' actually analyzes and how it differs from its family siblings, leaving a routing 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 nested member schema is unusually rich, documenting date/time formats, timezone handling, and house-system letters in detail. The description contributes only '[Required: members]', which the schema already encodes in its required array, so it adds essentially no parameter meaning beyond the structured fields. 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 phrase 'System-level family astrological signatures' gestures at the tool's domain but names no specific computation or output. It does not distinguish this tool from close siblings like astroway_family_genogram, astroway_family_sibling_dynamics, or astroway_family_parent_child_deep, so an agent cannot tell which family endpoint to pick from the purpose alone.

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

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

The description provides no when-to-use guidance and no exclusions or alternatives. '[Required: members]' and the cost line are preconditions, not usage routing, so the agent is left to infer the tool's role entirely.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The text is short but poorly structured: a vague fragment followed by bracketed metadata lines. It is under-specified rather than concise, and the opening line does not front-load a clear purpose.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The four lines are tight and the purpose sentence is front-loaded ahead of the bracketed metadata block. Nothing is padded, though the metadata lines are boilerplate rather than definitional content.

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

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

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

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

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

Schema description coverage is 67% and the nested chart objects carry extensive inline documentation (formats, rejected short names, timezone semantics, houseSystem letters), so the schema does the heavy lifting. The description only restates the required parameters (chart1, chart2, question), adding no meaning for question, language, fields or precision. Baseline 3 is appropriate.

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

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

The description names a specific verb (coach), the resources (two charts) and the domain (relationship dynamics), so the agent knows this produces interpretive guidance rather than raw chart data. It does not, however, distinguish itself from the many sibling compatibility tools (ashtakoot, dashakoota, compatibility_full) or from astroway_mcp_ai_chat, so sibling differentiation is left to inference.

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

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

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

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false, so the safety profile is covered without the description. The description does add genuinely useful operational context not present in the annotations: the credit cost (100 credits, Tier 4) and the endpoint. However it never explains why a read-only operation is flagged non-idempotent (repeated calls likely yield differently worded narrative), which is the one behavioral trait an agent would most want here.

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

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

The purpose sentence is front-loaded and the payload is small. The '[Required: planet1, planet2, aspectType]' line duplicates the schema's required array, but the cost and endpoint lines justify their space.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is short and front-loads the purpose before the bracketed metadata. The bracketed group/endpoint/required/cost lines are slightly noisy but each carries compact information, so there is little waste.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

States a specific verb+resource+mechanism: 'Server-Sent Events streaming chat completion with optional chart context.' An agent can tell this is a streaming chat tool rather than a static computation. It does not explicitly name or contrast with the closest sibling astroway_mcp_ai_chat, so it stops short of a 5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 100%, so both `fields` and `precision` are already documented in the schema with examples and constraints. The description contributes no additional parameter meaning; the baseline 3 is appropriate.

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds the cost (10 credits, Tier 1), which is useful, but says nothing about what the result contains or that a full natal chart (date/time/lat/lon) is required to derive the sign. Against existing annotations this 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?

The functional sentence is front-loaded and tight; the group/endpoint/cost metadata lines are boilerplate but compact. No wasted prose.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, the description leaves a real gap: it implies the tool is driven by a zodiac sign, while the required parameter set is a full natal birth chart with no sign field, which could mislead an agent about the minimum input.

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 baseline is 3. The description confirms the gender filter is optional, which maps to the nested gender enum in the schema, but adds no explanation of why full birth data is required for a 'sign-aligned' naming tool.

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

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

States a concrete output (name suggestions) and the basis for them (sign alignment), plus an optional gender filter. It is distinguishable from most siblings, though it doesn't explicitly separate itself from astroway_business_name_suggestions or explain that the 'sign' comes from natal birth data rather than a direct sign input.

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 given. The agent must infer that this is the pet-naming tool and that other pet_* siblings cover temperament, diet, etc., with no help from the description.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely new non-schema context: the 10-credit Tier 1 cost and the presence of a disclaimer in the response. It does not cover rate limits, output size/truncation, or any failure modes.

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

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

Front-loaded with the core statement, then bracketed metadata lines that are each short and information-dense (group, endpoint, requirements, cost). No filler prose, though the required-params line partly duplicates the schema.

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

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

An output schema exists, so return values need not be explained. The description covers the essentials (what it computes, required inputs, cost) but omits anything about the crucial timezone/zodiac-system choices that materially change the chart, leaving the agent to discover them in the schema.

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

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

Schema description coverage is only 33% across 15 parameters. The description merely restates the four required fields, which the schema already lists in its required array, and says nothing about the significant optional parameters (timezone, timezoneOffset, zodiacType, ayanamsa, houseSystem, fields, precision). It does not compensate for the low 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?

States a specific verb and resource: 'Full natal chart for the pet (sun, moon, ASC + planets)'. The 'for the pet' qualifier distinguishes it from the human chart tool astroway_western_chart and from the interpretive pet siblings (personality, temperament, etc.), though no sibling is named explicitly.

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

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

The description gives operational metadata (endpoint, required inputs, cost) but no when-to-use guidance, no exclusions, and no pointer to alternatives such as astroway_western_chart or the pet interpretation tools. An agent must infer that this is the raw-computation step versus the interpretation steps.

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 a closed world, so the safety profile is covered. The description adds genuinely useful non-annotation context: the cost (10 credits, Tier 1), the group, and the endpoint. It does not, however, explain what is computed or any constraints on interpretation, and the output schema carries the return 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?

The one-line purpose is front-loaded and the bracketed metadata block is compact and scannable. Nothing is padded, though the boilerplate tags are structural scaffolding rather than substantive 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?

For a 15-parameter chart-derived tool, the description is thin: it never states that output is computed from a natal chart at the given date/time/location, nor hints at the sidereal/house-system choices that materially change the result. Cost is disclosed and an output schema exists, but the agent is left without enough to call this confidently over its pet_* 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 33% across 15 parameters, so the description must compensate — and it does not. It merely repeats the four required names (date, time, latitude, longitude), which the schema already enforces, while the eleven optional parameters (zodiacType, houseSystem, ayanamsa, precision, fields, etc.) go unexplained. Listing required fields is zero-value duplication rather than added semantics.

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?

"How best to communicate with this pet" gestures at the output but names no verb or method — it doesn't say the result is derived from birth data. It also fails to differentiate from close siblings like astroway_pet_temperament, astroway_pet_personality, or astroway_pet_training_style, which an agent could easily confuse with it. Vague but not tautological.

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 pointer to alternatives among the many pet_* siblings. The bracketed [Required] line lists inputs but says nothing about when this tool is the right choice versus temperament, personality, or play_style.

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 useful operational context the annotations do not carry: the endpoint, the four required inputs, and a cost of 10 credits (Tier 1). It still says nothing about what the response contains, though an 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?

The bracketed metadata block is compact and front-loads the endpoint, required inputs and cost, with no filler prose. It is efficient, though the leading sentence is too thin to anchor the entry.

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 chart-derived tool with 33% schema coverage, the definition omits the input semantics the schema does not document and never explains how a pet's sign/element translates into a dietary result. The output schema excuses it from describing return values, but the input and usage gaps remain substantial.

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 at only 33% schema description coverage, the description is expected to compensate, but the only parameter content is the required list (date, time, latitude, longitude), which merely repeats the schema's required array. Nothing is said about ayanamsa, zodiacType, houseSystem, precision, fields, or timezone semantics that the schema leaves thin.

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?

"Element-based dietary focus" conveys a topic (pet diet guidance derived from an astrological element) but never states an action or what artefact it produces, and unlike siblings such as astroway_pet_health_tips or astroway_pet_exercise_needs it does nothing to distinguish itself. The name/title combination plus this phrase is close to a restatement rather than a distinct definition.

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 the neighbouring pet tools (astroway_pet_health_tips, astroway_wellness_diet) or over astroway_pet_grooming_by_element, which is the obvious near-duplicate in the family. Usage must be entirely inferred from the tool name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond annotations — the POST endpoint, the 10-credit Tier 1 cost, and the group — but says nothing about response shape, determinism, 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 single substantive sentence is front-loaded, and the bracketed tags (group, endpoint, required, cost) are compact and scannable. Nothing is padded, though the 'Required' tag is redundant with the schema and could be dropped.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. However, for a 15-parameter tool with three enums, the description leaves too much unspecified — notably what 'element-based' derivation implies and how the pet's chart inputs map to the output — making it merely adequate.

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

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

Schema description coverage is only 33%, so the description carries a real burden, yet it only restates the four required parameters already declared in the schema's required array. Undocumented parameters (zodiacType, cosmogram, ayanamsaId, houseSystem, latitude/longitude semantics) get no clarification here, so it fails to compensate for the coverage gap.

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

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

The description names the resource and output concretely: 'Element-based daily exercise minutes + recommended activities,' which tells an agent exactly what the call produces for a pet. It does not, however, differentiate itself from overlapping pet siblings like astroway_pet_play_style, astroway_pet_diet_by_sign, or the human-facing astroway_wellness_exercise, so an agent cannot tell which to pick from purpose alone.

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

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

There is no when/when-not guidance and no alternatives named. The agent is never told under what circumstances exercise-minutes advice is appropriate versus the neighboring play-style, temperament, or wellness-exercise tools, leaving selection to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-schema context: a 10-credit Tier 1 cost and the mandatory inputs, which matter for an agent budgeting calls. It still says nothing about what the response contains or how the element is derived.

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

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

Very compact and front-loaded: the core purpose leads, with structured bracket metadata for group, endpoint, requirements, and cost. Nothing is padded, though the endpoint string is redundant with the tool name.

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

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

An output schema exists, so return values need no explanation. But for a 15-parameter astrological computation, the description omits how the element is determined, what the grooming guidance is keyed to, and any hint about the optional chart-shaping parameters — leaving the agent under-informed relative to the tool's complexity.

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

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

Schema description coverage is only 33% across 15 parameters, so the description carries a compensation burden it does not meet. It merely restates the four required fields (date, time, latitude, longitude) that the schema already marks as required, and leaves city, name, cosmogram, zodiacType, houseSystem, and ayanamsaId completely unexplained.

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

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

The fragment 'Grooming focus + frequency by element' names the resource (grooming guidance) and the shaping dimension (astrological element), so an agent can broadly infer the output. But it is a terse noun phrase with no verb and never says what 'grooming focus' or 'frequency' actually mean in practice, and it does nothing to separate itself from the many sibling pet_* 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?

The description provides no when-to-use guidance, no when-not-to-use conditions, and never names an alternative among the pet_* siblings. The bracketed metadata (required inputs, cost tier) is operational detail, not 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 cover the safety profile (readOnly, idempotent, non-destructive), so the description's strongest additions are the cost (10 credits, Tier 1), the endpoint, and the medical disclaimer — all behavioral context the annotations do not carry. It does not describe response shape, but an output schema exists to cover 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 prose is one tight sentence and the bracketed metadata block is front-loaded and scannable. Nothing is wasted, though the single prose sentence carries little beyond the title/name.

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?

It supplies the required inputs, cost, and endpoint for a 15-param tool, and an output schema handles return values. It leaves unaddressed how the sign is derived (the pet's chart from date/time/location) and how this tool relates to the many other pet-reading siblings, which is a notable gap given the tool's complexity.

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

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

With only 33% schema description coverage across 15 params, the description compensates partially by enumerating the four required inputs (date, time, latitude, longitude). It says nothing about the optional but consequential parameters (timezone, ayanamsa, zodiacType, houseSystem, fields, precision), which significantly affect output.

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

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

States a specific resource ('sign-specific health vulnerabilities') for pet astrology, so the agent knows exactly what it returns. It does not differentiate itself from nearby pet siblings such as astroway_pet_diet_by_sign, astroway_pet_exercise_needs, or astroway_pet_temperament, so an agent must infer the boundary from the name alone.

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

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

The 'NOT veterinary advice' caveat is a genuine usage constraint and steers the agent away from presenting output as medical guidance. However, there is no when-to-use guidance relative to the other pet tools and no statement of prerequisites beyond the required-params list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds genuinely useful non-schema context — endpoint, required inputs, and a 10-credit Tier 1 cost — which helps an agent budget before calling. It says nothing about what the response contains, and nothing contradicts the annotations.

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

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

The definition is short, front-loaded with the functional sentence, and the bracketed metadata block is easy to scan. Nothing is padded. The only weakness is that its brevity comes at the cost of substance rather than from tight editing of rich 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?

For a 15-parameter astronomical calculation with only 33% schema coverage, the description does not explain how the optional chart parameters interact (sidereal vs tropical, ayanamsa selection, timezone resolution rules) or what distinguishes the output. The presence of an output schema excuses it from describing return values, but the input complexity is left largely undocumented.

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, yet it merely repeats the four required names that the schema already declares as 'required', adding zero semantic meaning. The numerous chart-shaping options (ayanamsa vs ayanamsaId, zodiacType, houseSystem, precision/fields compact mode, timezone vs timezoneOffset) receive no explanation or interaction guidance in the description.

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

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

The description states the resource ('days of week traditionally aligned with the sign'), and the '[Group: Pet Astrology]' tag clarifies the domain, so an agent can tell it is about lucky weekday identification for a pet. However, it never states a verb, never explains whose 'sign' is meant (presumably the pet's Sun sign derived from the birth data), and is close to a restatement of the title 'Lucky Days'. It does not distinguish the tool from sibling lucky-day tools such as astroway_financial_lucky_day or astroway_chinese_feng_shui_lucky_directions.

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

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

There is no 'when to use' guidance, no exclusions, and no mention of the alternatives (astroway_pet_sun_sign_meaning, astroway_financial_lucky_day, the calendar/muhurat tools). The required-parameter and cost lines are operational facts, not usage guidance. An agent must infer the use case entirely from the tool name and group tag.

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 behavior, so safety is covered. The description adds genuinely useful context beyond that: the scoring methodology (element + sign distance), the 0-100 output range, and the 10-credit Tier 1 cost, which matters for budget-aware tool selection.

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

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

The purpose sentence is front-loaded and every remaining line is structured metadata (group, endpoint, required, cost) with no filler. 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?

An output schema exists, so return-value explanation is unnecessary, and required inputs plus scoring basis and cost are provided. For a read-only scoring endpoint this is nearly complete, with only usage routing left unaddressed.

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

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

Schema coverage is 100%, and the nested owner/pet birth-data objects are richly documented in the schema itself. The description only restates the two required params (owner, pet) without adding format or semantics, so the baseline 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb-like outcome, a compatibility score from 0-100, and its basis (element + sign distance), so an agent knows exactly what this returns. It is clear but does not explicitly differentiate itself from other pet tools, relying on the name/title for that.

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

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

There is no guidance on when to use this versus alternatives such as astroway_pet_personality or astroway_horoscope_compatibility. The 'Required: owner, pet' line is prerequisite metadata, not usage context, and no exclusions or alternative-selection rules are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context the annotations lack: the endpoint (POST /v1/pet/personality) and the credit cost/tier, which matters for an agent deciding whether to spend a call. It says nothing about what the breakdown contains or whether the call is expensive in 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?

It is short and front-loads the one-sentence purpose, then switches to bracketed metadata lines that are easy to scan. However, the leading sentence is so thin that the brevity reflects under-specification rather than efficiency.

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 chart calculation with an output schema present, the return values need no explanation, but the description is still far too thin: it never says what the 'personality breakdown' comprises, how it differs from other pet tools, or how the many optional chart settings affect the result.

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

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

With 15 parameters and only ~33% schema description coverage, the description needs to compensate, but it only re-lists the four required fields (date, time, latitude, longitude) that the schema already enforces. It adds nothing about timezone vs timezoneOffset interaction, ayanamsa, house system, or the compact-mode fields 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 'Full personality breakdown' merely restates the title 'Pet Personality Profile' without naming a verb, a resource, or the pet subject. It does not distinguish this tool from close siblings like astroway_pet_temperament, astroway_pet_sun_sign_meaning, or astroway_pet_birth_chart, so an agent cannot tell which of them 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 versus its pet-domain siblings, and no prerequisites beyond the bare list of required inputs. The only usable routing signal is the cost line (10 credits, Tier 1), which is operational rather than guidance 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 readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new operational facts the annotations lack: the endpoint, that four inputs are required, and a 10-credit Tier 1 cost. It does not disclose auth needs or rate limits, but with an output schema present that is acceptable.

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 metadata block is dense and front-loads the required inputs and cost efficiently. However, the actual purpose sentence is a four-word fragment that carries almost no information, so the structure is tidy but under-informative.

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

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

For a 15-parameter tool at 33% schema description coverage, the description should compensate with parameter semantics or usage context and does not. It gives only cost and required inputs; the output schema covers returns, so the remaining gap is parameter meaning and purpose detail.

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

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

Schema description coverage is only 33% across 15 parameters, so several inputs (city, name, ayanamsaId, cosmogram, zodiacType, houseSystem) are undocumented anywhere. The description's '[Required: date, time, latitude, longitude]' merely repeats the schema's required array, adding no syntax or meaning.

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

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

The description is the noun phrase 'Preferred play and toy types', which essentially restates the title 'Play Style + Toys' rather than stating a verb and outcome. The group/endpoint tags situate it within Pet Astrology, but no sibling (e.g. astroway_pet_personality, astroway_pet_exercise_needs) is distinguished.

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 call this instead of the many adjacent pet tools such as pet_personality, pet_temperament, or pet_exercise_needs. The '[Group: Pet Astrology]' tag implies a domain but gives no selection guidance or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful operational context the annotations do not: cost (10 credits, Tier 1), the endpoint, and the group. It stops short of describing anything about the computation or output beyond annotations, 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?

Very compact and front-loaded: one content line followed by tagged metadata. The bracketed fields are scannable and every line carries information. Slightly hurt by being so terse it becomes fragmentary rather than explanatory.

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 with low schema coverage, the description is thin: it never explains why a full birth date/time/location is needed for a 'sun sign' reading, nor scopes the output. The output schema relieves it of return-value documentation, and cost/endpoint are given, but the parameter and usage gaps leave it inadequate.

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 undocumented fields (city, name, date, time, latitude, longitude, cosmogram, zodiacType, houseSystem, ayanamsaId). Instead it merely restates the four required parameters already present in the schema and adds no format, unit, or coordination detail (e.g. how timezone interacts with timezoneOffset, or why lat/long are needed for a sun-sign reading).

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 fragment listing output content ('Personality + temperament + best-suited household') rather than a verb+resource statement. Combined with the name/title, an agent can infer it returns a sun-sign-based reading for a pet, but it never states what it computes or distinguishes the sun-sign variant from siblings like astroway_pet_personality, astroway_pet_temperament, or astroway_pet_birth_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 when-to-use guidance and no routing to alternatives, despite a dense sibling set of overlapping pet tools (pet_personality, pet_temperament, pet_communication_style, pet_birth_chart). An agent must guess whether this or pet_personality is the right call for a given request.

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 behavior, so the safety profile is covered. The description adds genuinely useful non-schema context: the credit cost (10, Tier 1) and the endpoint. It does not explain what 'short' means for depth or output size, nor whether the result is deterministic across calls, so it adds some but not rich behavioral context.

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

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

The main line is a single fragment with zero waste, and the bracketed tags are consistently structured and front-loaded. However, the brevity is closer to under-specification than disciplined concision, and the tag block carries more informational weight than the actual description sentence.

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

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

An output schema exists, so return values need no explanation, and the required-parameter set plus cost are stated. For a 15-parameter chart-derived tool, though, the description is thin: it never says what the temperament summary contains or why sidereal/house-system options matter here, leaving the agent to rely entirely on schema descriptions that cover only a third of the parameters.

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 3 of them are enums whose meanings rest entirely on bare enum lists (zodiacType, houseSystem codes). The description's '[Required: date, time, latitude, longitude]' merely restates the schema's required array and clarifies nothing about the 11 optional parameters, so it fails to compensate for the coverage gap.

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

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

The description states a clear resource and scope ('Short temperament-only summary'), and the endpoint tag (POST /v1/pet/temperament) confirms what is produced. The word 'only' plus 'short' gives some purchase against the sibling astroway_pet_personality, but there is no verb and no explicit statement of how it differs from the other pet readings.

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?

Nothing tells the agent when to choose this over astroway_pet_personality, astroway_pet_sun_sign_meaning, or the other ~13 pet_* siblings. It also does not say when this narrow summary is preferable to a fuller reading. The only inferred usage comes from the title and the word 'only'.

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

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description does not need to restate it. It usefully adds the billing behavior — 'Cost: 10 credits (Tier 1)' — which is genuine context absent from the annotations, but says nothing about latency, caching, or what the three tips are keyed to.

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

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

Purpose is front-loaded in the first line and the bracketed metadata lines are each compact and additive (group, endpoint, required set, cost). No filler sentences, though the metadata block is dense and slightly beyond what an agent needs inline.

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 a low description-coverage schema, the description leaves the bulk of the contract implicit — no mention of defaults, no guidance on whether only date/time/lat/long are usable alone, and no note on how the payload differs when sidereal options are supplied. The output schema covers return values, so that omission is excusable, but the input-side gaps are 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%, so the description is expected to compensate, yet it merely repeats the four required parameters already declared in the schema's required array. The eleven optional parameters (timezone, ayanamsa, houseSystem, precision, fields, etc.) receive no explanation or interaction guidance.

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

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

The first line states a concrete resource and output shape: 'Preferred training style + 3 tips.' An agent knows this produces a training-style reading, not a generic chart. It does not differentiate itself from close pet siblings such as astroway_pet_play_style or astroway_pet_temperament, 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, no exclusions, and no routing to alternatives — the only context is an endpoint, a required-parameter list, and a credit cost. The agent must infer from the name alone that this belongs to the pet reading family.

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 (readOnlyHint, idempotentHint, destructiveHint=false, closed world), so the description carries a reduced burden. It adds the cost tier (50 credits, Tier 3), which is real operational context not present in annotations, but says nothing about what the calculation destroys, requires, or how heavy the response is. Adequate but 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?

Front-loaded definition followed by a compact metadata block; every line is short and scannable. The [Required: input1, input2] line mildly duplicates the schema's required array, which is the only wasted element in an otherwise tight 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?

An output schema exists, so return values need not be explained, and the two-chart input is implied by 'between two charts'. Combined with exhaustive per-parameter schema docs and annotations covering the safety profile, nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100%, with input1/input2 carrying very detailed nested docs (timezone handling, houseSystem letters, rejected short forms) and precision/fields documented inline. The description only restates the two required parameters, adding nothing beyond what the schema already provides. Baseline 3 applies when the schema does all 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?

States a specific verb (calculate) and resource (coalescent chart), and adds a definitional gloss — 'the harmonic chart that resonates most strongly between two charts' — which is genuinely useful for an obscure technique. However, it never distinguishes itself from close siblings like astroway_relational_composite, astroway_relational_davison, or astroway_relational_synastry, so the agent cannot tell from the text alone which two-chart tool to pick.

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

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

The description gives no when-to-use or when-not-to-use guidance and names no alternatives among the many relational tools. The [Group: Comparisons] tag and [Required: input1, input2] block are structural metadata rather than selection guidance, and the cost line tells the agent the price but not the condition that should make it choose this over a composite or synastry chart.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine extra context: the 50-credit Tier 3 cost and the required parameters. However it says nothing about output shape or what the composite is useful for, so it only partially extends beyond structured data.

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

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

A single front-loaded sentence states the operation and method, followed by compact bracketed metadata (group, endpoint, required, cost). No filler, though the bracketed block is terse rather than prose and the whole thing is quite sparse.

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

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

With a rich output schema and full annotations, the description carries a light load, and it does supply method, cost, and required inputs. The one real gap is the absence of any sibling differentiation among the many relational comparison tools, which the agent would need to choose correctly.

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

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

Schema description coverage is 100%, so the nested chart1/chart2 objects and the fields/precision compact-mode parameters are already fully documented in the schema. The description only repeats the two required params, adding no meaning beyond the schema.

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

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

States a specific verb (Calculate) and resource (midpoint composite chart) and explains the method — averaging planetary positions and house cusps of two natal charts. This implicitly distinguishes it from the Davison sibling (a different composite method), though it never names any sibling explicitly.

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

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

No when-to-use guidance is given. Nothing tells the agent when to pick a midpoint composite over astroway_relational_davison, astroway_relational_synastry, or astroway_relational_coalescent. The only routing help is the structural [Group: Comparisons] tag.

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 usefully adds the credit cost and tier (50 credits, Tier 3) and the endpoint, which are not in the annotations. It does not describe the output shape or any constraints on the two input charts.

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 substantive sentence followed by compact bracketed metadata — front-loaded and free of filler. The bracketed lines are terse and skimmable rather than prose padding.

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

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

With annotations, a rich nested input schema, and an output schema, the description need not explain returns. Its one real gap is relational-sibling routing: given the dense cluster of composite/coalescent/synastry tools, an agent needs at least a hint about which to pick.

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

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

Schema description coverage is 100% and the nested chart objects carry extensive field documentation, so the baseline of 3 applies. The description only restates that chart1 and chart2 are required, adding no semantics beyond the schema.

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

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

States a specific verb ('Calculate') and resource ('Davison relationship chart') and even explains the method — the midpoint in time and space between two birth moments. However, it never differentiates itself from its closest sibling, astroway_relational_composite, which is the alternative an agent would most likely confuse it with.

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

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

The bracketed metadata lists required parameters and cost, but there is no statement of when to choose a Davison chart over a composite, coalescent, or synastry chart — all siblings in the same relational group. The agent gets operational facts, not 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 readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful operational context beyond the annotations in the form of the endpoint and, notably, a cost tier (100 credits, Tier 4). It does not add rate limits or failure behavior, so a 3 is appropriate.

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

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

Front-loaded with the core sentence, followed by compact bracketed metadata lines. No filler or repetition, though the '[Required: inputs]' line merely restates the schema requirement.

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

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

An output schema exists, so return-value explanation is unnecessary, and annotations already cover the safety profile. The description supplies cost and endpoint context, leaving the agent adequately equipped to call this read-only multi-chart calculation 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?

With schema description coverage at 67% and the schema fully documenting the non-obvious fields (timezone, timezoneOffset, houseSystem, ayanamsa), the schema does most of the heavy lifting. The description adds no parameter syntax or format detail, 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 gives a specific verb (Calculate), resource (synastry aspects) and scope (simultaneously across 2–8 charts, returning all pairwise cross-chart aspect matrices). This scope distinguishes it from the 2-chart astroway_relational_synastry, but no sibling is named explicitly.

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

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

There is no statement of when to pick this tool over astroway_relational_synastry, astroway_relational_synastry_aspect_grid, or astroway_relational_composite. The '2–8 charts' bound and '[Group: Comparisons]' tag hint at multi-chart use but provide no explicit when/when-not 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavior beyond that: the endpoint (POST /v1/match/score), the cost (50 credits, Tier 3), and the fact that one call replaces a multi-call workflow — which matters for cost-aware planning. It does not discuss latency or auth, keeping it at a solid 4 rather than 5.

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

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

Front-loaded with the tool's identity and output payload in the first sentence, followed by the positioning rationale and the input note. The bracketed Group/Endpoint/Required/Cost block is structured metadata rather than prose, and no sentence is redundant.

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 explanation, and the input schema fully documents the nested chart objects. The description still supplies the selection-critical facts an agent needs — what the aggregate returns, what it replaces, the endpoint, the credit cost, and the shared input shape — leaving no material gap for calling it correctly.

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

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

Schema description coverage is 100% and the nested TwoChart object is exhaustively documented, so the schema carries the parameter burden and 3 is the baseline. The description adds only 'Same TwoChart input as /synastry', which is orientation rather than new field-level semantics; the fields/precision compaction parameters 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?

States a concrete verb+resource — a one-call dating-compatibility aggregate over the synastry engine — and enumerates the exact outputs (overall 0-100 score, label, harmony/tension, attraction score, influential cross-aspects, green/red flags). It also distinguishes itself from the constituent siblings by naming what it replaces (synastry + attraction + custom flag logic), so an agent can tell it apart from astroway_relational_synastry and astroway_relational_synastry_attraction_score.

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 'Built for dating apps that want a single call instead of synastry + attraction + their own flag logic' clause gives a clear selection condition against the sibling tools, and 'Same TwoChart input as /synastry' tells the caller the input contract is shared. It stops short of explicit when-not guidance or naming the sibling tool identifiers directly, so it is clear context rather than full routing.

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