tarot

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

Annotations already declare readOnlyHint=true and idempotentHint=true, which covers safety and idempotency. The description adds valuable context: the calculation is free, but full sphere interpretations are a paid product—the tool only returns a link. This disclosure of limitations is beyond what annotations provide and helps set agent expectations about outputs.

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 two sentences, front-loaded with the core purpose (what it calculates) and then a concise note about pricing and output. Every sentence contributes necessary information: the first defines the output, the second explains the free/paid boundary and that a link is provided. No redundant or fluff 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?

Given the tool has no output schema and moderate complexity, the description adequately conveys what the tool returns (arcana with names at key points) and the link for paid texts. It doesn't specify response format or link details, but for a calculation tool with annotations and clear schema, it is sufficiently complete. Minor gap: does not state what happens with invalid dates or error handling, but that's not critical.

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 covers 100% of parameters with descriptions, including date format and locale default. The description does not add any additional semantic meaning beyond what the schema provides. It mentions 'по дате рождения' but that's inherent to the tool's purpose, not new parameter detail. 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 clearly states the tool calculates 'Матрица судьбы' (Matrix of Fate) from a birth date, listing output types (arcana at key points like personal portrait, destiny, money, love). This specific verb+resource distinguishes it from siblings like calculate_pythagoras, and 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?

The description does not explicitly state when to use this tool versus alternatives, nor provide exclusions. It implicitly differentiates itself by naming the Matrix of Fate, but there is no direct guidance on choosing this over calculate_pythagoras or other sibling tools. The context is clear enough, but the explicit when/when-not is missing.

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 adds context beyond annotations by stating the calculation is free and the tool provides a link to a paid detailed analysis. This is additional behavior not captured by readOnlyHint, idempotentHint, or destructiveHint. It also clarifies the scope of output (cells 1-9 and additional numbers) which complements the safety 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 brief (two sentences) and front-loaded with the core purpose. It avoids redundant details and each sentence adds value: first explains what it does, second explains cost/link behavior. No 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 (2 parameters), the description explains the output (cells 1-9 and additional numbers) and the paid-link feature. Though there is no output schema, the description sufficiently sets expectations for a free calculation that returns these data and a link. It would benefit from an explicit mention that it returns a structured representation, but overall it is 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% for both parameters, so the description does not need to add parameter explanations. The description does not explicitly mention parameters but the schema already provides defik for 'date' and 'locale'. The free/paid aspect is not directly parameter-related, so no increment beyond 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 clearly states the tool computes the Pythagoras Square (psychomatrix) from a date of birth, specifying the output as filledness of cells 1–9 and additional numbers. This is a specific verb+resource, and it distinguishes the tool by its content focus, though sibling differentiation is not 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 explicit guidance is provided on when to use this tool versus alternatives like 'calculate_matrix' or other divination tools. The description implies it is for the Pythagoras Square but does not give exclusions or context on selection criteria.

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 clear. The description adds useful behavioral context: it works across all Arcanika decks with per-deck meaning variations, and returns multiple dimensions (love, career, advice, etc.) in both upright and reversed positions. No contradictions 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?

Two concise sentences that front-load the core purpose and immediately clarify the single-card scope and pointer to start_reading for multi-card spreads. No filler or redundant 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 read-only lookup tool with no output schema, the description adequately describes what the response will contain (meaning sections, upright/reversed, deck-specific) and clarifies constraints (one card only, paid multi-card alternative). It fully equips the agent for 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 coverage is 100% with detailed parameter descriptions (e.g., card name/slug formats, deck slug from list_decks, locale enum with defaults). The description repeats some of this (e.g., deck slug reference) but adds no significant new meaning beyond the schema, so a baseline score 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 tool returns the meaning of one Tarot card with specific sections (keywords, general, love, career, advice) in both upright and reversed positions. It explicitly distinguishes from the sibling 'start_reading' tool by stating it's for a single card, and from 'calculate_matrix' and 'calculate_pythagoras' by focusing on card meanings.

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

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

Provides explicit guidance: works with any Arcanika deck, and directs users to 'start_reading' for multi-card readings (which is a paid product). Also references 'list_decks' for obtaining deck slugs, giving clear context on when to use this tool versus alternatives.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which covers safety. The description adds that it's specifically Lenormand (not Tarot) and lists the types of information returned, which is useful but does not describe the output structure, any potential errors, or pagination. It adds some value but not extensive.

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 single sentence that is concise and front-loaded. It immediately states the tool's purpose and lists the key output aspects without unnecessary verbosity. Every word adds 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?

Given the simple nature of the tool (one required parameter, read-only), the description is complete enough. It specifies the card type, the non-Tarot distinction, and the aspects of information returned. With annotations covering safety and schema covering parameters, the description adds sufficient context for a lookup tool. It could mention the output format or the meaning of the fields, but that may be inferred from the description.

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

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

The input schema fully documents both parameters: 'card' (name, slug, or number) and 'locale' (enum with ru/en, default ru). The description does not elaborate on parameter values beyond what the schema already provides. Since schema coverage is 100%, a baseline of 3 is appropriate.

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

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

The description clearly states the tool returns a Lenormand oracle card (36 cards, not Tarot) and lists the specific information provided (key, theme in Grand Tableau, essence, love, work, timing). It uses a specific noun (card) and verb (get) and explicitly differentiates from Tarot, which helps distinguish from sibling tools like get_card_meaning.

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 implies usage for Lenormand cards and even notes 'not Tarot', suggesting a contrast with get_card_meaning. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or context (e.g., 'for general card meanings, use get_card_meaning'). There is minimal guidance beyond the implicit contrast.

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, idempotent, harmless behavior. The description adds useful behavioral context by revealing that results include page addresses and that each deck has unique card meanings, which goes beyond the structured 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 two short sentences, front-loaded with the core purpose, and adds only essential details. No wasted words or 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?

For a simple listing tool with one optional parameter and no output schema, the description provides sufficient context: it explains the content (decks) and mentions page addresses and unique card meanings. It could mention response format or filtering, but given the simplicity, it is adequately 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 schema fully describes the only parameter 'locale' with an enum and default. The tool description does not mention this parameter, but since schema coverage is 100%, the description does not need to add more. It neither repeats nor adds extra value, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool lists Arcanika decks (Tarot and oracles) with page addresses, and notes that each deck has its own card meanings. This specific verb+resource combination distinguishes it from sibling tools like get_card_meaning or list_spreads, 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 gives the general context (listing decks with page addresses) but does not explicitly state when to use this tool versus others, nor any exclusions or prerequisites. The distinction is implicit from the name and siblings, but no direct guidance is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool reveals free vs. paid status and pricing, which is useful output-context. It does not contradict annotations (no annotation_contradiction). However, it adds no detail on output format, pagination, or other behavioral traits beyond the product-content listing.

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 sentences, front-loaded with the core purpose, followed by the pricing distinction in the second sentence. The long listing of product categories is informative, not redundant, and there is zero filler. Efficiently structured for the information conveyed.

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 only 1 optional parameter (fully schema-documented), no output schema, and no nested objects, this is a low-complexity tool. The description adequately covers what the tool does and what it reveals (product catalog with pricing). A short note on return format would be nice, but the description is essentially complete for this complexity level.

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% – the single optional locale parameter is fully documented with its enum (ru/en) and default (ru) in the schema. The description makes no mention of this parameter, but since the schema does the heavy lifting, 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 starts with a specific verb+resource ('Обзор всех продуктов Arcanika' – overview of all products), enumerates the full catalog (Tarot, decks, Fate Matrix, Pythagorean Square, dream interpretation, etc.), and adds the pricing/free-paid distinction. This clearly distinguishes it from siblings like list_decks and list_spreads, which are narrower subsets, and from calculation tools like calculate_matrix.

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: the description frames this as the comprehensive overview tool covering all products and pricing, contrasting with more specific siblings (list_decks, list_spreads). However, there is no explicit when-to-use/when-not-to-use guidance or named alternatives, so the agent must infer the tool's role from scope rather than receive direct instruction.

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 safe read-only nature is established. The description adds that this is a catalog view with no paid content, clarifying the scope boundary. This is useful but doesn't go much beyond what annotations provide; it doesn't get into rate limits, auth, or failure modes.

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

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

Two sentences: the first lists what's included, the second clarifies what's not. Concise and front-loaded with the core purpose. Could be slightly tightened but overall efficient.

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 listing tool with no required parameters, a short description suffices. The description explains the catalog contents and explicitly notes that detailed interpretations are a paid feature elsewhere. This covers the main use case without needing more elaboration.

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 both parameters are documented in the schema. The description mentions filtering by theme implicitly ('о чём расклад') and the query parameter examples ('любовь', 'работа', 'год') are in the schema. The description itself doesn't add parameter details beyond the schema, so 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 clearly states this lists Tarot spreads with title, card count, theme, and page URL. It distinguishes this as a catalog-listing operation. However, it doesn't explicitly differentiate itself from sibling tools like get_card_meaning or list_decks, though the resource types differ.

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 implies a catalog-browsing use case and explicitly states what's NOT included (position breakdowns and card interpretations are paid). It doesn't name alternatives like list_decks or get_card_meaning, so usage guidance is implied rather than explicit.

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, so the agent knows this is a safe read operation. The description transparently discloses that the tool does not return the reading itself but only a link, which is a key behavioral aspect. It mentions that the interpretation is part of the paid service, which sets expectations. However, it doesn't detail rate limits, authentication, or what happens if spread is invalid, though such details are not required given the tool's simplicity.

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 two-sentence block. It front-loads the core function (link to interactive spread) and efficiently explains the critical limitation (does not return interpretations). No word is wasted, and the em-dash style adds clarity. It earns a 5 for its structure and 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?

For a simple, read-only tool with full schema coverage and no output schema, the description is complete. It clearly states the tool's output (a URL) and the paid-nature context. It doesn't mention error cases or locale handling, but these are minor. Given the tool's simplicity and the support from annotations and schema, the description is sufficiently complete. A 4 is appropriate, slightly above average due to the clear scope restriction.

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 100% of the parameters with descriptions, providing a baseline of 3. The description adds context that the 'spread' parameter refers to a title or slug from list_spreads and that omitting it leads to a catalog, which goes slightly beyond the schema. The description text repeats the schema info but doesn't add parameter-specific semantics. Given full schema coverage, the description's implicit reference to list_spreads adds a bit more.

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: it provides a link to an interactive Tarot spread on Arcanika. It explains that cards are drawn and interpreted within the product, not returned by the tool. This distinguishes it clearly from tool functions that would return interpretations, distinguishing it from 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 explains what the tool does NOT do (does not return interpretations) and what it does (returns a URL for the user to perform the spread). It gives context that the interpretation is the paid part of the service. It doesn't explicitly name sibling alternatives, but the list of siblings (like get_card_meaning, list_spreads) provides alternatives; the description's clarification of scope is helpful. The guidance could be stronger by naming a specific alternative tool to use instead of asking for a reading.

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