Tarot MCP Server by RoxyAPI

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

Annotations already declare readOnlyHint and destructiveHint, and the description adds useful behavioral context by stating that only lightweight basic card data is returned and that full interpretations belong to a different endpoint. It does not describe the exact response shape, but the schema covers the parameters and annotations cover safety.

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 purpose, then filters, output nature, and the alternative endpoint. It is longer than strictly necessary, and the final marketing sentence about 'professional tarot readers worldwide' is not essential, but the structure is logical and most sentences earn their 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?

For a read-only catalog tool with 7 parameters and no output schema, the description covers what it returns, which filters are available, and when to use the sibling endpoint for full interpretations. It could be more explicit about the exact fields returned per card, but the schema and annotations cover most invocation details.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra semantic value, especially for the number parameter: Ace=1 for new beginnings, Page=11 for messages, Knight=12 for action, Queen=13 for mastery, and King=14 for authority. It also clarifies the meanings of arcana and suits beyond the schema.

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

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

The description opens with a specific verb and resource: 'Retrieve the complete Rider-Waite-Smith tarot deck of 78 cards.' It clearly differentiates from GET /cards/{id} by noting this endpoint returns lightweight basic data rather than full interpretations, and it lists the available filters.

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 explicitly tells an agent when to use this endpoint and when to switch: 'Use GET /cards/{id} for full upright and reversed interpretations with keywords.' It also frames intended use cases like reference libraries and card databases, which helps distinguish it from the post_tarot_* drawing and spread 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 mark this as readOnly and non-destructive. The description adds meaningful behavioral context by detailing what a caller will receive: upright and reversed meanings, keywords, 400+ word interpretations, and life-domain guidance. It does not fully describe response structure or error behavior, but the read-only annotation lowers 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 description is front-loaded with the core operation and then expands into detailed card categories and a broad list of use cases. While informative, it is longer than necessary and includes somewhat redundant material (for example, the leading-article behavior is also in 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 no output schema, the description compensates by explaining the return contents in detail: meanings, keywords, word counts, and life domains. It also covers ID format guidance. It does not address invalid-ID behavior or error cases, but for a read-only lookup this is reasonably 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 100% and the id parameter is already well-documented, but the description reinforces parameter semantics with concrete ID examples, kebab-case guidance, and the accepted leading article behavior. It adds value beyond the schema without being strictly necessary.

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 operation: retrieving comprehensive details for a specific tarot card from the Rider-Waite-Smith deck. It distinguishes the singular-card scope from collection or draw operations, though it does not explicitly name sibling tools or contrast itself with them.

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

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

The description gives clear context for when this tool is appropriate: detailed tarot study, reading interpretations, divination apps, and professional learning. It does not explicitly state when not to use it or which alternative to choose, but the singular-card purpose is clear enough to imply selection.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable behavioral context: it explains the seeded randomness mechanism ('the same seed gets the same card on the same day') and describes the return content ('keywords, full meaning, and a daily message summary'). This goes beyond annotations without contradicting them. It doesn't mention potential caveats like date validation or rate limits, but for a read-only tool this is acceptable.

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

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

The description is composed of three balanced sentences. It leads with the purpose, then explains the seeding behavior, and ends with use cases. It avoids redundancy and fluff. It is slightly longer than necessary but remains focused and information-dense, earning a strong score for structure.

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 stating what is returned ('card with keywords, full meaning, and a daily message summary'). It covers the main parameters indirectly (date, seed) and mentions language default via schema, but doesn't explicitly address the compact parameter (which schema covers). For a read-only tool with no required parameters, the description is sufficiently complete to guide correct invocation. It could have explicitly differentiated from sibling draw tools, but the 'single card' wording mitigates this.

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 provides descriptions for all four parameters (date, lang, seed, compact), covering their formats, defaults, and examples. The description reinforces the seed purpose ('userId, email hash, session token') but does not add meaning beyond what the schema already provides. Since schema coverage is 100%, the baseline of 3 is appropriate; the tool description adds no extra parameter semantics.

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

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

The description clearly states the tool's core function: 'Receive a single tarot card for daily guidance and reflection.' It specifies the verb (receive), the resource (single tarot card), and the context (daily). It also distinguishes from siblings by emphasizing 'single card' and 'Card of the Day,' which differentiates it from multi-card draws and spreads. The mention of seeded randomness further clarifies its unique deterministic behavior.

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 tool: it is 'perfect for Card of the Day features' and lists applicable use cases such as tarot apps, wellness platforms, and journaling tools. It explains the seed parameter for reproducible readings and the option to omit it for anonymous draws. However, it does not explicitly state when not to use it or name alternative sibling tools, so it misses the explicitness of the top-tier example.

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 mark the tool as read-only/non-destructive, and the description adds meaningful behavioral detail: deterministic same-seed ordering, 50% default reversal probability, traditional no-duplicate deck behavior, compact lossless shape, and drawing 78 returning the entire shuffled deck. No statements contradict the annotations.

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

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

The description is front-loaded with the core draw and seed behavior, but the latter portion is verbose and includes marketing-style lists such as 'perfect for custom spread builders' and 'authentic Rider-Waite imagery,' plus an arcana breakdown that adds little for an agent deciding how to invoke the tool. The useful behavioral content could be delivered in roughly half the 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?

For a six-parameter tool with no output schema, the description tells an agent exactly what each returned card contains—position, reversal state, keywords, 400+ word meaning, imagery, and metadata—and explains all major behavioral toggles (seed, reversals, duplicates, compact). It is complete enough to select parameters and interpret the response.

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 per-parameter descriptions for all six parameters. The prose adds value on top—seed format guidance, common count values (1 daily, 3 past-present-future, 5 relationship, 10 Celtic Cross), default reversal probability, and oracle-style duplicate semantics—so it earns more than the baseline 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 opens with a specific verb and resource: draw 1-78 tarot cards from the complete Rider-Waite-Smith deck with seeded reproducibility. It clearly distinguishes the core capability from sibling spread/daily/yes-no tools by emphasizing custom draw mechanics and deterministic seed behavior.

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 operational direction around seeding: provide a seed for reproducible readings, omit for true randomness, set allowReversals=false for upright-only, and allowDuplicates=true for oracle-style readings. It identifies this tool as suitable for custom spread builders and random card generators, implying when fixed-spread siblings would be more appropriate, though it does not name those alternatives explicitly.

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 no side-effect warning is needed. The description adds functional context such as the seven SWOT positions, but it does not describe response shape, pagination, rate limits, or reproducibility; seed behavior is left to the parameter 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?

The first sentence is a strong front-loaded summary. However, the description repeats career and use-case positioning across several clauses ('Perfect for...', 'Use for...', 'Ideal for...') and includes promotional filler like 'practical professional insight,' which does not earn its place for an agent deciding whether to call the tool.

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

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

The description covers the conceptual scope and common use cases well, and annotations cover safety. But with no output schema, it does not state what shape the response will take, and it omits any direct statement of the return value; these gaps keep it from being fully 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 provides descriptions for all four parameters, including enum values, defaults, and examples, so schema coverage is 100%. The tool description adds no parameter-level detail, making the baseline 3 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 opens with a specific verb and resource: 'Perform a comprehensive 7-card career tarot spread using SWOT analysis framework.' The career domain and seven named positions clearly set it apart from sibling spreads such as love, celtic_cross, and 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?

It explicitly lists concrete triggers: 'Use for career transitions, job offers evaluation, promotion decisions, starting a business, workplace conflicts...' This gives clear context for when the tool is appropriate. It does not mention when to prefer a sibling tool or provide exclusions, so it stops short of full routing guidance.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the tool returns ten position-specific insights, but it does not describe response structure, side effects, or runtime behavior beyond what the schema already covers.

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

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

The core purpose is front-loaded, but the description is heavily padded with promotional language such as 'legendary,' 'used by professional tarot readers worldwide for over a century,' and 'authoritative comprehensive readings.' This reduces clarity and adds little functional 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?

All parameters are optional and fully documented, and the description explains the meaning of all ten positions, so an agent can invoke the tool correctly. However, there is no output schema, and the description does not describe the exact return shape, leaving some uncertainty about what the response will contain.

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 parameters are already well documented. The description itself adds no parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action and resource: 'Perform the legendary Celtic Cross spread' with a 10-card layout, and it enumerates all ten positions. This makes it easy to distinguish from sibling spread tools like post_tarot_spreads_love or post_tarot_spreads_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?

The description provides explicit context for when to use the tool: 'Perfect for life-changing decisions, complex relationship questions, career transitions, spiritual guidance, and deep self-discovery.' However, it does not explicitly explain when to prefer other spread tools instead, so it stops short of full when-not guidance.

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

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

Annotations already cover safety, and the description adds meaningful runtime behavior: the API draws exactly one card per position, requires name and interpretation for each position, supports only up to 10 positions, and provides no pre-generated summary. There is no contradiction with the readOnlyHint.

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

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

The definition is front-loaded with a strong first sentence but becomes repetitive, especially the 'Perfect for...' and 'Ideal for...' use-case paragraphs that cover nearly the same ground. Several sentences are helpful, but trimming the redundant audience lists would tighten it without losing 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?

For a tool with six parameters and no output schema, the description covers the essential behavior clearly: custom positions, card count limits, the absence of a summary, and the mapping of cards to positions. It does not describe error cases or exact response fields, but those gaps are not critical for selecting and invoking 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 description coverage is 100%, giving a baseline of 3. The description adds value by explaining how the positions parameter drives the draw ('draws the exact number of cards you specify and maps them to your custom positions') and reinforcing that each position requires a name and interpretation.

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 ('build and perform') and resource ('custom tarot spread'), and clearly differentiates from the fixed sibling tools by emphasizing user-defined positions and a configurable 1-10 card count. Even without opening the schema, an agent can distinguish this from post_tarot_spreads_celtic_cross or post_tarot_daily.

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: it is 'perfect for' therapists, coaches, app developers, and anyone wanting 'specialized layouts beyond traditional spreads.' However, it never explicitly names alternative tools or states when not to use it, so the when-not guidance is only implied.

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

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

Annotations already mark the tool as read-only and non-destructive, so the description does not need to restate safety. It adds semantic behavioral detail about the five positions and their meanings, but it does not disclose the response structure, state persistence, or any operational constraints. Moderate 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 first sentence is front-loaded and useful, but the description becomes bloated with repetitive marketing phrases such as 'Perfect for dating apps...' and 'Ideal for understanding compatibility...' Many sentences do not earn their place for an agent deciding how to invoke the tool.

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

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

The description thoroughly explains the domain context and the meaning of the five positions, which is helpful because there is no output schema. However, it never describes what the API response actually contains, such as card names, images, interpretations, or the JSON shape, leaving a notable gap for processing the result.

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

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

Schema description coverage is 100%, so the schema fully documents lang, seed, compact, and question. The description adds no parameter-specific detail, and per the baseline for full schema coverage, a 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 opens with a specific verb and resource: 'Perform a specialized 5-card relationship tarot spread.' It clearly defines the love/relationship focus and names the five positions, making it easy to distinguish from career, celtic cross, and three-card 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?

The description gives clear context for when to use the tool, listing love-centered use cases like dating apps, relationship counseling, matchmaking, and self-love journeys. It does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

Annotations already establish read-only and non-destructive behavior. The description adds useful behavioral detail: each position includes reversal state, keywords, full meaning, position-specific interpretation, and a connecting summary, plus reproducible results via seed. It does not cover all response-shape details, but the main behavioral characteristics are disclosed.

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

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

The core behavior is front-loaded and the structure is logical, but the description includes some promotional filler such as 'perfect for quick insights' and 'Ideal for tarot reading apps, decision-making tools, and personal growth platforms.' These add context but are not strictly necessary.

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 adequately explains what the caller receives: card per position with reversal state, keywords, meaning, position-specific interpretation, and a summary. It does not deeply address each parameter, but the schema already covers those. Overall it is sufficient for a low-complexity read-only tool.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description adds only a brief mention of seeds and specific questions, which is useful but not substantial beyond what the schema provides. 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 uses a specific verb and resource: 'Perform the classic three-card tarot spread' and immediately enumerates the three positions (Past, Present, Future). Its name and content clearly distinguish it from the other spread tools in the sibling 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 description gives clear usage context: 'quick insights, daily guidance, or exploring specific questions' and labels it 'beginner-friendly.' It does not explicitly contrast it with sibling spreads like career, love, or celtic cross, so exclusions are absent, but the context is strong enough for selection.

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

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

Despite readOnlyHint and destructiveHint already covering safety, the description goes well beyond annotations by explaining card orientation mapping, special ambiguous cards, Major vs Minor Arcana strength, return payload contents, and seed reproducibility. This gives agents accurate expectations for how the tool 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?

The description is front-loaded with the core behavior, then systematically covers interpretation rules, output structure, use cases, and seed behavior. Every sentence contributes unique information with no redundancy.

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 listing the returned components: answer, strength level, drawn card details, and interpretive explanation. All parameters are documented in the schema, and the behavioral rules are fully specified, making the tool callable without further research.

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 the baseline is 3. The description adds slight value by explaining the seed's reproducibility and emphasizing question specificity, but it doesn't meaningfully expand on lang or compact beyond what the schema already documents.

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

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

The description states a clear verb and resource: ask a specific question and receive a yes/no/maybe answer from a single tarot card draw. It also distinguishes itself from sibling tools by focusing on yes/no outcomes and single-card mechanics, making the purpose unmistakable.

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

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

The description provides clear context for use: decision-making apps, quick guidance tools, chat bots, and interactive tarot experiences. It does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.

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