AstroWay Reports

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

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

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

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

Three efficient sentences: purpose, usage guidance, and return format. Front-loaded with key information, no wasted words.

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

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

Despite lacking an output schema, the description specifies the return format (plain-text human-readable summary). For a simple status check tool, this is complete and sufficient.

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

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

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

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

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

Description clearly states the verb 'Check' and the resource 'API key status' with specific attributes (tier, credit balance, rate limits, monthly cycle reset). It distinguishes itself from the many sibling astrology calculation tools.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 100%, so every one of the six parameters is already documented in the schema, including the format enum and the select/fields/precision semantics. The description restates the format option rather than adding new meaning, so the baseline 3 for full schema coverage applies.

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

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

The description states a specific verb and resource: returning agent tool definitions generated from the live OpenAPI document, in either OpenAI or Anthropic shape. That is clear enough to differentiate it from report/chart tools in the namespace, but it never names the closest sibling (astroway_mcp_tools_list) or explains the distinction, so it falls short of a 5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already establish readOnly, idempotent and non-destructive behaviour, so the safety bar is low. The description adds genuinely useful operational facts the annotations do not carry: the tool is an MCP Advanced feature costing 100 credits (Tier 4). It still says nothing about how rounds affect runtime or output, or whether chart context is mandatory for a meaningful debate.

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

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

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

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

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

This is a high-complexity tool: 8 parameters, a nested chart object with detailed validation rules, and an output schema. The description covers none of that complexity and omits the astrological framing entirely, leaving an agent to infer from the schema alone what inputs matter. Output format is covered by the output schema, so that omission is acceptable, but the rest is a real gap.

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

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

Schema description coverage is only 38% and several parameters (topic, agentA, agentB, rounds, language) carry no schema description, so the description is expected to compensate — and it does not, adding no parameter meaning whatsoever. 'multi-round' only obliquely hints at the rounds parameter, and nothing explains what agentA/agentB strings should contain or how chart is consumed.

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

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

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

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

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

There is no when-to-use guidance at all: no statement of what situation calls for a two-persona debate over a single-shot chat, no prerequisites, and no mention of alternatives. The only extra text is group and cost metadata, which is billing context rather than usage guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely new context by disclosing a 10-credit Tier 1 cost, but omits what the status payload represents or whether it reflects live pool state.

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

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

It is very short and front-loads the one substantive fact, but the first sentence is a dangling fragment rather than a complete statement of purpose, and the bracket tags read as metadata padding rather than description.

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

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

With an output schema present, return values need not be explained, and annotations cover safety, so the description's remaining burden is small. It is still thin on what 'pool status' reports and when it should be invoked, leaving a minor gap for a zero-required-parameter status tool.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Three tight sentences, front-loaded with the core differentiator ('answered from the positions we computed') before secondary facts about history, languages, and pricing. The trailing group/cost tags are metadata rather than prose, so there is minimal waste.

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

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

An output schema exists, so return values need not be explained, and the description covers the AI-behavioral surface (grounding, history, language, persona, cost). For a 7-parameter tool with nested objects and low schema coverage, it could say more about the chart input contract, but the essentials are present.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is short and front-loaded, with cost and group metadata placed clearly after the core sentence. It wastes no words, although it is arguably too sparse for a tool of this complexity.

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

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

For a 6-parameter tool with nested chart objects and multiple AI/synastry siblings, the description is far too thin. The output schema covers return values, but the description does not explain what 'coaching' entails or when to select this tool over alternatives, leaving a substantial contextual gap.

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

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

Schema description coverage is 67%, and the description adds no parameter-level meaning beyond the schema. It says 'two charts' but does not clarify the role of the required question field, language, precision, or fields parameters, nor does it help compensate for the less-documented parameters.

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

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

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

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

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

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

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

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

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

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

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

It is short and front-loaded, but the terseness here reflects under-specification rather than efficient communication. The metadata lines consume half the length without adding invocation help.

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

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

An output schema exists, so return values need no prose, but the description leaves key input questions open: how planets must be named, which chart object is required for a natal calculation, and what the aspectType enum means in context. For a 7-parameter tool with a nested birth-data object, this is thin.

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

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

Schema description coverage is only 43%, and the undescribed parameters include the three required ones (planet1, planet2, aspectType). The phrase 'between two planets' loosely implies planet1/planet2 but gives no naming convention or accepted values, and aspectType, language, fields and precision get nothing despite the gap.

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

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

States a specific verb and resource: an explanation of an aspect between two planets. An agent can tell what it does, though it never contrasts itself with the sibling astroway_mcp_ai_explain_transit, which is the nearest alternative.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 38% and the five required parameters (chart, transitDate, transitPlanet, natalPlanet, aspectType) carry no schema descriptions at all. The description only obliquely implies a transit/natal pairing and says nothing about expected values or formats for those required fields, so it does not compensate for the coverage gap.

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

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

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

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

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

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

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

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

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

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

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

The text is very short and front-loads the core action before the group and cost tags. No sentence is wasted, though the brevity reflects under-specification rather than thorough contextual completeness.

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

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

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

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

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

Schema description coverage is only 50%, and the description adds no parameter-level meaning for question, agents, chart, fields, language, or precision. In particular, the required 'agents' array and its 2-4 item constraint, as well as how 'chart' relates to the question, are left entirely to the schema.

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

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

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

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The closest sibling, astroway_mcp_agent_debate, is not mentioned, and the cost tier alone does not tell an agent when this tool should be selected.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered elsewhere. The description adds only the cost tag (10 credits, Tier 1); it says nothing about batch limits, what the compact response excludes, or the idempotentHint=false implication that repeated calls may vary.

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

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

The single sentence plus metadata tags are front-loaded and free of padding, so it is structurally clean. However, the brevity here is under-specification rather than conciseness: the sentence carries almost no callable information.

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

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

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

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

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

Schema description coverage is only 50%, so the description is expected to compensate — and it does not. The compact-mode controls (fields, precision) and the intent enum are never mentioned in the description, leaving the agent to discover their meaning entirely from the schema.

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

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

"Compact context for MCP agents working across multiple charts" restates the tool name (multi-chart context) without a concrete verb or resource for what is actually produced. It never says it computes natal chart data for multiple subjects, nor does it distinguish this tool from sibling report/chart tools like astroway_reports_natal or astroway_reports_synastry.

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

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

The only usage signal is the implied "working across multiple charts," from which an agent might infer batch multi-subject use. There is no explicit when-to-use, no exclusions, and no mention of when a single-chart or report sibling is preferable, despite ~40 alternatives.

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is moderate at 60%, and the description adds no parameter meaning at all. It does not clarify what 'query' should contain, how 'topK' affects results, or how 'chart' is used, so key semantics remain dependent on the schema alone.

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

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

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

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternatives to consider. It only supplies group and cost metadata, leaving the agent with no routing signal among the sibling tools.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, open-world, non-idempotent). The description adds two genuinely useful behavioral facts beyond them: the response arrives as Server-Sent Events, and each call costs 100 credits (Tier 4). It says nothing about auth requirements, rate limits, or what the stream events look like, so it is adequate but not rich.

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

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

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

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

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

For a 5-parameter tool with a nested birth-chart object, no output schema, and only 60% schema description coverage, the definition is thin. It does not describe the streamed response shape, streaming lifecycle, or the required message parameter, and gives no guidance on how chart context should be formed.

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

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

Schema coverage is 60% and the nested chart object carries extensive inline documentation that the description does not repeat. The 'optional chart context' phrase confirms the chart parameter exists but adds no semantics for message, language, fields, or precision, so it does not compensate for the coverage gap.

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

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

States a specific verb and resource: an SSE streaming chat completion, with the chart-context option noted. It is clearer than a bare 'chat', but it never distinguishes itself from sibling astroway_mcp_ai_chat (presumably the non-streaming counterpart) or astroway_mcp_tool_call_stream, so the agent must guess which chat entry point to pick.

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

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

No when-to-use, when-not-to-use, or alternative guidance is given. The description notes that chart context is optional but never says when you should supply it or how it changes the answer, and it never mentions the sibling chat tools as alternatives.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There is no statement of when to use this tool, when not to, or what alternative exists for the same need. The only context is the group/cost tag, which tells the agent a price but not a use case.

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

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

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

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

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

The description is short and front-loads its main claim about being an auto-generated manifest. The bracketed group and cost lines add metadata without excessive verbosity. It is efficient, though the bracket metadata is only marginally useful for tool selection.

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

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

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

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

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

Schema description coverage is 100%, so both parameters (fields and precision) are already fully documented in the schema. The description adds no parameter-level meaning beyond what is in the input schema. With complete schema coverage and no additional description detail, a baseline 3 is appropriate.

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

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

The description says it is an auto-generated tool manifest for MCP clients, which identifies the general resource but uses no action verb and does not explicitly state that it lists available MCP tools. It also does not distinguish this tool from nearby siblings such as astroway_agent_tools or the MCP-related tools. Purpose is therefore implied rather than clearly stated.

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

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

The only usage context is the phrase 'for MCP clients,' which implies an audience but gives no guidance on when to call this tool versus alternatives. It does not mention prerequisites, exclusions, or sibling tools. This is the same level as a definition that provides only an implied context.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds a genuinely useful non-schema trait: the 250-credit Tier 5 cost and an explicit "confirm with user before invoking" caution. It also notes the computation (fast and slow planet transits within the month). It does not mention non-idempotency/repeat-cost, which would have pushed it higher.

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 purpose in the first clause, followed by a comparative scope note, an input list, and clearly demarcated group/cost metadata lines. Compact and well-ordered, with only the input enumeration bordering on restating 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?

For a complex tool (8 params, nested chart object, output schema present), the description supplies purpose, scope, and cost without needing to explain return values. It is complete enough for correct selection and invocation, though it leaves the non-required compact-mode params (fields, precision) 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 low (38%), so the description should compensate, but it only enumerates input names ("chart, year, month (1-12), language, tone, length") without adding meaning beyond the schema's own ranges and enums. It omits the two parameters not listed (fields, precision) and gives no format detail for chart or language/tone/length, so it adds little semantic value over the structured fields.

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

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

States a specific resource and output type ("Single-month forecast") and distinguishes its scope from a named sibling concept ("Tighter scope than year-ahead"), which lets an agent separate it from the year-ahead narrative without opening the schema. It stops short of routing against the other narrative siblings (natal, synastry, transit), 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?

"Tighter scope than year-ahead" implies when this tool is the right choice versus the year-ahead sibling, and the cost warning tells the agent to confirm before invoking. However there is no explicit when-not statement or routing among the many other narrative tools, so guidance is implied rather than spelled out.

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=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description adds useful context beyond annotations: it discloses the markdown output, the token limit (≤3200 tokens for long), the return of model and token usage, the grounding scope on the computed natal chart, and the heavy cost. It does not describe authentication, failure handling, or credit-charging rules, so a 4 is appropriate.

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

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

The description is front-loaded with the tool's purpose and output format, followed by inputs, returns, grounding scope, and cost/group metadata. It is mostly efficient, though listing input options briefly duplicates schema enums; the cost warning and token cap justify their space. No major restructuring is needed.

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

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

Given the complexity (AI narrative generation with nested chart input, 6 parameters, output schema present), the description covers the essential invocation concerns: purpose, output format, key input controls, cost, token cap, and grounding scope. The output schema handles return-value details, so the description need not explain them. The main gap is the unmentioned fields and precision parameters, but the schema covers them.

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 50%, so the description must compensate but only partially does so. It names and explains chart, language (21 codes), tone (warm/professional/concise), and length (short/medium/long; ≤3200 tokens), adding useful meaning such as the token cap and language count. However, it omits the fields and precision parameters entirely, and the chart parameter's rich nested schema is not augmented 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 a specific verb and resource: 'Long-form natal-chart narrative (markdown).' It clearly distinguishes this tool from sibling AI narratives (monthly, synastry, transit, year ahead) and from non-AI natal report tools by naming the resource as a natal-chart narrative. An agent can identify the tool's purpose without opening the schema.

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

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

The description provides clear context for use: it is an AI Reports tool costing 250 credits (Tier 5), marked as heavy, and instructs the agent to confirm with the user before invoking. It does not explicitly list when to choose this over other AI narrative siblings or when not to use it, but the cost caution and purpose give sufficient usage context for an agent to proceed carefully.

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

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

Annotations already declare the safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false), so the bar is lower. The description adds a genuinely useful trait the annotations lack: the 250-credit Tier 5 billing cost and the explicit instruction to confirm with the user before invoking, which materially affects invocation behavior.

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

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

Two front-loaded sentences followed by structured metadata tags (group, cost, warning). No padding; the purpose appears first and the heavy-cost caveat is placed for emphasis. Slight redundancy in listing inputs the schema already enumerates.

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 format needn't be described, and rich nested chart schema plus annotations carry specification weight. However, for a complex, expensive, nested-input generation tool the description omits any usage context, prerequisites, or output character, leaving it adequate but thin.

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

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

At 57% schema coverage, the description should compensate but instead only names five inputs (chart1, chart2, language, tone, length) without explaining any of them. It omits the two nuanced params -- 'fields' and 'precision' (compact mode) -- and adds no meaning beyond the schema, whose enum and nested descriptions already document tone/length/language. The input listing is essentially a restatement.

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: 'Long-form relationship narrative grounded in cross-chart aspects,' which clearly identifies this as a synastry/compatibility report. It does not, however, differentiate this AI-narrative tool from sibling report tools like astroway_reports_synastry or astroway_reports_ai_natal_narrative, so the agent must infer the distinction.

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 guidance is the cost warning 'confirm with user before invoking,' which addresses authorization rather than tool selection. It never says when to pick this over the sibling synastry/love report tools or what preconditions apply, leaving the agent to infer usage.

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

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

Annotations already declare the safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false). The description adds real value beyond them: the 250-credit Tier 5 cost, the 'confirm with user' caution, and the orb <=1° grounding rule. It does not explain side effects or why readOnly is false for what reads as a read operation, so it stays mid-range.

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

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

Front-loaded with the core purpose, then a compact input/return summary and bracketed metadata tags. Every sentence is short and purposeful, though the inaccurate input list is wasted text rather than too much text.

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

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

An output schema exists, so return values need not be spelled out, and the aspect-orb detail is a nice touch. But with 8 params at 63% coverage and a stated input set that mismatches the schema, the definition is not fully complete for correct invocation.

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

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

The description's input list ('chart + transitDate, transitTime/tzOffset, language, tone, length') does not correspond to the schema, which actually exposes date, time, fields, ayanamsa, ayanamsaId, timezone, timezoneOffset, precision. Naming parameters that do not exist is misleading rather than additive, despite 63% schema coverage doing 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 ('Snapshot transit interpretation') scoped to a single date, which implicitly separates it from the monthly/year-ahead/reports_transit_yearly siblings. The scope ('single date') is clear, but it never names an alternative sibling explicitly, keeping it below a 5.

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

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

The '[Cost: 250 credits (Tier 5)] Heavy — confirm with user before invoking' line is genuine usage guidance about cost/prudence. However, it gives no when-to-use vs when-not guidance against the many other AI narrative siblings (natal, monthly, synastry, year-ahead), so routing is left 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 declare readOnlyHint=false, destructiveHint=false and openWorldHint=true but say nothing about cost. The description adds the Tier 5 / 250-credit price and an explicit instruction to confirm with the user first, which is real behavioral context an agent needs before invoking. It does not disclose latency or that the output is long-running, but the cost disclosure is the material one.

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 plus a group/cost tag block, front-loaded with what the tool produces before the input list. The 'Inputs:' enumeration is slightly over-compressed because it presents an incomplete parameter list as if it were complete, but there is no filler.

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

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

For a complex, nested-chart, non-readonly generation tool this covers the essentials: what is produced, the key inputs and defaults, and the cost/confirmation requirement. With an output schema present it need not describe return values, though the compact-mode params and the relationship to sibling report tools remain unexplained.

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

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

Schema description coverage is only 43%, and the description compensates well for the important gaps: it states that 'year' defaults to the next year (the schema has no default for it) and that 'length=long' is what produces a full annual report. It omits the compact-mode parameters (fields, precision) and says nothing about tone or language semantics, so coverage is partial but the highest-value parameters are clarified.

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 (long-form annual report) and describes the synthesis: natal context plus the year's major outer-planet transits clustered by month. That is enough to distinguish it from astroway_reports_ai_monthly_narrative, but the nearby sibling astroway_reports_transit_yearly and the other *_narrative AI reports are never named, so the agent must infer the boundary.

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

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

It gives operational guidance ('confirm with user before invoking' for a 250-credit call) and a parameter-level hint ('use long for full annual report'), which is genuinely useful. However, it never states when to choose this over astroway_reports_ai_monthly_narrative or astroway_reports_transit_yearly, so usage is implied rather than specified.

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 (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely non-redundant context: a 5,000-credit Tier 7 cost, the warning that it consumes ~50% of a free monthly budget, the required user confirmation, and a 'not financial advice' disclaimer. It stops short of describing output delivery (PDF vs HTML link) or any timeouts/rate limits.

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

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

Two short sentences plus a bracketed cost block, front-loaded with the purpose. Every element carries information; no padding or restatement of the title.

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 purpose plus cost are covered. However, the description never states the output medium (PDF/HTML), how the generated report is delivered, or that the `language` and `whitelabel` inputs shape the artifact — meaningful gaps for a premium report-generation 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?

The description mentions no parameters at all. With 60% schema description coverage across 5 parameters, the schema is doing all the work (chart, fields, precision, language, whitelabel) and the description adds nothing to disambiguate required vs optional inputs or the compact-mode fields/precision interaction.

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

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

The description names a specific resource and analytic lens ('Founding-chart analysis (mundane astrology)') and enumerates what the report covers (Sun/purpose, MC/reputation, Jupiter/growth, Saturn/structure). It distinguishes itself from a generic natal report by the 'founding chart' framing, though it never explicitly contrasts itself with the closest siblings (astroway_reports_money, astroway_reports_career, astroway_reports_natal).

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 instruction is 'Confirm with user before invoking', which is a cost prerequisite rather than selection guidance. There is no statement of when a business/founding-chart report is the right choice versus astroway_reports_money, astroway_reports_career or astroway_reports_natal.

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

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

Annotations declare openWorldHint=true, destructiveHint=false and idempotentHint=false, so the safety profile is partly covered. The description adds genuinely useful behavior the annotations lack: the 5,000-credit Tier 7 cost, that it consumes ~50% of a free monthly budget, and a confirm-before-invoking rule. It does not describe the returned artifact, but the output schema covers 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?

Two compact blocks: the content scope first, then the cost/confirmation warning. Every fragment earns its place, and the highest-stakes fact (credits and budget share) is isolated where a reader cannot miss it.

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

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

With an output schema present, the description needn't explain return values, and the cost caveat plus content scope give an agent enough to decide and call safely. Only the usage distinction from the other report siblings is unstated, which is a minor gap for a 5-parameter generator.

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%, and the description contributes nothing about chart, fields, language, precision, or whitelabel. The chart, fields, and precision properties are well documented in-schema, but language (enum) and whitelabel (large nested object) carry little or no description, and the tool text does not compensate.

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 report type and enumerates its astrological content (MC, 10th-house cusp, Saturn, Mars, Sun aspects), so an agent knows exactly what the artifact covers. It contrasts implicitly with the generic 'natal' sibling by prefixing 'Career-themed', though it never names a sibling explicitly.

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

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

It gives two usage signals: 'Self-knowledge tool, not directive' and 'Confirm with user before invoking' tied to the premium cost. That establishes a precondition, but it never says when to pick this over astroway_reports_natal, astroway_reports_money, or astroway_reports_business, leaving the choice among near-identical report siblings 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 only say this is a non-read-only, non-idempotent, open-world call. The description adds material behavioral context the annotations lack: the exact credit cost, its share of the free monthly budget, and the requirement to confirm before invoking. It omits the PDF-vs-HTML output distinction implied by the title, which is a notable gap.

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 report's identity and content in two sentences, then the cost warning. Efficient and well ordered, though the 'includes full natal data and a disclaimer' clause is closer to filler than actionable detail.

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

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

An output schema exists, so return values need not be described, and the cost/confirmation guidance is a real addition. But for a five-parameter premium report tool, the absence of any input guidance and the missing PDF/HTML output clarification leave the definition incomplete for confident invocation.

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

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

Schema description coverage is only 60%, so the description is expected to compensate, yet it mentions none of the five parameters (chart, fields, language, precision, whitelabel). Everything an agent learns about inputs comes from the schema, and the description adds zero parameter meaning.

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

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

States a specific output — a parenting-oriented natal report — and enumerates its content (Moon, Mercury, Venus, Mars, full natal data, disclaimer). The 'child'/'parenting-oriented' framing implicitly distinguishes it from the sibling astroway_reports_natal, though it never explicitly says to prefer this one for a child's 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?

The premium cost block gives a genuine usage instruction (5,000 credits, ~50% of the free monthly budget, confirm with the user first), which is useful operational guidance. However, there is no statement of when to choose this over astroway_reports_natal or other report siblings, so selection guidance remains implied.

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 disclose the safety profile (readOnlyHint=false, non-idempotent, openWorldHint=true), so the bar is lower. The description adds value with the cost warning (5,000 credits, ~50% of free monthly budget, confirm first) and the format-suffix behavior, but says nothing about what the output is returned as (URL? binary?) or auth requirements, and the visible text is cut off mid-explanation.

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 clause, which is good. However the prose is verbose and appears truncated, suggesting it runs long without a clean structure or summary of the key call-shape decisions. It is not padded with pure tautology, but it could be tighter.

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

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

An output schema exists, so return-value explanation is not required. The description covers the document's content intent and its relationship to the vedic gemstones endpoint, plus cost. But with 7 parameters, 43% schema coverage, and a truncated description, an agent is left without guidance on several inputs and on how the produced PDF/HTML is delivered.

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 43%, so the description would ideally compensate for the undocumented parameters. It only adds the `?format=html` toggle beyond the schema; the rich nested `chart` object, `school`, `language`, `precision`, `whitelabel` and `wearingFrom` receive no extra narrative. The (truncated) remainder may have covered more, but on the evidence shown the description adds marginal parameter value.

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

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

The description gives a specific verb+resource: producing a 'ratna prescription' (gemstone report) as a multi-page A4 PDF by default or live HTML via `?format=html`. That is concrete enough to distinguish it from generic report siblings like astroway_reports_vedic_kundli, though it never explicitly contrasts itself with the closest siblings. The text is truncated mid-sentence, so full purpose is not verifiable.

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

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

It states the report shares astrology with `POST /vedic/gemstones` and adds document-only content, which implies when this is preferable (you want a formatted document, not a data table). It does not name an explicit alternative tool in the sibling set or say when NOT to use it. The credit warning ('confirm with user before invoking') is present but is cost guidance rather than usage routing.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds the credit cost ('10 credits (Tier 1)'), which is useful behavioral context, but it does not address determinism/seed reuse, whether generation is idempotent, or whether a second call re-charges credits.

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 dense and front-loaded: the dispatcher scope and the enum of types come first, then the conditional-required rules. The trailing ellipsis ('seed …') indicates it is cut off, so it is not maximally efficient, but there is little filler.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Against 13 parameters at 38% coverage, though, the description only partially compensates, and being truncated it leaves the caller without the full picture of how the 12 modes differ in required inputs.

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 38%, so the description carries extra burden. It does add real value by explaining the conditional requiredness the schema cannot express (chart for most types, chart1+chart2 for synastry), but the text is truncated mid-sentence and leaves the remaining parameter interactions (seed, whitelabel, fields/precision compact mode) unaddressed.

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

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

The description states a specific verb and resource ('Single endpoint over the 12 type-specific renderers') and enumerates the 12 report_type values, so an agent immediately understands this is the unified dispatcher. It distinguishes itself conceptually from the type-specific siblings ('over the 12 type-specific renderers') but never names them or contrasts call patterns 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?

It gives substantive conditional guidance on inputs ('Required fields vary by type: chart for most, chart1+chart2 for synastry, seed …'), which is genuine when-to-use value. However, it offers no explicit guidance on when to call this dispatcher versus the individual astroway_reports_natal / _synastry / _business tools in the sibling list, which is the central routing decision for this tool.

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

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

Discloses non-obvious behavior well beyond the annotations: PDFs are purged after 24h, stale entries come back with expired: true and a dead URL, and limit defaults to 10 with a 1-50 range. However, it claims 'Free to call' while the same block says cost is not in the public credit manifest, and it never explains why annotations mark this list as readOnlyHint=false — an ambiguity an agent would want resolved.

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

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

Front-loads purpose, then usage, then lifecycle behavior, then cost, in three dense sentences with no filler. The appended [Group]/[Cost] tags add some clutter and the internal free-vs-cost tension slightly muddies the close.

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 list endpoint with an output schema, the description covers what an agent needs: scope, expiry semantics, pagination default and cost posture. The remaining holes are the unexplained readOnlyHint=false and the fact that the advertised limit parameter is not actually accepted by 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 100%, so the two declared parameters (fields, precision) are already documented and the description adds nothing about them. It does add limit semantics (1-50, default 10), but that parameter is absent from the input schema, so the extra detail creates a mismatch rather than compensating for a gap.

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

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

States a specific verb (List) and resource (the calling key's recently generated PDF reports) and enumerates the returned fields. It is clearly distinguishable from the many sibling astroway_reports_* tools, which generate reports rather than list past exports.

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 two concrete usage contexts: re-fetching a report link inside its 24h validity window and surfacing recent exports in a dashboard. It does not name an alternative tool or state when not to use it, so it falls short of explicit routing 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 declare openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is largely covered structurally. The description adds non-derivable behavioral context that the schema cannot express: the 5,000-credit Tier 7 cost and its share of the free monthly budget, plus an explicit confirmation requirement. It does not restate the idempotency or external-side-effect hints.

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 report's contents, then a compact cost/warning block. Every element earns its place, though sentence one is a dense comma-list that reads more like an inventory 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?

An output schema exists, so return-value description is not required, and the content list tells the agent what the report will say. It omits how the artifact is delivered, and the title advertises 'PDF or HTML' while the description says only 'Bodygraph PDF', leaving the output format ambiguous.

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

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

Schema description coverage is only 60%, and the description contributes nothing about any of the five parameters — nothing on chart/birth data, language, fields, precision, or whitelabel branding. The richly documented 'chart' object in the schema carries the load, but fields, precision, language and whitelabel remain unexplained in both places.

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 enumerates exactly what the Human Design report contains (Type, Strategy, Authority, Profile, Definition, Not-Self theme, Incarnation Cross, 9 centers, activated channels), which makes the tool's output unmistakable. The verb comes from the title ('Generate ... Report') rather than the description, and it does not explicitly position itself against sibling report tools, but 'Human Design' is a unique domain no sibling covers.

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

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

It gives a real usage gate — 'Premium — ~50% of free monthly budget. Confirm with user before invoking' — which is genuinely actionable. However, it offers no guidance on when to choose this over the many other report siblings (natal, stellaforge, generate) or what prerequisites the chart data must satisfy.

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 non-read-only, open-world, non-idempotent, non-destructive, so the description adds real value beyond them: the Tier 7 cost (5,000 credits, ~50% of a free monthly budget), a premium user-confirmation warning, and the computation convention (Lahiri ayanamsa, sign-from-Lagna house numbering). Missing is any note on delivery format or latency, hence not a 5.

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

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

Front-loads what the report contains, then appends group and cost metadata as bracketed lines that are easy to scan. Two tight paragraphs with no filler; only minor trimming possible.

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?

Output schema exists, so return values need not be described, and the description covers the report domain, computation convention, and the costly-invocation caveat that an agent most needs. For a generation tool of this complexity, nothing essential 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 60%, so the schema already documents chart, fields, precision, language and whitelabel in detail. The description's only parameter-relevant content is the Lahiri sidereal default, which the schema states anyway. It neither compensates for the uncovered portion nor adds new parameter meaning, 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?

States a specific verb+resource (Lal Kitab report) and enumerates the report's contents: Teva graha placements with Pakka-ghar match, Kismat & Prosperity scores, Rins, and Upayas. That is enough to tell it apart from generic siblings like reports_natal. It never names an adjacent sibling (e.g. reports_vedic_kundli) to sharpen the boundary, 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?

Usage is implied by the domain (use this when a Lal Kitab report is wanted) and reinforced by the explicit cost instruction to confirm with the user before invoking. However, it gives no guidance on when to prefer this over reports_vedic_kundli or reports_natal, which is the real selection decision an agent faces.

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 only declare readOnly=false, idempotent=false, openWorld=true and destructive=false; the description adds substantial context beyond them — a 5,000-credit cost (Tier 7), the share of a free monthly budget it consumes, and a mandatory user-confirmation step. It also sets expectations with a 'not a prophecy' disclaimer. It stops short of describing the returned artifact.

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

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

Two short blocks, front-loaded with what the report is and then the cost/confirmation warning. Waste-free, though the bracketed metadata lines are slightly stack-like rather than prose.

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

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

Output schema exists, so return structure needn't be explained, but the title promises 'PDF or HTML' and the description never says which output form is produced or how it is selected — a notable omission given no visible format parameter. The credit cost and confirmation requirement are well covered; the input/output contract is 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?

The description says nothing about any of the 5 parameters, including the required nested 'chart' object. With schema description coverage at only 60%, the description is expected to compensate for the undocumented parameters (fields, language, precision, whitelabel) and does not.

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

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

States a specific verb+resource ('Romantic-relationship natal report') and names the exact astrological bodies it interprets, so the agent knows the report's content. It does not contrast itself with the closest sibling (astroway_reports_synastry, which covers two-person relationship analysis), leaving that distinction 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 cost block gives real pre-invocation guidance ('Premium — ~50% of free monthly budget. Confirm with user before invoking'), which is actionable. However, there is no when-to-use / when-not-to-use guidance relative to sibling reports such as synastry, natal, or career, which is what an agent most needs to route correctly.

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 reveal it is not read-only, not idempotent, and open-world, but the description adds the crucial operational fact the annotations do not: this costs 5,000 credits (Tier 7), roughly half a free monthly budget, and should be user-confirmed. That is exactly the cost/budget context annotations cannot express. It stops short of saying how the artifact is delivered or that the call is billed on generation.

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?

Compact and front-loaded: the astrological content comes first, then the cost/confirmation block where an agent will actually look for it. The first sentence is tersely nominal ('Financial natal: 2nd house...'), but nothing is padding.

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

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

An output schema exists, so return-value explanation is not required, and the annotations plus the cost warning cover the behavioral essentials. The remaining gap is that neither description nor annotations state what the tool produces or returns (a generated PDF/HTML report), which the title carries 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?

Five parameters at 60% schema coverage, and the schema itself is unusually verbose about chart, fields, and precision. The description contributes nothing to parameter meaning — chart, language, precision, and whitelabel are unexplained — but with this much schema-side detail the mechanical baseline of 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?

Together with the title, the description makes clear this is a financial/money natal report, spelled out as 2nd house (earned income), 8th house (shared resources), Jupiter and Saturn. That content scope distinguishes it well from siblings like astroway_reports_business or astroway_reports_career. It never states the verb or that the deliverable is a PDF/HTML, so it leans on the title for the action.

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

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

Usage is implied by the financial scope, and there is an explicit invocation directive — confirm with the user before invoking. However, no alternative is named (e.g., when to prefer business or career reports over this one), and there is no 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 declare a non-readonly, non-destructive, non-idempotent, open-world operation, and the description adds real context beyond that: the report is A4, output is PDF/HTML, each day is scored by sunrise Panchang factors, and ranked days include Abhijit Muhurat plus scoring rationale. It stops short of stating pagination or repeat-invocation cost 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?

Front-loaded with the deliverable, then methodology in one dense sentence; the cost warning is clearly appended. Some engine detail (Panchang limbs, author names) is heavier than an agent strictly needs, and the trailing activity list is cut off mid-sentence.

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

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

An output schema exists, so return values need not be explained, and the description covers purpose, methodology and cost adequately. But for a premium 13-parameter tool it leaves the whitelabel/branding and result-limiting parameters entirely to the schema, so an agent must open the schema to invoke confidently.

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

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

Schema description coverage is only 31% across 13 parameters, so the description is expected to compensate, but it only restates `activity` (already enumerated in the schema) and alludes to the search window. topN, ayanamsa, timezoneOffset, precision, fields and the whole whitelabel object are left to the schema alone.

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

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

Specific verb ('Render') plus resource ('standard A4 report of the most auspicious dates') and a clear scope (activity over a search window). It distinguishes itself from other report siblings by naming the muhurta subject and the shared /vedic/muhurat/* engine, though it does not explicitly contrast with the other report generators.

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

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

Usage is implied by the 'Reports' group and the premium-cost warning ('Confirm with user before invoking'), which is genuinely useful gating advice. However there is no explicit when-to-use/when-not guidance and no named alternative (e.g. the raw muhurat endpoint or reports_generate).

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 non-read-only, non-idempotent, open-world; the description adds genuinely new behavior: PDF URLs expire after 24h via an auto-cleanup cron, branding overrides are applied when whitelabel is set, and the call is expensive (5,000 credits, ~50% of a free monthly budget) so user confirmation is required. Cost and output-lifetime disclosure is strong; the sentence explaining HTML mode is cut off mid-word.

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?

Dense, front-loaded and mostly waste-free: format and content come first, then branding, language and URL lifetime. It loses a point for a truncated trailing clause and for the language claim that conflicts with the schema, so not every sentence earns its place.

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

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

With an output schema present the description needn't describe return values, and the 24h URL note is a useful addition. But it is truncated, mismatches the language enum, and says nothing about failure/refund behavior for a 5,000-credit premium call, leaving an agent short of what it needs to invoke this confidently.

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

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

Schema description coverage is only 38%, so the description must compensate; it clarifies the format switch and whitelabel behavior but is silent on tone, length, enrich, fields and precision. Worse, it claims languages are 'uk (default) or en' while the schema enum lists 21 languages, which could steer an agent away from valid values. The nested `chart` object is richly self-documented in-schema, which partially offsets the gap.

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

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

Opens with a specific verb+resource ('Render a Western tropical natal chart') and enumerates exactly what the artifact contains (Big Three, planets table with houses/retrograde, 12 cusps, major aspects). Western tropical vs. sidereal implicitly separates it from astroway_reports_vedic_kundli, 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?

Gives option-level guidance (PDF default, `?format=html` for live HTML, `whitelabel: true` for branding, language default) plus a premium-cost warning to confirm with the user first. However it never states when to choose this report over the many narrative siblings (astroway_reports_ai_natal_narrative, astroway_reports_generate), leaving the selection decision 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 the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), so the bar is lower. The description still adds meaningful context beyond them: the 5,000-credit Tier 7 cost, the ~50% budget impact, and an explicit instruction to confirm with the user before invoking, plus the default 300 km line radius. It is silent on whether the output is cached or regenerated, which keeps it from a 5.

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

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

Dense but front-loaded: format/scope first, then per-place contents, then cost. Every clause carries information. It is docked slightly because the text trails off mid-sentence ('a…'), leaving an unfinished clause rather than a clean close.

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 restated, and the description helpfully covers report contents and cost. But for an 8-parameter premium tool with 38% schema coverage, the omission of language, categories, whitelabel, precision, and fields leaves real gaps an agent must guess at.

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 must carry the load, and it largely does not. It hints at the locations cap ('up to five places') and the 300 km line radius (relating to orbKm), but never names or explains orbKm, categories, language, fields, precision, or whitelabel. The '?format=html' instruction does not even correspond to a schema parameter, which risks confusing an agent about how format is actually selected.

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 operation on a concrete resource: comparing up to five places against one birth chart to produce a relocation report in PDF or HTML. The enumerated contents (relocated ascendant/midheaven, planets changing house, astrocartography lines within 300 km) are unmistakably relocation/astrocartography material, so an agent can tell this apart from the natal, synastry, or transit report siblings without opening the schema.

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

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

Provides the format-selection rule (PDF by default, add `?format=html`) and a strong invocation caveat (premium cost, confirm with the user first), which is real usage guidance. However it never says when this report is preferable to the neighbouring report tools, so alternative-routing is left 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 cover the safety profile (readOnly false, destructive false, openWorld true, idempotent false), so the bar is lower, and the description still adds materially: it discloses the deterministic non-AI rendering behavior and a concrete cost of 5,000 credits (~50% of a free monthly budget) requiring user confirmation. It does not say what is required for the call to succeed (e.g. a valid chart object) or how the artifact is delivered.

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

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

Front-loaded with the concrete deliverable and its visual contents, with no filler sentences. It loses a point because the style enumeration is cut off mid-word in the third option, leaving the structure visibly incomplete.

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 cost/tier is disclosed. But the title promises 'PDF or HTML' while neither the description nor the schema exposes any format selector, and the third style value is truncated — so an agent cannot fully determine the call's output mode from the description.

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 50%, so the schema carries most parameter meaning, including the detailed chart/timezone/houseSystem notes. The description adds value only for `style`, enumerating editorial (light) and celestial (dark + gold) and starting a third ('cl…', presumably classic) that is truncated. `fields`, `precision`, `language` and `whitelabel` 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 specific verb and resource ('Render a data-rich, print-ready natal chart poster') and enumerates the visual contents (wheel, Sun/Moon/Rising trio, placements table, balance bars, aspects), so the output is unambiguous. It differentiates itself implicitly from the narrative report siblings by being a deterministic chart render with '0 AI'. However it never names a sibling or explains how it differs from astroway_reports_natal or astroway_reports_generate.

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

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

Usage is implied by the content list and the cost banner ('Confirm with user before invoking'), which is genuine invocation guidance. But there is no explicit when-to-use framing, no exclusion rules, and no pointer to the alternative report tools an agent should pick instead for a written interpretation.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description goes beyond them with cost (5,000 credits, Tier 7), a budget proportion warning, and an explicit confirmation requirement -- meaningful operational context. It does not resolve the title's 'PDF or HTML' ambiguity or state whether output is a link, upload, or inline bytes.

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 payload sentence is dense but front-loaded and every clause names real content in the report. The cost block is a separate bracketed line, which keeps the primary statement readable. No filler sentences.

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

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

An output schema exists, so return values need not be explained, and the description usefully previews report contents plus the premium cost gate. What is missing is only the PDF-vs-HTML selection question implied by the title and any routing against the narrative sibling; for a paid report renderer the description is otherwise complete enough to invoke.

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%, in the middle band, and the schema itself carries very rich per-field documentation (timezone, houseSystem, city-as-label-only). The description contributes no parameter meaning at all -- chart1/chart2, language, whitelabel, precision and fields go unmentioned. 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?

States a specific verb (Render) and resource (relationship synastry PDF) and enumerates the document's contents: Big Three, cross-chart aspect table, element/modality balance. It never names the closest sibling, astroway_reports_ai_synastry_narrative, so an agent cannot tell from the text alone which synastry output to choose.

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 cost block gives one precondition ('Confirm with user before invoking'), which is real invocation guidance, but there is no when-to-use / when-not guidance and no routing to alternatives such as the AI narrative or astroway_reports_generate. Usage is implied by the premium warning rather than explained.

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 mark it non-read-only and open-world, and the description adds genuinely useful behavior beyond them: the deterministic mulberry32 RNG tied to `seed`, the daily-seed fallback when omitted, and the effect of `allowReversed`. It does not mention the 100-credit cost, but determinism disclosure is exactly the kind of context an agent benefits from 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?

Front-loaded with the action and default, then parameter behavior. The ten-item spread list is long but justified because `spread` is a plain string in the schema with no enum, so this is the only place the valid values appear. The trailing text is truncated, slightly hurting readability.

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 core generation parameters are covered. However, several configurable inputs (language, whitelabel theming, fields/precision compact mode) are neither in the description nor documented in the schema, leaving meaningful gaps for a tool with 8 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 25% across 8 parameters, so the description must compensate. It explains `spread` (with the full valid list, since the schema types it as a bare string), `seed`, and `allowReversed`, but leaves `language`, `whitelabel`, `fields`, `precision`, and `name` entirely undocumented. Partial compensation only.

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 ('Render') and resource ('tarot reading PDF') and immediately characterizes the default output (three-card Past/Present/Future from Rider-Waite-Smith). Tarot is unambiguous against all report siblings, which cover natal, synastry, vedic, etc.

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

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

It explains how to use the tool (spread options, seed for reproducibility, omit for daily seed, allowReversed toggle) but never says when to choose this over the other report generators or what prerequisites exist. Usage is implied by parameter behavior rather than stated as 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 mark it non-read-only and non-destructive, and the description adds behavior the annotations do not cover: the 5,000-credit Tier 7 charge (~50% of a free monthly budget) and the requirement to confirm with the user first. It does not mention rate limits, auth needs, or render latency, so it is strong but not exhaustive.

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

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

Two front-loaded sentences carry the purpose and computational scope, followed by compact structured tags for group and cost. No sentence is filler; the cost warning is placed where it will be seen before invocation.

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

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

Output schema exists so return values need no explanation, and the description covers the report content, cost, and confirmation requirement for a 6-parameter tool. The only visible gap is the title's mention of 'PDF or HTML' versus the description's PDF-only wording, leaving the output-format choice ambiguous.

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 compensates on just one parameter — it explains the `year` default (next calendar year) and defines the report's computational scope. The other parameters (fields, precision, language, whitelabel, chart) get no added meaning beyond the schema, leaving real gaps at this coverage level.

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

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

States a specific verb (Render) and resource (year-ahead transit calendar PDF), then goes further to define the exact content: major aspects of Mars–Pluto to natal positions at a 0.5° orb. This clearly distinguishes it from narrative-report siblings like astroway_reports_ai_year_ahead_narrative, which produce prose rather than a month-grouped calendar.

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 concrete usage context: defaults to next calendar year when `year` is omitted, and explicitly instructs the agent to confirm with the user before invoking because of the 5,000-credit cost. It does not name an alternative tool or state when-not-to-use, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description adds substantial context beyond that: it is Group Reports, costs 5,000 credits (Tier 7, ~50% of the free monthly budget), and requires user confirmation. Credit cost and budget impact are genuinely valuable and not derivable from annotations, though it doesn't clarify whether each invocation consumes credits again (non-idempotent).

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

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

The content list is front-loaded and dense with concrete deliverables, followed by clearly tagged [Group] and [Cost] lines. Every element earns its place with no filler, though the trailing confirmation note is appended without much structural integration.

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 details are rightly omitted, and the description adequately conveys what the generated report contains plus its credit cost. The main gap is that the 'PDF or HTML' output choice from the title is never explained or tied to a parameter, leaving the delivery format ambiguous.

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 60% schema description coverage, the schema does most of the work, and the description adds only the Lahiri default (mapping to the ayanamsa parameter). It gives no guidance on fields, precision, language, or whitelabel behavior. This is the baseline 'schema carries it' case, with only marginal added value.

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

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

The description names a specific resource and its scope: 'Sidereal Vedic chart (Lahiri ayanamsa)' with Lagna, nakshatra/pada, planet positions, and a 9-period Vimshottari Mahadasha tree. This is far more specific than a tautology and implicitly distinguishes it from tropical/natal siblings by emphasizing 'Sidereal Vedic'. However, it never explicitly names the sibling it differs from (e.g. reports_natal), so an agent must infer the routing.

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 guidance is the cost guardrail: 'Confirm with user before invoking' for a Tier 7 tool. That is useful but concerns approval, not selection. There is no statement of when to choose a Vedic Kundli over astroway_reports_natal, human_design, or the other report siblings, leaving usage to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds two things the annotations do not: a first-access seeding side effect and a concrete cost (10 credits, Tier 1), both of which materially affect an agent's decision to call it.

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

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

Two tight sentences with the purpose front-loaded and the side effect immediately after; the bracketed group/cost tags are compact metadata rather than prose. No wasted sentences, though the tags sit slightly awkwardly in the description body.

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 annotations carry the safety profile. The seeding behavior and cost are disclosed, leaving only the absence of routing guidance against sibling white-label tools as a gap.

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

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

Schema description coverage is 100% and both parameters (fields, precision) are fully documented in the schema, so the baseline is 3. The description says nothing about compact mode, dotted paths, or precision rounding, 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 and resource — 'Read the authenticated user's branding overrides' — and enumerates the covered fields (logo, palette, font, footer, domain), which lets an agent distinguish it from narrower siblings like astroway_whitelabel_logo or astroway_whitelabel_domain_verify. It never explicitly names an alternative, 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 statement of when to call this versus whitelabel_preview, whitelabel_logo, or whitelabel_domain_verify, and no prerequisites or exclusions. The 'On first access, defaults are seeded' line is a behavioral note, not usage guidance.

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

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

The description says it 'Persists the result,' which is a state-changing side effect, while the annotations declare readOnlyHint=true (no environment modification). That is a direct contradiction between description and structured metadata, warranting the score-1 rule. (The A-record hint is useful, but the conflict dominates.)

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 short, front-loaded sentences: the check, the persistence, then the fallback behavior, followed by group/cost tags. Efficient and easy to scan, with 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 cost/group are given. However, the definition omits any explicit when-to-use guidance and its persistence claim conflicts with the declared read-only behavior, leaving the agent's safety model ambiguous.

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% — the two generic compact-mode parameters (fields, precision) are fully documented in the schema. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource — check whether the configured custom_domain resolves to api.astroway.info via CNAME — which is precise and unambiguous. It doesn't explicitly contrast with siblings such as astroway_whitelabel_config or astroway_whitelabel_preview, so it stops short of full sibling differentiation.

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

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

Usage is only implied: an agent can infer this runs after a custom domain is configured, but the description never says when to call it, when not to, or how it relates to whitelabel_config/preview. The A-record fallback note describes output behavior, not when to choose this tool.

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

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

The description explicitly says the upload 'replaces any prior logo and deletes the old file from storage' — a write/destructive side effect — while the annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. This is a direct contradiction between the stated behavior and the structured safety profile.

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

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

Two tight sentences with the format constraint front-loaded, plus brief group/cost metadata. Nothing is padded, though the bracketed metadata lines add little for an invoking agent.

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

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

An output schema exists so return values need not be explained, and the description covers format, size, and side effects. However, it omits auth/permission requirements and error behavior (invalid image, oversized payload), and its side-effect disclosure conflicts with the annotations instead of clarifying them.

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

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

Schema coverage is 67% and the description fills the main gap: it spells out the base64 data-URL shape and the 512 KB size ceiling for data_url, which the schema only encodes as a regex. The unrelated 'fields'/'precision' compact-mode params are documented in the schema, so nothing critical is missing.

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: uploading a white-label logo, with the accepted data-URL format enumerated. It does not explicitly contrast itself with siblings like astroway_whitelabel_config or astroway_whitelabel_preview, but the resource is unambiguous enough to route correctly.

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

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

It never says when to use this tool versus the other white-label siblings, nor what prerequisites (e.g. branding config existing) or exclusions apply. The format constraints are payload requirements, not usage guidance, so the agent must infer the context on its own.

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

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

Beyond the safety annotations (readOnly/idempotent/non-destructive), the description discloses the exact cost (5,000 credits, Tier 7), that it consumes ~50% of the free monthly budget, and that the agent should confirm with the user before invoking. It also states the fallback behavior when `chart` is omitted. This is unusually 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?

Front-loaded purpose, then the key usage rule, then grouped cost metadata. Every sentence earns its place with no redundancy; the metadata tags ([Group], [Cost]) are compact and scannable.

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. The description adds purpose, the pivotal parameter rule, and cost/confirmation guidance — everything an agent needs to invoke it correctly.

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

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

The `chart` parameter has no schema description (anyOf with empty object), and the description is the only place its behavior is explained. `fields` and `precision` carry schema descriptions and `language` is a self-explanatory enum, so with 50% coverage the description fully compensates for the one ambiguous 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 states a specific verb and resource: 'Render a sample natal report PDF using the authenticated user's white-label configuration,' with scope implied by 'sample' and the white-label branding. This cleanly separates it from the general report generators (astroway_reports_natal, etc.), though it never explicitly names a sibling it is not.

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

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

It gives concrete when-to-use context for the `chart` parameter ('Pass `chart` to use your own birth data; omit to use the bundled Kyiv 1990 sample') and a confirmation prerequisite for the premium cost. It stops short of naming an alternative tool or stating when not to use this one.

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