Tarot MCP Server by RoxyAPI

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent. It adds useful context about the data returned ('lightweight basic card data') and the deck structure, but does not disclose additional behavioral caveats (e.g., pagination or language fallback), which are already in the schema. The description adds some value 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?

The description is longer than typical but well-structured: it opens with the purpose, then details filters and closes with use cases and an alternative. Every sentence contributes information, though some length could be trimmed without losing value. It remains front-loaded and 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 7 optional parameters and no output schema, the description adequately explains the tool's scope, filter semantics, and complementary endpoints. It could specify what fields 'basic card data' includes, but the current level of detail is sufficient for an agent to decide when to invoke this tool and how to configure parameters.

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

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

While the schema covers all 7 parameters, the description enriches semantics significantly: it explains suit meanings (cups=emotions/relationships, wands=creativity/passion, etc.), arcana meanings, and number ranges (Ace=1 for new beginnings, 2-10 for progression, etc.). This goes far beyond the schema's field descriptions and helps agents select parameters correctly.

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 the verb 'Retrieve' and the resource 'Rider-Waite-Smith tarot deck of 78 cards', and distinguishes from sibling tools by noting that full interpretations are available via GET /cards/:id. The deck composition and filter options are explained, making 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?

The description provides explicit use cases ('Perfect for building tarot reference libraries, card databases, learning applications') and directs users to an alternative endpoint for full interpretations ('use GET /cards/:id for full upright and reversed interpretations'). This gives clear when-to-use guidance and distinguishes from 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 provide readOnlyHint=true and destructiveHint=false, and the description adds meaningful content expectations: 'complete upright meanings', 'reversed meanings', '400+ words each', and 'guidance across life domains'. It also reveals card-ID normalization behavior ('the-star' and 'star' both resolve), going beyond the annotation's safety profile.

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

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

The description is front-loaded and organized, but at ~180 words it includes verbose details like 'full interpretations (400+ words each for upright and reversed orientations)' and a marketing-style list of use cases ('divination apps, fortune-telling platforms...'). Several sentences could be trimmed without losing operational 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?

Given the absence of an output schema, the description supplies a robust mental model of the returned data: keywords, 400+ word upright/reversed interpretations, life-domain guidance, and Major/Minor Arcana semantics. It also covers ID format and aliasing, making the tool's expected behavior and content clear.

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% with detailed descriptions for id, lang, and compact, including normalization rules and examples. The description's id examples and kebab-case note are helpful but largely redundant with the schema, so it adds limited parameter-level value beyond the structured 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 opens with 'Retrieve comprehensive details for a specific tarot card' and immediately identifies the deck (Rider-Waite-Smith) and distinct content (upright/reversed meanings, keywords, life domains). This distinguishes it from sibling draw/spread creation tools and the plural get_tarot_cards.

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

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

It clearly states the tool is for detailed study and interpretation, and gives concrete use cases: 'essential for detailed tarot study, reading interpretations, divination apps, fortune-telling platforms, spiritual guidance tools...'. It does not explicitly exclude draw/spread alternatives, but the specification of a single card id makes the scope apparent.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses important behavioral traits: seeded randomness ensures "the same seed gets the same card on the same day," and the response includes "keywords, full meaning, and a daily message summary." It also notes that omitting the seed yields anonymous draws, adding useful context.

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

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

The description is a concise, well-structured paragraph that front-loads the main purpose and then efficiently explains the seeded randomness, seed usage, response contents, and appropriate use cases. Every sentence contributes information without redundancy or fluff.

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

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

Given the tool's simplicity (all optional parameters, no output schema), the description provides a complete overview: what it does, how seeding works, what the response contains, and ideal use cases. It could mention behavior with unsupported languages or the compact parameter, but those are already covered in the schema, so overall it is sufficiently 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?

The input schema already provides 100% coverage with thorough descriptions for all four parameters, including defaults and examples. The tool description adds some context about the seed's purpose (e.g., reproducing readings) but does not introduce significant parameter-level meaning beyond what the schema already contains.

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 the tool's purpose: "Receive a single tarot card for daily guidance and reflection." It uses a specific verb ('receive') and resource ('single tarot card'), and distinguishes itself from sibling spread tools by the 'daily' and 'single card' focus.

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

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

The description provides clear context for when to use the tool, stating it is "perfect for 'Card of the Day' features" and listing suitable use cases like "tarot apps, wellness platforms, morning ritual apps, and journaling tools." It also explains the seed option for reproducibility and the anonymous alternative, but does not explicitly name alternatives or state when not to use it.

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 indicate readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: seeded reproducibility ('same seed always returns identical cards in exact same order'), reversal behavior ('50% chance of reversal per card'), duplicate handling ('traditional deck draws each of 78 cards once, or oracle-style allows repeating same card'), and return content ('position number, reversal state, keywords, full meaning text, authentic imagery'). This goes well 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?

The description is front-loaded with the core purpose but is overly verbose, particularly the final sentence listing many use cases ('meditation apps, journaling prompts, divination tools...') and deck statistics ('22 Major Arcana spiritual lessons + 56 Minor Arcana practical guidance') that add little for an AI agent. While structured, it could be trimmed without losing essential information.

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

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

With no output schema, the description compensates by detailing exactly what each drawn card includes: 'position number, reversal state (boolean), keywords for quick interpretation, full meaning text (400+ words), authentic Rider-Waite imagery, and card metadata.' It also covers edge behaviors like drawing 78 cards ('returns the entire shuffled deck') and language fallback ('Languages without translations yet return English').

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%, so baseline is 3, but description adds meaningful guidance beyond schema: seed format ('user123-2025-12-27'), common count values ('1 for daily card, 3 for past-present-future'), and semantics of reversals/duplicates. This enriches parameter understanding.

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 the tool's function with a specific verb and resource: 'Draw 1-78 tarot cards from the complete Rider-Waite-Smith deck with seeded reproducibility'. It distinguishes itself from sibling tools by focusing on random draws with seed control, reversals, and duplicates, unlike specific spreads or card info tools.

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

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

The description provides clear contexts for use: 'Perfect for custom spread builders, random card generators, automated tarot reading platforms, daily card features...' and explains when to use seed ('essential for daily tarot features') and when to omit it ('Omit seed for true random draws each time'). However, it does not explicitly contrast with sibling spread tools or state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds context about the spread's content but does not disclose behavioral traits like return format, rate limits, or side effects beyond what annotations already convey. The bar is lower with annotations, and the description meets it minimally.

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 excessively long and repetitive, containing marketing language like 'Perfect for...' and 'Ideal for...' which duplicates the use cases already listed. Key information is front-loaded, but the bulk of the text is verbose and could be reduced by half without losing meaning.

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 description thoroughly explains the seven spread positions and target use cases, but does not describe the output JSON structure or mention absence of an output schema. Since no output schema exists, the description should provide some indication of what the response contains; listing positions partially covers this, but the verbosity and missing response format details leave 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 descriptions cover all four parameters (lang, seed, compact, question) with clear examples and semantics. The tool description adds no additional parameter information, so the baseline score of 3 is appropriate as 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 clearly states the tool performs a 7-card career tarot spread using a SWOT framework, with specific position meanings. It distinguishes from sibling tools by explicitly focusing on career and listing business-related aspects, making 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?

The description provides extensive contexts for when to use the tool, such as career transitions, job offer evaluation, and strategic planning. However, it does not explicitly name alternative tools or state when NOT to use this spread (e.g., for love readings), so it stops short of full exclusion guidance.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is already known. The description adds context about what the spread entails (10 positions, specific meanings, 'layered insight'), which helps understand the output. However, it does not disclose any technical behaviors beyond that, such as pagination, rate limits, or how the seed affects repeatability (the latter is only in schema). It does not contradict annotations.

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

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

The description is excessively long and filled with promotional language ('legendary', 'most comprehensive', 'professional tarot readers worldwide for over a century') that adds little actionable information. The core value—what the spread does and its positions—is buried amid marketing fluff. It could be cut by half without losing substance. This is not conciseness; it is verbose.

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

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

For a complex 10-card spread with no output schema, the description does a good job explaining the meaning of each position and the overall purpose. It also hints at the output structure ('Each card position provides layered insight'). It does not specify the exact JSON response shape, but given no output schema exists, the description carries that burden reasonably well. Some things like how to structure the question or what to do with the seed are left to the schema, but overall it is sufficiently complete for an agent to understand scope and output expectations.

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 all four parameters (lang, seed, compact, question) are already described in the schema. The description adds no additional parameter details—it doesn't even mention them. Since the schema fully covers parameter semantics, a baseline of 3 is appropriate; the description does not enhance understanding of parameters.

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

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

The description explicitly states it 'Perform[s] the legendary Celtic Cross spread' with a 10-card layout, and details each of the ten positions. It also distinguishes this from sibling tools by labeling it 'the most comprehensive and detailed tarot reading available', making its unique value proposition 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?

The description provides clear contexts for use: 'Perfect for life-changing decisions, complex relationship questions, career transitions, spiritual guidance, and deep self-discovery.' It implies it is for complex situations, and the 'most comprehensive' phrase contrasts with simpler sibling spreads, but it does not explicitly state when not to use it or name alternative tools. Thus it has clear context but no explicit exclusions or alternatives.

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

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

While annotations indicate readOnlyHint=true and destructiveHint=false, the description adds meaningful behavioral context: 'The API draws the exact number of cards you specify and maps them to your custom positions' and 'No pre-generated summary provided - you interpret the reading based on your framework.' This clarifies what the tool does and does not return, which is valuable beyond the safety hints.

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

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

The description is long (nine sentences) and contains redundant phrases like 'flexible endpoint,' 'unique spread layouts,' and 'custom' repeated. The list of target users (therapists, coaches, app developers...) and example themes (chakra, lunar, elements...) is extensive and could be trimmed without losing essential meaning. The structure is front-loaded with the core purpose, which is good, but the verbosity prevents a higher score.

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

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

Given the tool's moderate complexity, the description covers the essential aspects: purpose, input structure (positions), card drawing behavior, lack of summary, and maximum positions. It does not explicitly describe the return payload format, but since there is no output schema, a clearer statement of the response shape would strengthen completeness. The use cases are well covered, making it adequate for an agent to select and invoke the 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 100%, so baseline is 3. The description adds extra process-level meaning: 'Each position requires a name and interpretation - you define what each card position represents' and 'The API draws the exact number of cards you specify and maps them to your custom positions.' This goes beyond the schema's field descriptions by explaining the underlying behavior and the relationship between positions and drawn cards.

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 opens with a clear verb and resource: 'Build and perform your own custom tarot spread with personalized positions and interpretations (1-10 cards).' It explicitly distinguishes from traditional spreads by noting 'beyond traditional spreads' and 'any purpose,' making it unique among sibling tools that handle fixed spreads.

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

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

The description provides extensive context on when to use this tool: therapists, coaches, app developers, spiritual practitioners, and for specific themes like chakra or lunar phases. It implicitly contrasts with traditional spreads by saying 'beyond traditional spreads,' but does not explicitly say 'use this instead of X' or mention when not to use it. This is clear guidance but lacks explicit 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 and destructiveHint=false, and the description adds valuable behavioral context about the five positions (You, Partner, Relationship Dynamic, Challenge, Outcome) and the nature of insights provided. There is no contradiction, and the description enriches the annotation baseline.

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 thorough but verbose, with redundant phrasing and multiple paragraphs covering use cases and positions. While it is well-structured and front-loaded with the core action, it could be significantly trimmed without losing essential 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?

For a read-only tool with no output schema, the description is quite complete: it explains the tool's purpose, the five card positions, and a wide range of use cases, making it easy for an agent to invoke. The lack of return-value shape is a minor gap given the explanatory nature of the description.

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

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

The input schema already documents all four parameters (lang, seed, compact, question) with clear descriptions, achieving 100% coverage. The tool description does not add any parameter semantics beyond the schema, so it earns the baseline score of 3.

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

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

The description clearly states it performs a specialized 5-card relationship tarot spread analyzing romantic connections, making the love focus unambiguous. The title 'Love Spread (5 cards)' and the detailed description distinguish it from sibling spread tools such as career, celtic cross, and three-card spreads.

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

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

The description provides strong usage context by listing application domains (dating apps, relationship counseling, wellness apps) and specific use cases (compatibility, conflict resolution, breakup recovery, self-love). It does not explicitly name alternatives or state when not to use this tool, preventing a score of 5.

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

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

Annotations already declare the operation safe (readOnlyHint=true, destructiveHint=false). The description adds valuable behavioral context beyond that: it details the output structure ('drawn card with reversal state, keywords, full meaning, and position-specific interpretation'), mentions a 'summary connecting all three cards,' and explains the optional seed for reproducible results. No contradictions found.

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 four sentences, each earning its place: purpose, usage, output details, and seed note. It is front-loaded with the main function and structured logically. No fluff or repetition of schema fields, making it highly concise and readable.

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

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

Given no output schema, the description sufficiently covers the return value ('Each position includes a drawn card... Returns a summary connecting all three cards'). It also explains the seed for reproducibility, use cases, and the spread's beginner-friendly nature. The annotations handle safety, so the description completes the context needed for an agent to invoke this tool correctly and choose it over siblings.

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

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

Schema coverage is 100%, giving a baseline of 3. The description adds meaningful semantics for the seed parameter ('Optionally provide a seed for reproducible readings') and implies the question parameter's purpose ('exploring specific questions'). It does not cover lang or compact, but those are fully documented in the schema. Thus, the description enriches the parameter understanding without repeating schema details.

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 begins with a clear action verb 'Perform' and specifies the exact resource: 'classic three-card tarot spread revealing Past, Present, Future.' It defines each card position's meaning and states it is 'beginner-friendly,' which distinguishes it from sibling spread tools like career or Celtic Cross. The purpose is unambiguous and well differentiated.

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

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

The description provides clear context for when to use this spread: 'perfect for quick insights, daily guidance, or exploring specific questions' and calls it 'the most popular beginner-friendly spread.' It implies when to choose this over more complex sibling spreads but does not explicitly name alternatives or state when NOT to use it. A slightly stronger exclusion would push this to 5.

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

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

The description thoroughly explains behavioral nuances beyond the read-only annotation: how upright/reversed cards map to yes/no, that ambiguous cards always yield 'Maybe', and that Major Arcana gives stronger answers. It also discloses the optional seed parameter for reproducible results, adding valuable context.

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

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

The description is well-structured and front-loaded with the core action, but it is somewhat lengthy due to the detailed explanation of card logic and use cases. Each sentence earns its place, providing meaningful information without padding, though a bit more brevity could be achieved.

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 no output schema, the description explicitly states what is returned (answer, strength, drawn card details, and interpretation), covering the return values. It also explains the logic behind the reading, making the tool's behavior comprehensive for an agent.

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

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

The schema already covers all four parameters with detailed descriptions, so the baseline is 3. The description adds minimal extra semantics beyond the schema, only reiterating the seed's purpose and emphasizing question specificity, but not enriching parameter understanding significantly.

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 the tool's function: asking a specific question and receiving a yes/no/maybe answer based on a single tarot card draw. It distinguishes this from sibling tools by emphasizing the single-card yes/no format, and explicitly mentions the return of answer, strength, card details, and interpretation.

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

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

The description provides clear context on when to use this tool, listing ideal use cases such as decision-making apps, quick guidance tools, and fortune-telling chatbots. However, it does not explicitly mention alternatives or when not to use the tool, which keeps it from a perfect score.

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