Server Quality Checklist

Tool Scores

• get_card_meaningA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It reveals the content of the response and the data source (Rider-Waite-Smith), but does not address edge cases like unknown card names, case sensitivity, or error handling. No contradictions with annotations exist since none are provided.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the action and resource, and lists the contents efficiently. Every sentence adds value with no repetitions or fluff.

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

  Completeness4/5

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

  Despite lacking an output schema and annotations, the description lists the major return fields and provides guidance on invocation, making it quite complete for a simple lookup. It misses only minor details about unknown names or formatting, so not a 5.

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

  Parameters3/5

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

  The input schema already fully documents the single 'name' parameter with an example. The description adds only 'by name' which reinforces but does not meaningfully extend beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool retrieves the full meaning of a single tarot card, listing specific fields (upright/reversed meanings, contexts, etc.). The phrase 'a single tarot card' and 'by name' distinguishes it from sibling tools like list_cards, search_cards, and draw_cards.

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

  Usage Guidelines4/5

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

  Explicitly states 'Call this when you need the meaning of a specific card by name,' providing clear usage context. However, it does not provide exclusions or name alternative tools, 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.

• list_cardsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full transparency burden. It describes the listing and filtering behavior, but does not disclose response format, ordering, or any side effects. This is minimally adequate for a simple read-only operation.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the main action, and no redundant phrasing. Every word earns its place.

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

  Completeness4/5

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

  For a simple list tool with fully described parameters, the description covers purpose and use case. It could explicitly mention the return format (e.g., an array of names), but the description is otherwise complete for its complexity level.

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

  Parameters3/5

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

  Schema coverage is 100% with enumerations and descriptions for both parameters. The description only restates the filter options without adding additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool lists tarot card names from the dataset, with optional filters by arcana or suit. The phrase 'Call this to discover valid card names' further clarifies its distinct role among sibling tools.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Call this to discover valid card names', giving a clear when-to-use instruction. It does not list exclusions or alternatives, but the context is sufficient for a listing tool.

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

• search_cardsA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description takes on the burden of explaining behavior. It states the search scope (names, keywords, meaning texts) and what is returned (matching cards with their keywords), adding clarity beyond the schema.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the core purpose and an example. Every sentence adds value, with no filler or repetition.

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

  Completeness5/5

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

  For a simple search tool with no output schema, the description adequately explains what is searched and what is returned. It is complete enough for an agent to select and invoke the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both parameters are already well-documented. The description adds example queries and search scope but doesn't introduce new parameter semantics beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: search all 78 tarot cards by theme or keyword. It provides concrete examples and distinguishes the tool from sibling tools by specifying search by theme rather than card name.

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

  Usage Guidelines4/5

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

  Gives explicit guidance to use when a theme is available rather than a card name, implying get_card_meaning is for name-based lookups. It doesn't name alternatives explicitly but provides clear context for when to call this tool.

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

• yes_no_answerA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the output (yes/no/maybe value and upright meaning), and states coverage of all 78 cards. It does not mention error handling or input variations, but for a simple read-only lookup this is adequate.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary purpose, and contains no filler. Every sentence adds value.

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

  Completeness5/5

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

  For a simple tool with one parameter and no output schema, the description fully explains what it returns (value and justification) and its scope (all 78 cards). No additional context is needed.

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

  Parameters3/5

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

  The schema already describes the single parameter 'name' as 'Card name' with 100% coverage. The description adds that it refers to a tarot card and covers all 78 cards, but does not specify formatting or exact name matching. This is sufficient given the schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool returns a yes/no/maybe value for a tarot card, specifically for yes-or-no readings, and includes upright meaning as justification. This is a specific verb+resource+scope and clearly distinguishes it from sibling tools like get_card_meaning, list_cards, and draw_cards.

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

  Usage Guidelines4/5

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

  The description gives clear context: this is for yes-or-no readings, implying it should be used when a binary or tri-state answer is needed. It does not explicitly name alternatives or exclusions, but the purpose is clear enough to guide selection among siblings.

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

• draw_cardsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It discloses key traits: 'distinct' cards (no repeats), 'optionally with reversals', and 'returning each card's full meaning'. It does not detail randomization mechanics, but for a simple draw tool it covers essential behavior.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main verb and resource, and every sentence contributes value. The second sentence provides usage guidance without redundancy. This is appropriately concise.

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

  Completeness4/5

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

  For a simple tool with two parameters and no annotations, the description covers purpose, usage, and return behavior. It mentions 'returning each card's full meaning' which indicates output content, and the 'reading spread' context clarifies typical use. Though no output schema exists, the description is adequate for this small tool.

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

  Parameters4/5

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

  Schema coverage is 100% (both parameters have descriptions), so the baseline is 3. The description adds value by clarifying that cards are 'distinct' (without replacement), which supplements the count parameter description, and 'optionally with reversals' maps directly to allow_reversed.

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

  Purpose5/5

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

  The description clearly states the tool randomly draws one or more distinct tarot cards from the full 78-card deck, optionally with reversals, and returns each card's full meaning. This specific verb+resource combination distinguishes it from siblings like get_card_meaning (specific card lookup) and list_cards (listing all cards).

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

  Usage Guidelines4/5

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

  The description explicitly provides a usage context: 'Use for generating a reading spread.' This tells the agent when to invoke the tool, though it does not explicitly mention alternatives or exclusions. The purpose clarity already differentiates from siblings, so the guidance is sufficient albeit not exhaustive.

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