Real random tarot draws, card meanings, I Ching casting, BaZi charts and Chinese zodiac (EN/JA).
Scored across 6 tools
The set splits cleanly along three divination systems, and each description explicitly tells the agent when to use it (e.g. 'use this instead of making up a hexagram'). The only mild overlap is between bazi_chart and chinese_zodiac, which both derive from a birth date and both handle Li Chun/Lunar New Year boundaries, so an agent could hesitate on a 'tell me about my birth chart' request.
All names are snake_case, but the conventions are mixed: cast_i_ching, draw_tarot_cards, get_hexagram and get_tarot_card_meaning are verb-led while bazi_chart and chinese_zodiac are bare nouns. Readable and guessable, but not a single predictable pattern.
Six tools is well-scoped for a divination server: exactly two tools per practice (cast + lookup for I Ching, draw + lookup for tarot), plus one each for BaZi and zodiac. Each tool earns its place with no filler.
Tarot and I Ching both have draw/cast plus a lookup, giving full lifecycle coverage. BaZi has only a chart calculator with no follow-up lookup for individual stems, branches or Ten Gods, and the zodiac tool only covers the 2027 forecast, which are minor gaps an agent can work around.
Calculate a BaZi / Four Pillars of Destiny chart from a birth date, optional birth time and the birthplace time zone. Uses solar-term boundaries (the year changes at the Start of Spring, Li Chun) via an astronomical calendar engine. Returns the four pillars with Ten Gods, the Day Master, five-element balance, luck pillars and the coming years.
| Name | Required | Description | Default |
|---|---|---|---|
| gender | No | Needed only for the direction of the luck pillars. | |
| language | No | Output language. Use "ja" when the user writes in Japanese: Japanese card / hexagram names, meanings and links to the Japanese pages. Otherwise "en". | en |
| timezone | Yes | IANA time zone of the birthplace, e.g. "America/New_York" or "Asia/Shanghai". | |
| birth_date | Yes | Gregorian birth date, YYYY-MM-DD (local date at the birthplace). | |
| birth_time | No | Local clock time HH:mm. Omit if unknown (gives a three-pillar chart). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the non-obvious computation rule (solar-term boundaries, year changing at Li Chun via an astronomical calendar engine) and enumerates what the result contains. It doesn't state that the operation is purely computational/non-mutating or discuss determinism or cost, but the methodology disclosure is genuinely useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences: what it computes, how the calendar logic works, and what comes back. Nothing is repeated and the core purpose is front-loaded.
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 enumerating return contents (four pillars, Ten Gods, Day Master, five-element balance, luck pillars, coming years), which is enough for an agent to know what it will get. The main remaining gap is guidance on choosing this over the sibling divination tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all five parameters including the gender and language enums. The description adds only a high-level mention of birth date, optional birth time and timezone, and says nothing about gender or language, so it does not meaningfully exceed the schema 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?
States a specific verb (Calculate) and a specific resource (BaZi / Four Pillars of Destiny chart), plus the exact inputs it derives from. It is clearly distinguishable from siblings like cast_i_ching, chinese_zodiac and draw_tarot_cards without opening any schema.
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 when the tool applies (birth-data-based BaZi charting) and notes the birth time is optional, but it never states when to prefer it over chinese_zodiac or cast_i_ching, nor any exclusions or prerequisites. Usage is inferable rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cast an I Ching reading with the traditional three-coin method (six tosses, bottom line first). Returns the primary hexagram, any changing lines and the relating (transformed) hexagram, with links to each hexagram's meaning. Use this instead of making up a hexagram.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Output language. Use "ja" when the user writes in Japanese: Japanese card / hexagram names, meanings and links to the Japanese pages. Otherwise "en". | en |
| question | No | The question being asked (echoed back only; not stored). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the casting mechanic (six tosses, bottom line first) and the complete result shape (primary hexagram, changing lines, relating hexagram, meaning links). It omits whether the cast is random/stateless and whether repeated calls yield different results, which matters for a divination tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: method first, return value second, usage rule last. No filler and nothing redundant with the title.
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 two-parameter, zero-required tool with no output schema, the description usefully enumerates what comes back and how the hexagram is derived. Minor gaps remain around non-determinism and whether the question influences the cast, but an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including a detailed language enum explanation and the note that question is echoed back only and not stored, so the schema already does the heavy lifting. The description adds no parameter-level meaning beyond it; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (cast) and resource (I Ching reading) plus the exact method (traditional three-coin, six tosses, bottom line first), which is far more informative than the title alone. It does not explicitly differentiate from the sibling get_hexagram (lookup of a known hexagram), leaving that distinction to be inferred.
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?
"Use this instead of making up a hexagram" gives clear, actionable usage guidance and implicitly rules out fabrication. It stops short of naming alternatives or exclusions, such as when to use get_hexagram instead or whether repeated casts are meaningful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a person's Chinese zodiac animal from a birth year or date (handles the Lunar New Year and Start of Spring boundaries for January–February births) and return the 2027 Year of the Fire Goat forecast for that sign: love, career, money and a tip.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Output language. Use "ja" when the user writes in Japanese: Japanese card / hexagram names, meanings and links to the Japanese pages. Otherwise "en". | en |
| timezone | No | IANA time zone of the birthplace (e.g. "America/New_York"). Only matters for births near the Start of Spring in early February. | |
| birth_date | Yes | Birth year (YYYY) or full date (YYYY-MM-DD). A full date is needed to be exact for January–February births. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden and does add real behavior: it discloses the Lunar New Year and Start of Spring boundary handling and enumerates the forecast sections returned, which substitutes for the missing output schema. It does not mention behavior for invalid/implausible years or whether the forecast is fixed to 2027 only.
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?
A single well-formed sentence that front-loads the primary lookup and then the returned forecast. No filler, no repetition of the title.
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 usefully summarizes the return payload (love, career, money, tip) and the boundary-handling nuance that affects accuracy. Minor gaps remain around error behavior and whether non-2027 years still produce a sign-only 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 birth_date, timezone and language are already fully documented, including the Jan–Feb exactness caveat. The description reinforces but adds no syntax or format detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find a person's Chinese zodiac animal from a birth year or date') plus the second output ('2027 Year of the Fire Goat forecast'). Sibling tools (bazi_chart, tarot, I Ching) are clearly different domains, so an agent can pick this without opening the schema.
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 makes the trigger condition clear: birthday/year in, sign plus 2027 forecast out, with a full date required for January–February exactness. It gives no explicit exclusions or naming of alternatives (e.g. bazi_chart for a deeper chart), 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.
Draw tarot cards at random from a full 78-card Rider–Waite–Smith deck (cryptographically random, no repeats). Returns each card with its position, upright/reversed orientation, keywords and a link to its full meaning. Use this instead of inventing cards when a user asks for a tarot reading.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many cards to draw (1–10). 1 = single card / yes-no, 3 = past-present-future. | |
| language | No | Output language. Use "ja" when the user writes in Japanese: Japanese card / hexagram names, meanings and links to the Japanese pages. Otherwise "en". | en |
| question | No | The question being asked (echoed back only; not stored). | |
| positions | No | Optional position names in order, e.g. ["Past", "Present", "Future"]. | |
| allow_reversed | No | Whether cards can come up reversed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and usefully discloses that draws are cryptographically random with no repeats. It also lists return contents (position, orientation, keywords, meaning link), though it does not explicitly state the absence of side effects or persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core action and deck scope, and each sentence earns its place. It moves efficiently from what the tool does to what it returns to when to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description explains the key returned fields: position, orientation, keywords, and meaning link. Given the fully described input schema and the tool's straightforward read-only nature, no critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains count, language, question, positions, and allow_reversed. The description adds no parameter-level guidance beyond what the schema provides, matching the baseline 3 for fully documented 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 states a specific verb and resource: drawing tarot cards at random from a full 78-card Rider-Waite-Smith deck. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling get_tarot_card_meaning beyond implying that card meanings are linked.
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 gives a clear use case: use this instead of inventing cards when a user asks for a tarot reading. It does not specify when not to use it or name sibling alternatives such as get_tarot_card_meaning for pure meaning lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one of the 64 I Ching hexagrams by number (1–64), English name ("The Wanderer"), Chinese character (旅), Japanese name (火山旅) or pinyin (ambiguous pinyin like "lu" returns the candidates). Returns its essence, judgment, image, love and career readings, guidance and the six line texts.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Changing line numbers to highlight (1 = bottom). | |
| hexagram | Yes | Number 1–64, English name, Japanese name or pinyin. | |
| language | No | Output language. Use "ja" when the user writes in Japanese: Japanese card / hexagram names, meanings and links to the Japanese pages. Otherwise "en". | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does useful work: it lists the returned fields (essence, judgment, image, love/career readings, guidance, six line texts) and discloses the ambiguous-input fallback (returns candidates rather than failing). It doesn't mention pagination, error behavior for out-of-range numbers, or an explicit read-only statement, so not a 5.
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 lookup action and followed by the return contents. Dense but nearly every clause carries information. The long parenthetical enumerations make it slightly heavy, but there is no filler.
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 usefully enumerates the return payload, and the language parameter is thoroughly documented in the schema. The only gap is the lines parameter (highlighting changing lines), which is a functional behavior the description never mentions, so an agent might overlook it.
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 genuine meaning beyond the schema: it documents the Chinese-character input form (旅) that the schema's parameter description omits, gives a concrete English-name example, and explains the ambiguity behavior for pinyin, which the schema does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Look up") and resource ("one of the 64 I Ching hexagrams") and enumerates the accepted identifier forms, which is clear and actionable. It doesn't explicitly differentiate itself from the sibling cast_i_ching (the casting tool) or get_tarot_card_meaning, so it stops short of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: this is the lookup tool for retrieving a known hexagram's meaning. The description clarifies that ambiguous pinyin returns candidates, which helps the agent handle fuzzy input. However, it never states when to use this versus cast_i_ching (to generate a hexagram) or get_tarot_card_meaning, leaving the sibling routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the meaning of a tarot card: keywords, upright and reversed meaning, love, feelings, career and money readings, and whether it leans yes or no. Accepts names like "The Tower", "3 of Cups", "Queen of Swords" or "ace of coins".
| Name | Required | Description | Default |
|---|---|---|---|
| card | Yes | Card name, e.g. "The Moon", "Five of Wands", 「月」 or 「ワンドの5」. | |
| topic | No | Which aspect to return. | all |
| language | No | Output language. Use "ja" when the user writes in Japanese: Japanese card / hexagram names, meanings and links to the Japanese pages. Otherwise "en". | en |
| orientation | No | both |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. 'Look up' strongly implies a non-mutating read, and the enumeration of returned fields (keywords, upright/reversed, topic readings, yes/no) gives real transparency about output shape. It is silent on behavior for unrecognized card names, on whether matching is fuzzy, and on latency/limits, which matters more here precisely because there are no 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 sentences, no filler, and the core purpose is front-loaded ahead of the supported input formats. The content list is a bit dense but each clause maps to a real return field, so nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does the heavy lifting well: it names the returned facets and the accepted input shapes. The remaining gaps are error behavior for unknown cards and the meaning of the orientation default, which is a modest but real omission for a four-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, with card, topic and language documented but orientation left bare. The description compensates usefully by supplying additional accepted name formats ('3 of Cups', 'Queen of Swords', 'ace of coins') beyond the schema's examples, signalling tolerant, case- and article-insensitive matching. The mention of 'upright and reversed meaning' also hints at orientation behavior, though it does not explain the default 'both' or the language switch.
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 definition opens with a specific verb and resource ('Look up the meaning of a tarot card') and then enumerates the exact content returned: keywords, upright/reversed meaning, love/feelings/career/money readings, and yes/no lean. That is far more informative than the title alone. It stops short of naming the sibling it differs from (draw_tarot_cards), so an agent must infer that this one retrieves an existing card's interpretation rather than drawing a new spread.
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 is only implied: 'look up' suggests a retrieval task once a card is already known, which distinguishes it in spirit from draw_tarot_cards, but the description never says when to pick this over drawing. There are no explicit exclusions, prerequisites, or fallback guidance for unknown card names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bazi_chartcast_i_chingchinese_zodiacdraw_tarot_cardsget_hexagramget_tarot_card_meaningFree BaZi, I Ching, tarot, Zi Wei and bilingual learning tools with transparent methods. No API key.
I-Ching (周易) oracle: cast a hexagram, read classical commentary, get a reflection. Bilingual.
Tarot card meanings, spreads and seeded reproducible readings for AI agents, one API key.
Cast I Ching hexagrams with moving lines; classical + English judgments for all 64.
Add one secure layer between your agents and this server.