I Ching MCP Server by RoxyAPI
Server Details
I Ching hexagram casts, 64 hexagram meanings and changing lines for AI agents.
- Status
- Healthy
- Uptime
- 99.9% over 41 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 9 tools
Tools mostly target distinct retrieval methods (all hexagrams, by number, by binary pattern, random) but some overlap exists between get_iching_hexagrams_random and post_iching_daily, and between get_iching_cast and post_iching_daily_cast. The descriptions are clear enough to differentiate these pairs, though an agent might briefly hesitate.
All tool names follow a consistent verb_noun pattern with snake_case, using get_ and post_ verbs followed by 'iching_' and a resource. Variants like get_iching_hexagrams_lookup and get_iching_trigrams_id maintain the same convention, making the set predictable and easy to navigate.
9 tools is well within the ideal 3-15 range for a domain like I Ching reference and divination. The number feels justified: retrieval methods for hexagrams (all, by number, by pattern, random), trigrams, casting, and daily readings each earn their place without bloat.
The tool surface covers the core domain comprehensively: casting full readings, retrieving individual hexagrams by various methods, listing all hexagrams, accessing trigrams, and providing daily readings. No critical operations appear missing for an oracle/divination server.
Available Tools
9 toolsget_iching_castCast an I-Ching reading - Hexagram divination APIARead-onlyInspect
Generate an authentic I-Ching reading using the traditional three-coin casting method. Each of the six lines is determined by virtually tossing three coins, producing values 6-9 where 6 (old yin) and 9 (old yang) are changing lines. Returns the primary hexagram with full interpretation, the line values showing which lines are changing, and if any lines change, the resulting hexagram that the primary transforms into. Optionally provide a seed for reproducible castings. Perfect for divination apps, oracle features, and decision-making tools.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| seed | No | Optional seed for reproducible castings. Same seed = same casting every time. Pass any unique identifier (userId, session token, question hash). Omit for random casting. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| seed | No | |
| lines | Yes | |
| hexagram | No | |
| resultingHexagram | No | |
| changingLinePositions | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive. The description adds meaningful behavioral context: virtual three-coin tossing, line values 6-9, changing-line mechanics, transformation into a resulting hexagram, and reproducible castings via an optional seed. This goes well beyond the annotations without contradicting them.
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 three well-organized sentences that front-load the core purpose and casting method, then cover outputs and optional seed behavior. The final sentence about use cases is slightly generic but not wasteful, keeping the description appropriately sized.
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 output schema and annotations, the description covers the essential behavior, return semantics, and the optional seed. It does not mention language or compact options, but those are fully documented in the schema, so the overall context is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents lang, seed, and compact. The description only touches on the seed ('Optionally provide a seed for reproducible castings'), which adds little beyond the schema's already explicit 'Same seed = same casting every time.' 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 names a specific verb and resource: 'Generate an authentic I-Ching reading using the traditional three-coin casting method.' It also explains what the output contains and differentiates this casting tool from sibling hexagram/trigram lookup tools by emphasizing full reading generation with changing lines.
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 provides clear context for when to use the tool: 'Perfect for divination apps, oracle features, and decision-making tools.' It does not explicitly name alternative siblings or state when not to use it, but the intended use case is evident from the casting-focused description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_iching_hexagramsList all 64 hexagrams - I-Ching hexagram catalog APIARead-onlyInspect
Browse all 64 I-Ching hexagrams from the Book of Changes with their Chinese names, English translations, and trigram compositions. The hexagrams are ordered by the traditional King Wen sequence used in I-Ching divination for 3,000 years. Each hexagram represents a unique life situation combining two trigrams (Heaven, Earth, Thunder, Wind, Water, Fire, Mountain, Lake) into profound wisdom for decision-making and self-understanding.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| limit | No | Maximum items to return per page. Range: 1-64, default 20. | |
| offset | No | Number of items to skip for pagination. Default 0. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| hexagrams | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful context about King Wen ordering and the included content fields, but does not add operational behaviors like pagination defaults or language fallback; those live in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: the first sentence states the action and content, and the second adds ordering context. The third sentence is somewhat ornamental ('profound wisdom for decision-making') but not long enough to significantly hurt usefulness.
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 zero required parameters, a read-only annotation, and a full output schema, the description covers everything needed to invoke the tool correctly. The only real gaps are not mentioning sibling alternatives and a bit of nonessential prose in the final sentence.
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%: lang, limit, offset, and compact are all already documented with defaults, ranges, and examples. The description adds no parameter-level meaning, so the 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?
The description names a specific action ('Browse all 64 hexagrams') and resource, and the title reinforces the catalog scope. The 'all 64' framing distinguishes it from sibling lookup/number/random tools, though it never explicitly names those siblings, keeping it from a 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?
The usage is implied: use this tool when you want the full King Wen-ordered catalog of all 64 hexagrams. However, there is no explicit when-to-use vs alternative guidance, such as pointing to get_iching_hexagrams_lookup or random for single-hexagram needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_iching_hexagrams_lookupLookup hexagram by line pattern - I-Ching binary lookup APIARead-onlyInspect
Find an I-Ching hexagram by its binary line pattern. Provide 6 digits (0 or 1) representing broken (yin) and solid (yang) lines from bottom to top. Use this for custom divination interfaces where users input their own line configurations, or to find hexagrams matching specific trigram combinations. Example: "111111" returns Hexagram 1 (The Creative), "000000" returns Hexagram 2 (The Receptive).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| lines | Yes | Six-digit binary pattern (0=yin/broken, 1=yang/solid) from bottom to top. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| image | Yes | |
| binary | Yes | |
| number | Yes | |
| pinyin | Yes | |
| symbol | Yes | |
| chinese | Yes | |
| english | Yes | |
| judgment | Yes | |
| lowerTrigram | Yes | |
| upperTrigram | Yes | |
| changingLines | Yes | |
| interpretation | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safe read behavior. The description adds the bottom-to-top line order and worked examples like '111111' -> Hexagram 1, but does not discuss error handling, response shape, or edge cases. It is adequate but not rich.
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 three well-structured sentences: purpose, usage context, and concrete examples. It is front-loaded and free of filler or redundant schema repetition.
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 rich schema coverage, an output schema, and safety annotations, the description covers the essential entry point and usage context. It could mention invalid-input behavior or explicitly route to sibling tools, but nothing critical is missing for invoking the tool 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?
The schema already documents all three parameters thoroughly, including the line pattern, language enum with fallback behavior, and compact output format. The description mostly repeats the lines format and adds example output mapping, which is useful but not additive 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 action and target: 'Find an I-Ching hexagram by its binary line pattern.' It clarifies the input semantics and provides concrete examples, making it easy to distinguish from siblings like get_iching_hexagrams_number or get_iching_hexagrams_random.
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 explicitly identifies intended contexts: custom divination interfaces where users enter their own line configurations, and matching specific trigram combinations. It does not name sibling alternatives or state when not to use the tool, so it falls 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.
get_iching_hexagrams_numberGet hexagram by number - I-Ching hexagram detail APIARead-onlyInspect
Retrieve complete I-Ching hexagram details by King Wen sequence number (1-64). Returns the full hexagram with Chinese name, English translation, judgment text, image text, modern interpretations for general situations, love, career, and decision-making, plus all six changing line meanings. Use this to display detailed hexagram information after casting or for educational reference.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| number | Yes | Hexagram number in King Wen sequence (1-64). | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| image | Yes | |
| binary | Yes | |
| number | Yes | |
| pinyin | Yes | |
| symbol | Yes | |
| chinese | Yes | |
| english | Yes | |
| judgment | Yes | |
| lowerTrigram | Yes | |
| upperTrigram | Yes | |
| changingLines | Yes | |
| interpretation | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with a pure retrieval operation. The description adds useful content expectations but no additional behavioral caveats such as authentication, rate limits, or response-size implications.
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 with no filler: it front-loads the core action, summarizes the valuable return content, and closes with concrete use cases. Every sentence earns its 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?
Given the output schema, read-only annotations, and fully described parameters, the description covers what an agent needs to operate the tool. It adds use context ('after casting or educational reference'), though it could more explicitly relate this tool to sibling tools like get_iching_hexagrams_lookup.
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 documents number, lang, and compact comprehensively. The tool description only echoes the number range and does not add meaning beyond the schema, matching the baseline for full coverage.
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 ('Retrieve'), a specific resource ('I-Ching hexagram details'), and a precise access method ('King Wen sequence number'). It also enumerates the returned content, making the tool's function unambiguous and distinguishable from sibling lookup/random/cast tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear positive usage context: display detailed hexagram information after casting or for educational reference. It does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_iching_hexagrams_randomRandom hexagram - I-Ching hexagram picker APIARead-onlyInspect
Receive a random I-Ching hexagram with full interpretation. Perfect for daily oracle features, meditation prompts, or exploring the Book of Changes. Returns complete hexagram data including judgment, image, interpretations for love/career/decisions, and all six changing line meanings.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| image | Yes | |
| binary | Yes | |
| number | Yes | |
| pinyin | Yes | |
| symbol | Yes | |
| chinese | Yes | |
| english | Yes | |
| judgment | Yes | |
| lowerTrigram | Yes | |
| upperTrigram | Yes | |
| changingLines | Yes | |
| interpretation | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false, so the description adds value by specifying the return content (judgment, image, interpretations, changing lines). This goes beyond annotations but does not discuss randomness behavior or other side effects.
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 concise sentences, front-loaded with the core action and wrapped up with return data. 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?
Given an output schema exists and the tool is simple, the description covers purpose, use cases, and return summary. It is adequate for an agent to invoke 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 coverage is 100% with full descriptions for both lang and compact. The description adds no parameter details, so it scores at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Receive a random I-Ching hexagram' with a specific verb and resource, and mentions use cases. It distinguishes from siblings implicitly by the 'random' qualifier, but does not explicitly name alternatives.
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 provides context on when to use (daily oracle, meditation, exploration) but does not explicitly state when not to use or compare with sibling tools like get_iching_hexagrams_number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_iching_trigramsList all 8 trigrams - Bagua trigram catalog APIARead-onlyInspect
Retrieve all 8 I-Ching trigrams (bagua), the fundamental building blocks of hexagrams. Each trigram consists of three lines and represents a primal force of nature: Heaven (Qian), Earth (Kun), Thunder (Zhen), Wind (Xun), Water (Kan), Fire (Li), Mountain (Gen), and Lake (Dui). Understanding trigrams is essential for interpreting hexagram meanings, as each hexagram combines an upper and lower trigram.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| trigrams | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond the annotations by stating that the tool returns the complete set of all 8 trigrams and enumerates their names and elemental associations, which clarifies the response scope.
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 concise at three sentences and front-loads the core retrieval purpose. The second sentence enumerates the trigram names, which is valuable reference content, and the third provides relevant context without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full parameter schema, existing output schema, and read-only annotations, the description provides adequate context. The only minor gap is the lack of an explicit routing pointer to sibling tools for single-trigram lookups, but this does not prevent correct 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 description coverage is 100%, and both parameters (lang and compact) have thorough descriptions in the schema. The tool description itself adds nothing about parameters, so the baseline score of 3 is appropriate since the schema fully carries this burden.
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 all 8 I-Ching trigrams (bagua)'. It clearly identifies this as the catalog/list tool for the full set of trigrams, and the follow-on explanation of trigrams as hexagram building blocks differentiates it from the hexagram-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is useful when an agent needs the foundational trigram catalog or is preparing to interpret hexagrams. However, it does not explicitly state when to use this tool versus siblings like get_iching_trigrams_id or get_iching_hexagrams, nor does it name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_iching_trigrams_idGet trigram by number or name - Bagua trigram detail APIARead-onlyInspect
Retrieve a specific I-Ching trigram by its number (1-8) or English name (Heaven, Earth, Thunder, Wind, Water, Fire, Mountain, Lake). Returns complete trigram information including Chinese name, pinyin, element associations, core attributes, and symbolic meaning. Use this to understand the component trigrams of any hexagram.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Trigram number (1-8) or English name (Heaven, Earth, Thunder, Wind, Water, Fire, Mountain, Lake). | |
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| animal | Yes | |
| binary | Yes | |
| number | Yes | |
| pinyin | Yes | |
| season | Yes | |
| symbol | Yes | |
| chinese | Yes | |
| element | Yes | |
| english | Yes | |
| meaning | Yes | |
| quality | Yes | |
| bodyPart | Yes | |
| attribute | Yes | |
| direction | Yes | |
| familyMember | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the operation returns complete trigram details, but does not disclose behaviors beyond that; this meets the baseline but adds only modest additional transparency.
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 with no filler. The primary retrieval action and accepted inputs are front-loaded, followed by the return content and the practical use case, every sentence earning its 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 single-resource read operation with full annotation coverage, a complete input schema, and an output schema, the description covers all essential context. It explains what is retrieved, how to identify the resource, and why an agent would use 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 schema already documents all three parameters. The description adds explicit meaning for the id parameter by listing the exact English names and the 1-8 numeric range, which helps an agent construct valid calls even before reading 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?
Description states a specific verb and resource: retrieve a single trigram by number or English name, with the acceptable values enumerated. It is clearly distinguished from the sibling list tool get_iching_trigrams and the hexagram-focused 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 final sentence gives a concrete use case: understanding the component trigrams of any hexagram. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select this tool over the list-style sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_iching_dailyDaily hexagram - Daily I-Ching oracle APIARead-onlyInspect
Receive a daily I-Ching hexagram for guidance and reflection. This endpoint uses seeded randomness to ensure the same seed gets the same hexagram on the same day, perfect for "Hexagram of the Day" features in oracle apps, meditation platforms, and daily wisdom tools. Returns the hexagram with judgment, image, and interpretations for love, career, decisions, and practical advice based on ancient Chinese wisdom from the Book of Changes.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date for the reading in YYYY-MM-DD format. Defaults to today (UTC). Useful for viewing past daily readings or pre-generating future ones. | |
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| seed | No | Optional seed for reproducible readings. Same seed + same date = same hexagram every time. Pass any unique identifier (userId, email hash, session token). Omit for anonymous daily readings. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| seed | Yes | |
| hexagram | Yes | |
| dailyMessage | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a read-only, non-destructive operation. The description adds useful behavioral context—seeded randomness for reproducibility and the daily determinism—but does not describe the output format or any potential side effects beyond that. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core purpose (receive a daily hexagram) before elaborating on use cases and content. It is appropriately sized for the tool's simplicity, with no filler or redundant details.
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 presence of an output schema and complete parameter coverage, the description adequately covers what the tool returns (judgment, image, interpretations) and the key behavior (deterministic daily readings). It does not mention error handling or authentication, but these are not critical for a simple read-only endpoint with optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation covers all parameters at 100% coverage, so the description does not need to add much. It reinforces the seed parameter's determinism and mentions the lang fallback behavior, but these are already implied by the schema. The description adds slight value but does not go beyond the schema's explanations.
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 receives a daily I-Ching hexagram with seeded randomness, and lists the returned content (judgment, image, interpretations). It distinguishes itself from generic random hexagram tools by emphasizing the daily and deterministic nature, though it does not explicitly name sibling tools for contrast.
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 a use case ('Hexagram of the Day' features, meditation platforms) and explains the seed behavior for repeatable daily readings. However, it does not explicitly say when to prefer this tool over alternatives like post_iching_daily_cast or get_iching_hexagrams_random, leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_iching_daily_castCast daily reading with changing lines - I-Ching divination APIARead-onlyInspect
Cast a complete daily I-Ching reading using the traditional three-coin method with seeded randomness. Unlike the simple daily hexagram, this provides the full casting experience with line values (6-9), changing line positions, and the resulting hexagram if transformation occurs. Same seed + same date = same casting result. Perfect for I-Ching divination apps requiring authentic oracle experience with daily consistency.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date for the reading in YYYY-MM-DD format. Defaults to today (UTC). Useful for viewing past daily readings or pre-generating future ones. | |
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| seed | No | Optional seed for reproducible readings. Same seed + same date = same hexagram every time. Pass any unique identifier (userId, email hash, session token). Omit for anonymous daily readings. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| seed | Yes | |
| lines | Yes | |
| hexagram | No | |
| changingLines | No | |
| resultingHexagram | No | |
| changingLinePositions | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false already in annotations, the description adds valuable behavioral context: seeded randomness means the same seed and date yield the same result, and it discloses what the response contains (line values, changing line positions, resulting hexagram). It does not contradict annotations and supplements the safety profile with determinism and output composition details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences and mostly efficient: it opens with the action and method, then differentiates from the sibling, then notes determinism, and closes with a target use case. While the final sentence ('Perfect for...') is somewhat promotional, it is short and not redundant. Overall it is front-loaded and earns its 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?
Given the presence of a full output schema, all parameter descriptions, and safe annotations, the description covers the essential context an agent needs: what the tool does, when to prefer it, what result to expect, and determinism. It does not need to explain return values or parameter defaults because those are in the schema. It is complete for a read-only oracle tool with optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's only parameter-related statement ('Same seed + same date = same casting result') essentially repeats what the seed parameter's schema description already says ('Same seed + same date = same hexagram every time'). Thus it adds minimal semantic value beyond the structured 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 states a specific verb ('Cast'), a specific resource ('complete daily I-Ching reading'), and the method ('traditional three-coin method'). It explicitly distinguishes itself from the 'simple daily hexagram' sibling by enumerating what makes it different: line values (6-9), changing line positions, and the resulting hexagram. This clearly differentiates it from post_iching_daily and other siblings 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 provides clear usage context by contrasting itself with 'the simple daily hexagram' and positioning itself as the full casting experience. It implicitly advises using this tool when changing lines and transformation are needed, and the simple daily tool when they are not. However, it does not explicitly name the alternative tool or state a direct 'use X instead' condition, 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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
get_iching_hexagrams2 fields changed- added
Input schema / properties / offset / defaultAdded value: +0 - added
Input schema / properties / offset / minimumAdded value: +0
- Changed
post_iching_daily_cast3 fields changed- added
Output schema / properties / hexagram / properties / binaryAdded value: +{ + "type": "string" +} - added
Output schema / properties / hexagram / properties / changingLinesAdded value: +{ + "items": { + "properties": { + "meaning": { + "type": "string" + }, + "position": { + "type": "number" + }, + "text": { + "type": "string" + } + }, + "required": [ + "position", + "text" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / properties / hexagram / requiredPrevious value: -[ - "number", - "symbol", - "chinese", - "english", - "pinyin", - "upperTrigram", - "lowerTrigram", - "judgment", - "image", - "interpretation" -]New value: +[ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "upperTrigram", + "lowerTrigram", + "judgment", + "image", + "interpretation", + "binary" +]
1 tool update
- Changed
get_iching_hexagrams3 fields changed- removed
Input schema / properties / offset / defaultRemoved value: -0 - removed
Input schema / properties / offset / minimumRemoved value: -0 - changed
Input schema / properties / offset / typePrevious value: -[ - "integer", - "null" -]New value: +"integer"
9 tool updates
- Changed
get_iching_cast1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "changingLinePositions": { + "items": { + "type": "number" + }, + "type": "array" + }, + "hexagram": { + "allOf": [ + { + "properties": { + "binary": { + "type": "string" + }, + "changingLines": { + "items": { + "properties": { + "meaning": { + "type": "string" + }, + "position": { + "type": "number" + }, + "text": { + "type": "string" + } + }, + "required": [ + "position", + "text" + ], + "type": "object" + }, + "type": "array" + }, + "chinese": { + "type": "string" + }, + "english": { + "type": "string" + }, + "image": { + "type": "string" + }, + "interpretation": { + "properties": { + "advice": { + "type": "string" + }, + "career": { + "type": "string" + }, + "decision": { + "type": "string" + }, + "general": { + "type": "string" + }, + "love": { + "type": "string" + } + }, + "required": [ + "general", + "love", + "career", + "decision", + "advice" + ], + "type": "object" + }, + "judgment": { + "type": "string" + }, + "lowerTrigram": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "symbol": { + "type": "string" + }, + "upperTrigram": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "binary", + "upperTrigram", + "lowerTrigram", + "judgment", + "image", + "interpretation", + "changingLines" + ], + "type": "object" + }, + {} + ] + }, + "lines": { + "items": { + "type": "number" + }, + "type": "array" + }, + "resultingHexagram": { + "allOf": [ + { + "properties": { + "binary": { + "type": "string" + }, + "changingLines": { + "items": { + "properties": { + "meaning": { + "type": "string" + }, + "position": { + "type": "number" + }, + "text": { + "type": "string" + } + }, + "required": [ + "position", + "text" + ], + "type": "object" + }, + "type": "array" + }, + "chinese": { + "type": "string" + }, + "english": { + "type": "string" + }, + "image": { + "type": "string" + }, + "interpretation": { + "properties": { + "advice": { + "type": "string" + }, + "career": { + "type": "string" + }, + "decision": { + "type": "string" + }, + "general": { + "type": "string" + }, + "love": { + "type": "string" + } + }, + "required": [ + "general", + "love", + "career", + "decision", + "advice" + ], + "type": "object" + }, + "judgment": { + "type": "string" + }, + "lowerTrigram": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "symbol": { + "type": "string" + }, + "upperTrigram": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "binary", + "upperTrigram", + "lowerTrigram", + "judgment", + "image", + "interpretation", + "changingLines" + ], + "type": "object" + }, + {} + ] + }, + "seed": { + "type": "string" + } + }, + "required": [ + "lines", + "changingLinePositions" + ], + "type": "object" +}
- Changed
get_iching_hexagrams1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "hexagrams": { + "items": { + "properties": { + "chinese": { + "type": "string" + }, + "english": { + "type": "string" + }, + "lowerTrigram": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "symbol": { + "type": "string" + }, + "upperTrigram": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "upperTrigram", + "lowerTrigram" + ], + "type": "object" + }, + "type": "array" + }, + "limit": { + "type": "number" + }, + "offset": { + "type": "number" + }, + "total": { + "type": "number" + } + }, + "required": [ + "total", + "limit", + "offset", + "hexagrams" + ], + "type": "object" +}
- Changed
get_iching_hexagrams_lookup1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "binary": { + "type": "string" + }, + "changingLines": { + "items": { + "properties": { + "meaning": { + "type": "string" + }, + "position": { + "type": "number" + }, + "text": { + "type": "string" + } + }, + "required": [ + "position", + "text" + ], + "type": "object" + }, + "type": "array" + }, + "chinese": { + "type": "string" + }, + "english": { + "type": "string" + }, + "image": { + "type": "string" + }, + "interpretation": { + "properties": { + "advice": { + "type": "string" + }, + "career": { + "type": "string" + }, + "decision": { + "type": "string" + }, + "general": { + "type": "string" + }, + "love": { + "type": "string" + } + }, + "required": [ + "general", + "love", + "career", + "decision", + "advice" + ], + "type": "object" + }, + "judgment": { + "type": "string" + }, + "lowerTrigram": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "symbol": { + "type": "string" + }, + "upperTrigram": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "binary", + "upperTrigram", + "lowerTrigram", + "judgment", + "image", + "interpretation", + "changingLines" + ], + "type": "object" +}
- Changed
get_iching_hexagrams_number1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "binary": { + "type": "string" + }, + "changingLines": { + "items": { + "properties": { + "meaning": { + "type": "string" + }, + "position": { + "type": "number" + }, + "text": { + "type": "string" + } + }, + "required": [ + "position", + "text" + ], + "type": "object" + }, + "type": "array" + }, + "chinese": { + "type": "string" + }, + "english": { + "type": "string" + }, + "image": { + "type": "string" + }, + "interpretation": { + "properties": { + "advice": { + "type": "string" + }, + "career": { + "type": "string" + }, + "decision": { + "type": "string" + }, + "general": { + "type": "string" + }, + "love": { + "type": "string" + } + }, + "required": [ + "general", + "love", + "career", + "decision", + "advice" + ], + "type": "object" + }, + "judgment": { + "type": "string" + }, + "lowerTrigram": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "symbol": { + "type": "string" + }, + "upperTrigram": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "binary", + "upperTrigram", + "lowerTrigram", + "judgment", + "image", + "interpretation", + "changingLines" + ], + "type": "object" +}
- Changed
get_iching_hexagrams_random1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "binary": { + "type": "string" + }, + "changingLines": { + "items": { + "properties": { + "meaning": { + "type": "string" + }, + "position": { + "type": "number" + }, + "text": { + "type": "string" + } + }, + "required": [ + "position", + "text" + ], + "type": "object" + }, + "type": "array" + }, + "chinese": { + "type": "string" + }, + "english": { + "type": "string" + }, + "image": { + "type": "string" + }, + "interpretation": { + "properties": { + "advice": { + "type": "string" + }, + "career": { + "type": "string" + }, + "decision": { + "type": "string" + }, + "general": { + "type": "string" + }, + "love": { + "type": "string" + } + }, + "required": [ + "general", + "love", + "career", + "decision", + "advice" + ], + "type": "object" + }, + "judgment": { + "type": "string" + }, + "lowerTrigram": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "symbol": { + "type": "string" + }, + "upperTrigram": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "binary", + "upperTrigram", + "lowerTrigram", + "judgment", + "image", + "interpretation", + "changingLines" + ], + "type": "object" +}
- Changed
get_iching_trigrams1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "total": { + "type": "number" + }, + "trigrams": { + "items": { + "properties": { + "attribute": { + "type": "string" + }, + "binary": { + "type": "string" + }, + "chinese": { + "type": "string" + }, + "english": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "symbol": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "binary", + "attribute" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "total", + "trigrams" + ], + "type": "object" +}
- Changed
get_iching_trigrams_id1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "animal": { + "type": "string" + }, + "attribute": { + "type": "string" + }, + "binary": { + "type": "string" + }, + "bodyPart": { + "type": "string" + }, + "chinese": { + "type": "string" + }, + "direction": { + "type": "string" + }, + "element": { + "type": "string" + }, + "english": { + "type": "string" + }, + "familyMember": { + "type": "string" + }, + "meaning": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "quality": { + "type": "string" + }, + "season": { + "type": "string" + }, + "symbol": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "binary", + "element", + "attribute", + "familyMember", + "direction", + "bodyPart", + "animal", + "season", + "quality", + "meaning" + ], + "type": "object" +}
- Changed
post_iching_daily1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "dailyMessage": { + "type": "string" + }, + "date": { + "type": "string" + }, + "hexagram": { + "properties": { + "chinese": { + "type": "string" + }, + "english": { + "type": "string" + }, + "image": { + "type": "string" + }, + "interpretation": { + "properties": { + "advice": { + "type": "string" + }, + "career": { + "type": "string" + }, + "decision": { + "type": "string" + }, + "general": { + "type": "string" + }, + "love": { + "type": "string" + } + }, + "required": [ + "general", + "love", + "career", + "decision", + "advice" + ], + "type": "object" + }, + "judgment": { + "type": "string" + }, + "lowerTrigram": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "symbol": { + "type": "string" + }, + "upperTrigram": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "upperTrigram", + "lowerTrigram", + "judgment", + "image", + "interpretation" + ], + "type": "object" + }, + "seed": { + "type": "string" + } + }, + "required": [ + "date", + "seed", + "hexagram", + "dailyMessage" + ], + "type": "object" +}
- Changed
post_iching_daily_cast1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "changingLinePositions": { + "items": { + "type": "number" + }, + "type": "array" + }, + "changingLines": { + "items": { + "properties": { + "meaning": { + "type": "string" + }, + "position": { + "type": "number" + }, + "text": { + "type": "string" + } + }, + "required": [ + "position", + "text" + ], + "type": "object" + }, + "type": "array" + }, + "date": { + "type": "string" + }, + "hexagram": { + "properties": { + "chinese": { + "type": "string" + }, + "english": { + "type": "string" + }, + "image": { + "type": "string" + }, + "interpretation": { + "properties": { + "advice": { + "type": "string" + }, + "career": { + "type": "string" + }, + "decision": { + "type": "string" + }, + "general": { + "type": "string" + }, + "love": { + "type": "string" + } + }, + "required": [ + "general", + "love", + "career", + "decision", + "advice" + ], + "type": "object" + }, + "judgment": { + "type": "string" + }, + "lowerTrigram": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "symbol": { + "type": "string" + }, + "upperTrigram": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "upperTrigram", + "lowerTrigram", + "judgment", + "image", + "interpretation" + ], + "type": "object" + }, + "lines": { + "items": { + "type": "number" + }, + "type": "array" + }, + "resultingHexagram": { + "properties": { + "chinese": { + "type": "string" + }, + "english": { + "type": "string" + }, + "image": { + "type": "string" + }, + "interpretation": { + "properties": { + "advice": { + "type": "string" + }, + "career": { + "type": "string" + }, + "decision": { + "type": "string" + }, + "general": { + "type": "string" + }, + "love": { + "type": "string" + } + }, + "required": [ + "general", + "love", + "career", + "decision", + "advice" + ], + "type": "object" + }, + "judgment": { + "type": "string" + }, + "lowerTrigram": { + "type": "string" + }, + "number": { + "type": "number" + }, + "pinyin": { + "type": "string" + }, + "symbol": { + "type": "string" + }, + "upperTrigram": { + "type": "string" + } + }, + "required": [ + "number", + "symbol", + "chinese", + "english", + "pinyin", + "upperTrigram", + "lowerTrigram", + "judgment", + "image", + "interpretation" + ], + "type": "object" + }, + "seed": { + "type": "string" + } + }, + "required": [ + "date", + "seed", + "lines", + "changingLinePositions" + ], + "type": "object" +}
1 tool update
- Changed
get_iching_hexagrams_number1 field changed- changed
Input schema / properties / number / typePrevious value: -"number"New value: +"integer"
9 tool updates
- Changed
get_iching_cast2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
get_iching_hexagrams2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
get_iching_hexagrams_lookup2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
get_iching_hexagrams_number2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
get_iching_hexagrams_random2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
get_iching_trigrams2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
get_iching_trigrams_id2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_iching_daily2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_iching_daily_cast2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
9 tool updates
- Changed
get_iching_cast2 fields changed- added
Input schema / examplesAdded value: +[ + {} +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
get_iching_hexagrams2 fields changed- added
Input schema / examplesAdded value: +[ + {} +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
get_iching_hexagrams_lookup2 fields changed- added
Input schema / examplesAdded value: +[ + { + "lines": "111111" + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
get_iching_hexagrams_number2 fields changed- added
Input schema / examplesAdded value: +[ + { + "number": 1 + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
get_iching_hexagrams_random2 fields changed- added
Input schema / examplesAdded value: +[ + {} +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
get_iching_trigrams2 fields changed- added
Input schema / examplesAdded value: +[ + {} +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
get_iching_trigrams_id2 fields changed- added
Input schema / examplesAdded value: +[ + { + "id": "Heaven" + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_iching_daily2 fields changed- added
Input schema / examplesAdded value: +[ + {} +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_iching_daily_cast2 fields changed- added
Input schema / examplesAdded value: +[ + {} +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
1 tool update
- Changed
get_iching_hexagrams1 field changed- changed
Input schema / properties / offset / typePrevious value: -"integer"New value: +[ + "integer", + "null" +]
9 tool updates
- Changed
get_iching_cast1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
get_iching_hexagrams1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
get_iching_hexagrams_lookup1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
get_iching_hexagrams_number1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
get_iching_hexagrams_random1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
get_iching_trigrams1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
get_iching_trigrams_id1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_iching_daily1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_iching_daily_cast1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
9 tool updates
- Changed
get_iching_cast1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
get_iching_hexagrams1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
get_iching_hexagrams_lookup1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
get_iching_hexagrams_number1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
get_iching_hexagrams_random1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
get_iching_trigrams1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
get_iching_trigrams_id1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_iching_daily1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_iching_daily_cast1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
9 tool updates
- First observed
get_iching_cast - First observed
get_iching_hexagrams - First observed
get_iching_hexagrams_lookup - First observed
get_iching_hexagrams_number - First observed
get_iching_hexagrams_random - First observed
get_iching_trigrams - First observed
get_iching_trigrams_id - First observed
post_iching_daily - First observed
post_iching_daily_cast
Related MCP Connectors
I-Ching (周易) oracle: cast a hexagram, read classical commentary, get a reflection. Bilingual.
Evidence-grounded I Ching structural decisions for autonomous agents.
Divination for AI agents: Hafez, Tarot, I Ching, Runes, Geomancy, and the five-oracle Council.
Kua numbers, Eight Mansions, Flying Star charts and annual afflictions for AI agents.
Related MCP Servers
- AlicenseCqualityCmaintenanceIntegrates I Ching divination with AI responses, allowing users to receive guidance through traditional Chinese philosophy using the bibliomantic approach described in Philip K. Dick's work.42MIT
- AlicenseNot gradedqualityBmaintenanceDivination for AI agents: Hafez, Tarot, I Ching, Runes, and Geomancy. Plus the Pentamancy Council, all five oracles consulted in parallel and synthesized into one unified counsel. For when you need a new perspective on a current problem: a unique and pointed randomness for the stuck ones, genuine guidance for the heavy ones, or plain curiosity about what happens when an AI gets a reading from fiv20 npmMIT
- AlicenseAqualityBmaintenanceEnables AI assistants to analyze I Ching hexagrams and geographic feng shui for Taiwan locations, including business site evaluation and article search.332 npm1MIT
- AlicenseBqualityDmaintenanceProvides traditional Chinese metaphysics analysis capabilities including I Ching divination (hexagram generation and interpretation) and Bazi (Four Pillars) fortune-telling with comprehensive life analysis covering career, wealth, relationships, and health predictions.1028 npm30MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.