AstroWay Tarot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered. The description adds behavior those annotations cannot express: the cost (100 credits, Tier 4), the structure of what the AI returns, and multilingual output. It does not explain the non-idempotent nature of repeated AI readings, but the added cost and output detail is real 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?

The narrative is front-loaded in one dense sentence covering purpose, input flexibility and output shape, with the metadata block (group, endpoint, required, cost) compactly appended. No sentence is wasted; the only minor cost is that parameter detail is omitted rather than trimmed.

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

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

An output schema exists, so return values needn't be described, and cost plus required input are stated. However, for an 8-parameter tool at 38% schema coverage, an agent still lacks guidance on spread, question, art, fields and precision, making the definition only minimally 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 only 38%, so the description must carry more of the parameter burden. It covers the two most important ones implicitly (cards accepts slugs or a draw array; language = 'Multi-language'), but art, deck, spread, question, fields and precision get no mention at all, leaving six parameters explained only by terse or absent schema text.

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

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

Specific verb+resource with a clear scope: an AI reading of a spread across three deck systems, with the output shape (per-position reading, synthesis, one piece of advice) spelled out. It doesn't explicitly distinguish itself from the deck-specific siblings astroway_tarot_marseille_interpret or astroway_tarot_rider_waite_interpret, which is the remaining gap.

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?

'Takes card slugs or the drawn array of any draw response' implies the intended workflow (call this after a draw tool) but never states that directly, and gives no guidance on when to prefer the deck-specific interpret siblings over this cross-deck tool. Usage is inferable rather than 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 readOnly/idempotent/non-destructive/closed-world, so the safety bar is low; the description still adds real value by clarifying that endpoints are NOT invoked and that results are cached with a 5-minute TTL. It also discloses the return shape (total + per-endpoint breakdown with tier annotations), which is meaningful since no output schema exists.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful operational context absent from annotations: cost (10 credits, Tier 1) and the endpoint. It does not explain whether a seed makes the draw reproducible or how 'adapted' differs from the classic Celtic Cross layout.

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 one-line purpose, followed by compact bracketed metadata for group, endpoint, and cost. No filler sentences, though the alias line is procedural rather than user-facing.

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/endpoint are covered. But for a draw tool with 0 required params and half its schema undocumented, the description never explains the question parameter or what 'adapted' Celtic Cross positions are produced, leaving an agent without enough to invoke it confidently.

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

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

Schema coverage is only 50%, and the description supplies no parameter meaning at all. Three parameters (seed, question, allowReversed) are undocumented in both places despite question being the semantically central input for a divination draw; the description should have compensated for the gap 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?

Names the specific resource — an adapted Celtic Cross spread drawn with Lenormand cards — which separates it from the Marseille and Rider-Waite Celtic Cross siblings and locates it in the Lenormand family. No explicit verb ('draw'), but the action is unambiguous from the name and title pairing.

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 no guidance on when to choose this spread over the many other Lenormand draws (three-card, line-of-five, grand tableau, 9-card square) or over the Marseille/RWS Celtic Cross variants. The alias note tells the agent the canonical tool exists but not which to prefer or why.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare this a safe, idempotent read, so the description only needs to add context. It does add useful catalog detail (artist, year, source, preview image, card back, and coverage gaps for cards with no picture), which tells the agent the shape/quality of the data. It does not disclose pagination, result count, or whether all decks or just a filtered set are returned.

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

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

The core sentence is front-loaded and dense with payload facts, followed by compact Group/Endpoint/Cost metadata. It is slightly overpacked in one run-on sentence, but no content 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?

With an output schema present, return values need not be explained, and annotations cover the safety profile; the description supplies the catalog scope, the art-set linkage to other routes, and the cost/endpoint metadata. The only untold element is whether the deck list is paginated or complete, which is a minor gap for a catalog endpoint.

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% for both parameters (fields, precision), each fully documented in the schema itself. The description adds nothing about them, so the schema carries the full burden and the baseline 3 applies.

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

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

The description gives a specific verb-less but clear resource statement: it enumerates decks, their spreads, and public-domain card art sets, and names the envelope fields (id, artist, year, source, preview, card back, missing-art fallback). That is far more specific than a tautology, though it never says 'list' explicitly and does not name a sibling tool it competes with (e.g. the per-deck spread endpoints).

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

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

The phrase 'the public-domain card art sets you can pick with `art` on any tarot route' implies the use case: discovering the art values that the other tarot routes accept. But there is no explicit when-to-use vs when-not, and no pointer to an alternative such as the Rider-Waite or Marseille spread listings.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new behavioural context: the endpoint (GET /v1/tarot/lenormand/cards), the group, and a concrete cost of 10 credits (Tier 1) that the agent needs for budget decisions. No pagination or caching behaviour is disclosed, but the credit cost is a meaningful addition 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?

Four short lines: resource first, then bracketed metadata for group, endpoint and cost. Nothing is wasted and the key noun is front-loaded. It is arguably too terse rather than too long, 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?

For a simple read-only catalogue endpoint with an output schema, full parameter coverage and annotations covering safety, most of what an agent needs is present. The missing piece is routing context — nothing says this is the static deck reference versus the sibling cards_slug lookup or the draw_* spread tools, which is the main risk in a toolset this large.

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

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

Schema description coverage is 100% and both parameters (fields, precision) are fully documented in the schema as generic 'compact mode' modifiers. The description adds nothing about them, which is acceptable given the schema does the work, so the baseline of 3 applies.

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

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

The description names a specific resource ('36-card Lenormand oracle deck'), which tells the agent this returns the full 36-card catalogue rather than a spread. However it is a bare noun phrase with no verb, and it does not distinguish itself from the obvious sibling astroway_tarot_lenormand_cards_slug (single-card lookup) or astroway_tarot_lenormand_draw_* (spread draws). Purpose is inferable but not 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?

No when-to-use guidance and no mention of alternatives, despite ~30 Lenormand-related siblings in the toolset. The agent has to guess that this is a static reference lookup rather than a divination action. Nothing here is misleading, but nothing routes the caller either.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, repeatable read operation. The description adds no behavioral context beyond what annotations provide — no mention of rate limits, caching, or response characteristics. However, given the annotations carry the safety profile and an output schema exists, the bar is lower and this minimal restatement is acceptable.

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

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

Front-loaded and efficient: the first line states purpose clearly. The bracketed metadata lines (Group, Endpoint, Required, Cost) are structured and scannable. Slight redundancy with the required-slug tag being stated twice (in the description and the schema), but overall tight and well-organized.

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 read-only annotations covering safety, an output schema present, and 100% schema description coverage, the core call is sufficiently specified. However, the cost note ('see your plan — endpoint not in the public credit manifest') is vague and potentially a blocker for an agent assessing whether to call it, and there is no differentiation from the sibling 'cards' list endpoint. Just adequate.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters (slug format, fields compact mode with dotted paths, precision rounding). The description adds nothing beyond the required-parameter tag, which is already in the schema's 'required' array. Baseline 3 is appropriate when the schema does all 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 and resource: 'Single Lenormand card lookup by slug.' This is clear purpose. However, it does not distinctly differentiate from the highly similar sibling tool astroway_tarot_lenormand_cards (list all cards) or astroway_tarot_marseille_cards_slug / astroway_tarot_rider_waite_cards_slug which follow the same pattern. A brief note on the distinction (lookup one by slug vs browse all) would push this higher.

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 'by slug' phrasing implies this is a lookup operation and the required slug requirement is noted, giving minimal usage context. But there is no explicit when-to-use guidance, no mention of when to use the list endpoint instead, and no prerequisites stated. Adequate but with clear gaps.

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

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, and closed-world, so the safety profile is covered. The description adds the date-seed determinism (same date yields the same draw) and the 10-credit cost, which is useful for call planning, but says nothing about the response contents or what happens when date is omitted.

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

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

One front-loaded sentence carries the meaning, with the group/endpoint/cost metadata stacked below in a scannable format. Nothing is padded, though the bracket lines are boilerplate rather than descriptive content.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. The remaining gap is behavioral: with all four parameters optional, the description never states whether omitting date defaults to today, which is the key question for a daily-draw tool.

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

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

Schema coverage is 75%: art, fields, and precision are documented in the schema, while date carries only a pattern and no prose description. The phrase 'based on date seed' partially fills that gap by implying date drives the draw, but it does not state the default when date is omitted, which matters for a zero-required-parameter tool.

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

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

States a specific verb and resource ('Daily three-card draw') and adds the distinguishing mechanism ('based on date seed'), which separates it from a generic three-card spread. It does not, however, explicitly contrast with the nearby sibling astroway_tarot_lenormand_draw_three_card, so the agent must infer the difference from the name alone.

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

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

There is no explicit when-to-use guidance and no named alternative. 'Daily' implies a recurring date-based reading, but nothing states when to prefer this over astroway_tarot_lenormand_draw_three_card, astroway_tarot_marseille_daily, or the other daily-draw siblings. The bracket lines give an endpoint and cost, not usage guidance.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's main added value is the 10-credit cost and endpoint. It says nothing about determinism from `seed`, reversal behavior, or response shape beyond the grid layout.

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

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

Very tight: the spread semantics are front-loaded in one sentence, followed by compact group/endpoint/cost metadata. Nothing is padded, though the three bracketed metadata lines could be trimmed to just the cost signal.

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 output schema exists, so return structure needn't be explained, and the spread geometry is given. But with six parameters and half of them undocumented, plus no routing guidance among the many Lenormand draw siblings, the definition is only minimally sufficient for correct invocation.

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

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

Schema description coverage is only 50% (art, fields, precision documented; seed, question, allowReversed not), and the description adds no parameter meaning at all – no explanation of how `question` is used, what `seed` does for reproducibility, or whether `allowReversed` is meaningful for Lenormand, where reversals are traditionally atypical yet default to true.

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 defines the spread concretely – a three-by-three grid with row and column semantics – which, combined with the name 'draw_9_card_square', makes the operation and its output structure unambiguous. It does not, however, distinguish this spread from sibling draws like grand_tableau, line_of_five, or three_card.

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 mention of alternative Lenormand spreads, despite many siblings (draw_relationship, draw_three_card, draw_grand_tableau). The grid dimensions hint at a situational overview across time and life domains, but that is left for the agent to infer.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description's one genuine addition is the cost (10 credits, Tier 1) and the endpoint, which is useful operational context; it says nothing about how the draw behaves, how the seed parameter affects determinism, or how allowReversed influences results.

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

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

Extremely tight and front-loaded: the first line carries the meaning and the bracketed metadata lines are scannable. Nothing is wasted, though the brevity is partly under-specification rather than disciplined editing.

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

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

An output schema exists, so return values need not be explained, but for a six-parameter tool with half its parameters undocumented and a near-duplicate sibling, the description is too thin to let an agent call it confidently. It omits the one thing that would matter most here: how this differs from astroway_lnd_celtic_cross_lenormand and when each should be chosen.

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 meaning whatsoever. Three of six parameters (seed, question, allowReversed) are documented neither in the schema nor in the description, so an agent gets no help on whether a question is required for meaningful output or how the seed interacts with a 'random' draw.

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

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

Names a specific spread (Adapted Celtic Cross) and a specific deck (Lenormand), which distinguishes it from the three-card, line-of-five, and grand-tableau Lenormand draws and from the Marseille/Rider-Waite Celtic Cross variants. However, it does not distinguish itself from the near-identical sibling astroway_lnd_celtic_cross_lenormand, leaving an ambiguity the agent must resolve elsewhere.

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 at all: no statement of what question types suit a Celtic Cross versus a smaller spread, no mention of prerequisites, and no routing to a companion interpretation tool (e.g. astroway_ai_interpret_tarot) or to the sibling celtic-cross variants. The metadata block only supplies group, endpoint, and cost.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds the layout completeness and cost (10 credits), but says nothing about side effects, permissions, or output behavior beyond what annotations cover. It adds some billing context but not rich behavioral detail.

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 content sentences plus bracketed endpoint/cost metadata. Front-loaded and free of redundancy, though the endpoint line is arguably not needed by an agent. Efficient overall.

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 explained. Annotations cover safety. However, for a tool sitting among many Lenormand spread variants, the description omits usage guidance and parameter clarification, leaving the agent to infer when this spread applies.

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% (art, fields, precision documented; seed, question, allowReversed not). The description mentions no parameters and does not compensate for the undocumented ones. An agent must rely on the schema alone for half the inputs.

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

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

The description states the tool produces a full 36-card layout with every card and house used, which is a specific resource and scope. It implicitly distinguishes from partial Lenormand spreads, but does not name any sibling to make the distinction explicit.

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

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

No when-to-use guidance, no alternatives, no prerequisites. The agent gets no help deciding between this and the many other Lenormand draw tools (three-card, nine-card square, relationship, etc.).

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

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description carries a lower burden. It usefully adds the billing fact ('10 credits (Tier 1)') and the endpoint, which an agent needs for cost-awareness. It does not otherwise disclose return format or randomization behavior, but that is largely covered by annotations and the output schema.

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

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

Extremely compact and front-loaded: the operative phrase leads, followed by structured bracket tags for group, endpoint, and cost. Nothing is padded. The only weakness is that the brevity comes at the expense of usage guidance, not that any sentence is wasted.

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

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

An output schema exists, so return values need not be explained, but the description still leaves meaningful gaps: no guidance on selecting this spread, no explanation of the question/seed/reversed parameters, and no note on determinism despite idempotentHint. For a 6-parameter divination tool surrounded by near-identical siblings, 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 50%, leaving seed, question, and allowReversed without documented meanings, and the description adds nothing to compensate. Most notably it never mentions the `question` parameter, which is the semantic core of a divination draw, nor the `allowReversed` default. It relies entirely on the schema that is already half-undocumented.

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 shape: 'Five-card linear story spread,' which lets an agent distinguish it from the sibling Lenormand spreads (three_card, 9_card_square, grand_tableau, celtic_cross_lenormand). The name/title reinforce the same verb+resource. It stops short of explicit sibling differentiation in prose, but the spread type is specific enough to route on.

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

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

No when-to-use or when-not-to-use guidance is given. It does not say when a five-card linear reading is preferable to the three-card, relationship, or 9-card square spreads that sit right next to it in the catalog. The only routing signal is the spread geometry implied by the title.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context in the cost (10 credits, Tier 1) and the concrete endpoint, but says nothing about latency, deck requirements, or how randomness/seed behaves.

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

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

Extremely short and front-loaded — the spread definition leads, with group/endpoint/cost as bracketed metadata. Nothing is padded, though the metadata lines are boilerplate rather than tool-specific explanation.

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

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

An output schema exists, so return values need not be described, and annotations handle safety. What remains missing is routing guidance among the many Lenormand/tarot draws and any note on the optional question parameter, leaving the definition adequate but thin for a spread-selecting tool.

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

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

Schema coverage is only 50% across 6 parameters, and the description contributes nothing about art, seed, fields, question, precision or allowReversed. With half the parameters undocumented and no descriptive compensation, the agent has no extra semantic grounding.

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+scope: a 7-card Lenormand draw for relationship dynamics. The spread size and topic distinguish it from Lenormand siblings such as the three-card, nine-card square, line of five and grand tableau, though it never names them explicitly.

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

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

There is no guidance on when to choose this spread over the other Lenormand draws (three_card, line_of_five, 9_card_square, grand_tableau, celtic_cross_lenormand) or over the Rider-Waite relationship draw. The agent must infer selection purely from spread size.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful non-annotation context: the billing cost (10 credits, Tier 1) and the HTTP endpoint. It says nothing about randomness/determinism of a seeded draw, which is the main behavioral question for this tool.

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

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

Extremely short and front-loaded, with the spread's meaning in the first clause and metadata in bracketed groups. Nothing is redundant, though the brevity is under-specification rather than true efficiency.

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

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

An output schema exists, so return values needn't be described, and the cost/endpoint metadata is a plus. But usage routing against ~10 similar spread tools and any parameter semantics are missing, leaving the definition adequate but thin for a paid, seeded draw operation.

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%, yet the description explains no parameters at all. seed, question, and allowReversed are undocumented in both the schema and the description, so the description fails to compensate for the coverage gap.

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

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

States the resource (Lenormand three-card line) and the three positional slots (Subject / Situation / Outcome), which lets an agent distinguish it from line_of_five, 9_card_square, and grand_tableau siblings. It does not restate the draw verb explicitly, but the name and spread layout make the purpose unambiguous.

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

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

There is no guidance on when to choose this spread over the many sibling Lenormand spreads (relationship, daily, line of five, Celtic Cross) or what inputs a caller should supply. The cost line is the only selection-relevant context offered.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds genuinely new operational context — the endpoint and a 10-credit Tier 1 cost — which is useful for budget-aware planning, but it says nothing about caching, latency, or whether the result is static reference data.

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

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

One front-loaded sentence states the payload, followed by three bracketed metadata lines (group, endpoint, cost) that each carry distinct, non-redundant information. Nothing is padded or repeated.

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

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

An output schema exists, so return values needn't be explained, and the tool takes no required parameters. What remains missing is minor: no hint that it is a parameterless static reference call or how its output relates to a tableau draw, but nothing needed to invoke it correctly is absent.

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, including examples and semantics, so the baseline is 3. The description adds nothing about the compact-mode parameters, which is acceptable when the schema already carries them.

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 ('the 36 fixed houses') and its domain role ('for Grand Tableau interpretation'), so an agent knows exactly what comes back. It does not, however, distinguish itself from siblings like astroway_tarot_lenormand_draw_grand_tableau or astroway_lnd_celtic_cross_lenormand, leaving the agent to infer the boundary itself.

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

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

Mentioning 'Grand Tableau interpretation' implies the usage context, but there is no explicit when-to-use, no prerequisite, and no named alternative. An agent can guess this is a static reference lookup that complements a tableau draw, but the routing decision 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 already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful operational context — the POST endpoint and the 10-credit Tier 1 cost — which an agent cannot get from annotations or schema, but it says nothing about the returned payload or whether the cost is incurred per call.

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

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

Extremely tight — one descriptive sentence plus a compact structured metadata block with endpoint, required param and cost front-loaded. Nothing is padded, though the metadata block repeats facts (group, endpoint) that add little selection value.

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

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

An output schema exists, so return values need not be explained, and the read-only/cost facts are present. However, for a tool sitting among dozens of overlapping tarot computations, the absence of any deck/method selection guidance or alternative routing leaves the definition only minimally complete.

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

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

Schema coverage is 75%, with art, fields and precision each documented in the schema itself; the description only restates that date is required, matching the schema's required list. It adds no format or interpretation detail (e.g., how a date maps to a card) beyond structured data, 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 resource (a birth card) and method (Greer) plus the deck (Marseille), which usefully separates it from the sibling astroway_tarot_rider_waite_birth_card. It does not explain what a 'birth card' actually is or how it is derived, so a wholly uninformed agent still has a small gap, but the verb+resource is identifiable.

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 context and no routing to alternatives such as astroway_tarot_marseille_year_card or the Rider-Waite birth card. The only usage cue is the bare 'Required: date' line, which is schema information rather than guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the endpoint and a cost figure (10 credits, Tier 1), which is genuinely useful operational context, but it says nothing about response shape or pagination beyond what the output schema gives.

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 and tight: the distinguishing deck conventions come first, followed by compact bracketed metadata. No wasted prose, though the domain trivia is arguably more than a selection decision requires.

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 parameterless, read-only catalog call with an output schema, the definition is minimally sufficient. It still leaves unresolved how this full-deck tool relates to the slug, majors, and other Marseille siblings, which is the main thing an agent would need to choose correctly.

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

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

Schema coverage is 100% and both parameters (fields, precision) are fully documented in the schema, so the baseline of 3 applies. The description adds nothing about the compact-mode projection or precision handling, though its note about pip-minor interpretation is relevant to the returned data.

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

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

The description asserts domain facts about the deck (78 cards, Justice=8/Strength=11, pip minors by number+suit) but never states the tool's action — that it returns the full Marseille card catalog. The name and title carry the verb, so an agent can guess, but the description itself is a content blurb rather than a statement of purpose.

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

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

No when-to-use guidance and no mention of alternatives, despite many near-neighbours (astroway_tarot_marseille_cards_slug, astroway_tarot_marseille_majors, astroway_tarot_decks, astroway_tarot_rider_waite_cards). Nothing tells the agent when to pick this full-deck listing over a single-card lookup.

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, idempotent, not destructive, closed-world), so the bar is lower. The description earns credit for adding the concrete endpoint and an honest cost disclosure ('not in the public credit manifest'), which flags real billing uncertainty that annotations do not cover. It stops short of 5 because pagination/error behavior on an unknown slug is unstated.

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

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

One-line purpose sentence is front-loaded, followed by a bracketed metadata block that is scannable and zero-waste. Slightly telegraphic rather than fully prose, but 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 annotations fully cover the read-only/idempotent profile. Endpoint, group and cost are supplied. The only real omission is how to discover a valid slug, which is a minor gap for a lookup-by-key tool in a rich structured context.

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

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

Schema description coverage is 100% and all three parameters (slug, fields, precision) are documented in the schema itself, including the compact-mode syntax and precision bounds. The description adds nothing beyond repeating 'Required: slug', so the baseline 3 is correct.

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

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

States a specific verb+resource+scope: 'Single Marseille card lookup by slug'. The word 'Single' implicitly contrasts with the sibling list tool astroway_tarot_marseille_cards, so an agent can distinguish it, but the sibling is never named explicitly, so it stops short of a clean 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 gives no when-to-use guidance and never points at alternatives. It never says that astroway_tarot_marseille_cards is how you obtain a valid slug, nor when the majors/spreads siblings would be preferable. 'Required: slug' restates schema metadata rather than giving usage direction.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is low. The description adds the endpoint and cost (10 credits) context, which is useful, but says nothing about determinism of the draw, how question/seed affect the result, or reversal 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?

Extremely terse and front-loaded, with metadata block (group, endpoint, cost) clearly separated. Nothing is wasted, though at three words of actual purpose the brevity tips into under-specification.

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

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

For a 6-parameter, zero-required tool with an output schema, the description is far too thin. An agent cannot tell how to supply question vs seed, when to change allowReversed, or how this relates to draw_single / rider_waite_clarify. Only the cost/endpoint metadata is genuinely additive.

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 50%; art, fields, and precision are documented in-schema, while question, seed, and allowReversed have no schema description. The tool description compensates for none of these gaps - it does not explain what question is for, how seed makes draws reproducible, or what allowReversed does.

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 'Single clarifying card' states the resource (a card) and its role (clarifying) but is telegraphic and does not distinguish it from the many sibling draw tools (astroway_tarot_marseille_draw_single, astroway_tarot_rider_waite_clarify). An agent gets the gist but not why this differs from a single-card draw.

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

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

No when-to-use guidance, no prerequisites, no alternatives named. It never explains that a clarifying card is drawn to resolve ambiguity in a prior reading, nor differentiates it from draw_single or the Rider-Waite clarify sibling.

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 contributes genuine extra context: a cost of 10 credits (Tier 1) and the POST endpoint, which the annotations do not express. It stops short of explaining how the date seed affects output (determinism, whether omitting date means today), which is the behavior an agent would most want to know.

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

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

Very short and front-loaded: the core purpose is in the first clause, and the metadata lines (group, endpoint, cost) are compact and each carries real information. No filler or repetition, though the brevity edges toward under-specification rather than elegance.

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. What remains missing for a 4-optional-param tool is defaulting behavior (is date optional because it defaults to today?) and any routing guidance among the many tarot daily/draw siblings. Adequate but with clear gaps.

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

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

Schema coverage is 75%, so most parameters are already documented in the schema. The phrase 'based on date seed' hints that the date parameter determines the card deterministically, but the description says nothing about the art, fields, or precision parameters and does not clarify date defaults. Baseline 3 is appropriate given the schema does the heavy lifting.

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

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

The description names a specific resource (the Marseille daily card) and adds the mechanism (date seed), which lets an agent separate it from astroway_tarot_rider_waite_daily and astroway_tarot_lenormand_daily by deck. It is weaker on verb phrasing — there is no explicit 'returns/gets' action — and the core sentence closely mirrors the title 'Marseille: Daily Card', so it sits just below a fully self-contained purpose statement.

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

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

There is no when-to-use or when-not-to-use guidance. Nothing tells the agent how this differs in practice from astroway_tarot_marseille_draw_single or astroway_tarot_marseille_birth_card, nor whether it should be called once per day. 'Daily' implies a cadence, but that inference is left entirely to the caller.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds genuinely useful context that annotations do not carry: the cost (10 credits, Tier 1) and the exact endpoint. It does not disclose auth requirements, whether the seed makes draws reproducible, or what the spread yields, so it is helpful but not rich.

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

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

The purpose is front-loaded in the first line and the group/endpoint/cost tags are compact, non-redundant metadata. Nothing reads as filler. It is arguably too terse rather than bloated, but every line earns its place.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What remains missing is spread semantics (what the four positions mean) and any hint of how seed/question/allowReversed affect the draw — for a divination tool whose value is in the reading, that is a real gap, though the structured fields carry much of the load.

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% — three of six parameters (seed, question, allowReversed) have no schema description, and the description adds nothing about any parameter. Critical semantics like whether `seed` makes the draw deterministic or what `question` influences are left entirely undocumented in both places. With half the parameters undocumented and no compensating text, this falls below the 3 baseline.

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 action and resource: a 4-card career spread drawn from the Marseille deck, which separates it from the many other Marseille spread variants (love, spiritual, decision, celtic cross, single). The card count and topic together give an agent a clear picture of the outcome. It stops short of full sibling differentiation because it never contrasts itself with the Rider-Waite career draw or explains the spread layout, but the purpose is unambiguous.

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

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

There is no when-to-use guidance at all — no condition selecting this career spread over astroway_tarot_marseille_draw_three_card, draw_seven_card, or the Rider-Waite equivalent. The agent must infer from the name alone that this is for career questions. The meta tags give cost and endpoint but no usage direction.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world scope, so the safety profile is covered. The description contributes non-schema operational context (cost of 10 credits, Tier 1, POST endpoint, group), but says nothing about draw behavior itself, such as whether seeding makes the draw reproducible or how reversed cards are handled.

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 compact and front-loads the spread identity, with the endpoint/cost metadata in tagged lines that are easy to parse. There is no filler, though the brevity is partly under-specification rather than pure economy.

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

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

An output schema exists, so return-value documentation is unnecessary, and the description does convey spread, deck style, and cost. However, for a 6-parameter draw tool surrounded by dozens of near-synonymous tarot draws, it omits the usage routing and the purpose of question/seed/allowReversed, leaving real gaps.

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

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

Schema coverage is only 50% and the description contributes no parameter meaning at all. The undocumented parameters (seed, question, allowReversed) have no explanation anywhere, and the two schema descriptions that do exist (fields, precision) are recycled astrology text referencing planets.longitude and houses.cusp, which is actively confusing for a tarot draw tool. With low coverage the description is expected to compensate 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?

The description names a specific spread ("Adapted 10-card Celtic Cross") and deck style ("Marseille pip-style reading"), which lets an agent distinguish it from the RWS and Lenormand Celtic Cross siblings and from other Marseille spreads like draw_cross or draw_seven_card. The verb is only implied by the tool name rather than stated, so it stops short of the level of explicit sibling differentiation seen in the best definitions.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives among the many Marseille draw siblings (draw_cross, draw_seven_card, draw_three_card, draw_decision, draw_love, etc.). The agent must infer the choice purely from the spread name.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior. The description adds useful operational context the annotations don't: a 10-credit Tier 1 cost, the POST endpoint, and the ≤22 numerological reduction rule for the synthesis card. It still says nothing about how seed or allowReversed affect the draw, so it does not fully carry the burden.

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 layout description is front-loaded and the metadata tags are compact. The sentence is dense but every clause (positions, synthesis rule, cost, endpoint) earns its place.

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

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

An output schema exists, so return values needn't be explained, and annotations cover safety. What remains missing is the most decision-relevant content for this tool family: how it differs from the other Marseille draw spreads and what 'question' is for. Adequate but with clear gaps.

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

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

Schema description coverage is 50%, and the description contributes zero parameter information. Undocumented params like 'seed', 'question' and 'allowReversed' are left for the agent to infer with no help from the prose, which is below the minimum-viable 3.

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

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

States a specific verb and resource ('5-card cross' draw) and even enumerates the four positions plus the synthesis card, which is more than most draw tools offer. It doesn't explicitly distinguish itself from siblings like draw_celtic_cross or draw_seven_card beyond the spread name and tradition, 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?

No statement of when to choose this spread over the many sibling Marseille spreads (single, three-card, seven-card, celtic cross, love, career). The Jodorowsky/Costa attribution implies a tradition but gives no routing condition or exclusion.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely useful operational context — endpoint and a 10-credit Tier 1 cost — but says nothing about how the verdict is produced, whether the draw is deterministic given a seed, or what a 'verdict' contains.

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

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

Front-loaded with the one-line purpose, followed by compact bracketed metadata lines. Nothing is padded or redundant, though the group/endpoint/cost block is administrative rather than descriptive and could arguably be trimmed.

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 annotations carry the safety profile. However, for a 6-parameter tool with half its parameters undocumented and no usage routing among ~15 Marseille draw siblings, the definition is only minimally complete.

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

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

Schema description coverage is only 50% (art, fields, precision documented; seed, question, allowReversed not), and the description adds zero parameter meaning. It does not even mention that a `question` is expected, despite the tool being framed as a question-answering draw, so it fails to compensate for the coverage gap.

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

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

States a concrete verb+resource and outcome: a single-card draw that yields a yes/no answer with a verdict. This separates it from the bare astroway_tarot_marseille_draw_single, though it never names that sibling explicitly, so the differentiation is implicit rather than stated.

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

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

There is no when-to-use guidance, no mention of when a yes/no decision draw is preferable to draw_single, draw_cross, or the Rider-Waite equivalent, and no prerequisites. The agent must infer the use case entirely from the title and one-line summary.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context absent from annotations — the cost (10 credits, Tier 1) and the source/school of the spread (Jodorowsky/Costa). It says nothing, though, about how seed or allowReversed affect the reading.

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

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

The core sentence is front-loaded with the spread nature and structure, followed by compact metadata lines. Nothing is wasted, though the bracket block is structured plumbing rather than explanatory content.

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

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

The presence of an output schema means return values needn't be explained, and annotations cover the safety profile, so the description is not required to carry those. It is still incomplete on the input side: the undocumented 'question' and 'allowReversed' parameters are central to how a draw is performed and remain unexplained anywhere.

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% — art, fields, and precision are documented, but seed, question, and allowReversed have no schema description. The description adds no parameter meaning at all, not even for the central 'question' input that a divination draw would obviously need explained, so it fails to compensate for the coverage gap.

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

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

The description gives a specific spread concept (6-card Hero's Journey) and enumerates all positions (Hero / Objective / two Obstacles / Key / Resolution), so the agent knows exactly what it produces. It does not, however, explicitly distinguish itself from the many sibling draw_* spreads (celtic_cross, love, career, decision), leaving the differentiation implicit in the name.

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

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

The description contains no when-to-use guidance, no conditions, and no alternatives named. With roughly a dozen sibling spreads such as draw_celtic_cross, draw_cross, and draw_seven_card, the agent gets no help choosing this one over the others.

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, idempotentHint, non-destructive), so the bar is low, and the description adds a genuinely actionable trait not present in structured fields: a 10-credit Tier 1 cost. It also exposes the underlying endpoint. It does not, however, disclose whether the draw is random or seeded/deterministic.

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

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

Very tight and front-loaded: the spread definition leads, with group/endpoint/cost as clearly bracketed metadata. Nothing is wasted, though the bracketed scaffolding is boilerplate rather than tool-specific guidance.

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

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

An output schema exists, so return values need no explanation, and annotations carry the safety profile. What remains missing is behavioral context around the draw itself (determinism via seed, whether a question is expected, reversed-card handling) for a 6-parameter tool with half its schema undocumented.

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

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

Schema description coverage is only 50%: art, fields, and precision are documented in-schema while seed, question, and allowReversed are not. The description adds no parameter meaning at all, so it does not compensate for the undocumented third of the parameter surface — notably the 'question' field an agent would likely need to fill.

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

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

States a specific action (draw) with the resource (Marseille Tarot) and the spread identity ('5-card love and connection spread'), which separates it from sibling draws like draw_career, draw_celtic_cross, or draw_single. It stops short of explicitly contrasting itself with those siblings, but the topic+card-count combination is sufficient to disambiguate.

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 'love and connection' framing implies when the tool applies, but there is no explicit when-to-use statement and no named alternative (e.g., tarot_lenormand_draw_relationship, tarot_rider_waite_draw_love_triangle, or tarot_marseille_draw_cross). Usage is left to inference from the spread name.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description usefully adds the credit cost (10 credits, Tier 1) and the HTTP endpoint, but says nothing about what the spread returns, how allowReversed affects the draw, or how randomness interacts with the seed.

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

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

Extremely short and front-loaded with the defining fact (seven-card pyramid). The bracketed endpoint/cost metadata is boilerplate but contains a genuinely useful cost signal, so little is wasted despite the near total absence of substance.

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

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

There is an output schema, so return values need not be described, and annotations cover safety. However, for a fixed-layout divination tool the agent still lacks the position meanings of a 7-card pyramid, whether a question is required or optional for this spread, and how it differs from the more common three-card and celtic cross siblings.

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

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

Six parameters at ~50% schema description coverage; `art`, `fields`, and `precision` are documented in the schema, but `question`, `seed`, and `allowReversed` are undocumented anywhere. The description contributes no parameter meaning at all, so it fails to compensate for the coverage gap, particularly on seed reuse and reversal behavior.

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 spread variant ('7-card pyramid spread'), which distinguishes it from the sibling draw_single, draw_three_card, and draw_celtic_cross tools. It is a noun fragment with no verb and no mention of tarot/Marseille, but the variant name alone is enough to identify the resource.

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 indication of when to choose this spread over the many siblings (three-card, cross, celtic cross, love, career, decision). No prerequisites, no note on whether a `question` is expected for this particular spread.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the transport endpoint and a concrete cost (10 credits, Tier 1), which is genuinely useful billing context, but says nothing about whether the draw is randomized, whether the seed makes it reproducible, or how reversals are handled.

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 descriptive sentence is front-loaded and waste-free, but the bracketed group/endpoint/cost block is scaffolding shared across hundreds of sibling tools rather than information unique to this definition. Terse to the point of being under-specified.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, with six optional parameters and no required fields, the description leaves the agent guessing about what a caller should supply and when, which is a meaningful omission for a drawing 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 only 50%: `seed`, `question`, and `allowReversed` carry no schema documentation, and the description does not compensate for any of them. For a divination tool, the absence of any note on `question` or `allowReversed` (which defaults to true and changes the result set) is a real 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: a single-card draw from the Marseille deck. It is clear enough to distinguish from multi-card spreads like draw_three_card or draw_celtic_cross, but it never contrasts itself with near-neighbors such as marseille_daily, marseille_birth_card, or marseille_clarify, which may also produce single-card output.

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

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

There is no guidance on when to use a single-card draw rather than any other Marseille spread, no mention of prerequisites, and no named alternative. The bracketed endpoint and cost tags are metadata, not usage direction.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the credit cost (10 credits, Tier 1) and the endpoint, which is genuinely useful context. However, it says nothing about determinism via seed or what the draw returns, so it adds only moderate value over structured data.

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

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

It is front-loaded with the single substantive fact (the spread) and the bracketed metadata is compact and scannable. Every line carries information, though the group/endpoint/cost lines are boilerplate rather than description prose.

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

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

An output schema exists, so return values need not be explained, and cost plus endpoint are disclosed. Still, for a 6-parameter, zero-required draw tool in a crowded sibling family, the absence of routing guidance and parameter explanation leaves meaningful gaps.

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

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

Schema description coverage is only 50%: art, fields, and precision are documented in-schema, but seed, question, and allowReversed are not. The description explains none of these parameters, so it fails to compensate for the coverage gap; it neither clarifies the effect of allowReversed nor the determinism role of seed.

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 spread ('4-card spiritual development spread'), which is precisely what separates it from siblings like draw_love, draw_career, or draw_single. The verb is only implied via the tool name, and it does not explicitly route against those siblings, but the resource and scope are 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 or when-not-to-use guidance, despite a large family of sibling draw tools (draw_love, draw_career, draw_decision, draw_hero, draw_cross, etc.) where selection guidance would be most valuable. The spread label hints at the domain but leaves routing to inference by the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is fully covered. The description usefully adds the cost (10 credits, Tier 1) and HTTP endpoint, which are real context beyond the structured fields, but adds nothing about seeding behavior, reversals, or determinism.

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 one-line spread definition followed by compact metadata taglines; nothing is padded. The bracket tags are dense but functional rather than redundant prose.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. But the description leaves two of six parameters completely undefined and gives no usage context, which is thin for a 6-param, no-required-field 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 only 50%; seed, question, and allowReversed are undocumented in the schema, and the description contributes no parameter semantics at all. With 6 parameters and no required ones, the description should at least clarify what question and allowReversed do, but it does not.

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

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

States the specific spread and its positional meaning (Past/Present/Future) for a tarot draw. The group tag and name identify the Marseille deck, though the description body itself never restates 'Marseille' or the draw verb, leaving cross-deck distinction to the tool name.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. With sibling spreads like draw_single, draw_cross, draw_celtic_cross, draw_love, and the parallel rider_waite/lenormand three-card tools, an agent gets no help choosing among them.

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

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds genuinely useful non-structured info: the 10-credit Tier 1 cost and the POST endpoint. It does not disclose return shape, but an output schema exists for 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?

Front-loads the core action in one sentence, then packs metadata into bracketed tags with zero filler. Efficient and scannable, though the tags are more structural housekeeping than description content.

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

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

Output schema covers return values and annotations cover safety, so those gaps are fine. However, for a 5-param tool with only 1 required, the description supplies no usage context and no elaboration on the optional art/fields/precision params, leaving an agent to infer invocation intent from siblings alone.

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

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

Schema description coverage is 60%. The description clarifies the required 'cards' argument as 'card slugs' (the schema leaves cards undescribed), adding real value, but the other four params (art, fields, question, precision) receive no description-level elaboration beyond what the schema already says.

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 ('Resolve list of card slugs into meanings'), which clearly conveys the operation. Deck variant (Marseille) and the interpret-vs-draw distinction are implied by the title and group tags, but the description does not explicitly differentiate from siblings like tarot_marseille_cards_slug or tarot_rider_waite_interpret.

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 '[Required: cards]', which states a prerequisite but not when to use this tool versus the many draw_* siblings or the RWS interpret variant. No when-to-use context or exclusions are provided.

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