I Ching Hexagram MCP
Server Details
Public, read-only MCP over the complete 64-hexagram I Ching corpus. Deterministic lookup only.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 10 of 10 tools scored.
Each tool serves a distinct purpose: single vs batch vs bulk retrieval, reading context, trigrams, sequences, search, and server info. No overlap or ambiguity.
All tools follow a consistent verb_noun snake_case pattern (get_, list_, search_), making the tool set predictable and easy to navigate.
10 tools is well-scoped for a domain-specific reference server. Each tool covers a necessary operation without bloat or deficiency.
The tool surface covers retrieval, listing, search, reading context, trigrams, and sequences. Minor gaps like a random hexagram tool are non-essential for a deterministic reference dataset.
Available Tools
10 toolsget_all_hexagramsGet All HexagramsARead-onlyIdempotentInspect
The full 64-hexagram dataset in one call (bulk; stricter rate limit). Optional order: kingwen (default), mawangdui, eightpalaces, binary. Data © IChing.Rocks — attribution is a condition of the license terms: https://iching.rocks/mcp-terms.
| Name | Required | Description | Default |
|---|---|---|---|
| order | No | Ordering: kingwen | mawangdui | eightpalaces | binary. Default kingwen. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| order | No | |
| source | No | |
| hexagrams | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the safety profile is clear. The description adds value by disclosing the stricter rate limit and the required attribution per license terms, which are beyond annotation capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by parameter options and legal note. Every sentence earns its place, no waste.
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 existence of an output schema (not shown but indicated), the description adequately covers the tool's behavior, parameter, and important constraints (rate limit, attribution). Complete for a bulk retrieval 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 100% — the schema already documents the parameter with allowed values and default. The description repeats this information without adding new meaning, so it meets baseline expectations but does not exceed.
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 it returns 'the full 64-hexagram dataset in one call' with a specific verb and resource, and distinguishes itself from siblings like get_hexagram (single) or search_hexagrams (search) by emphasizing bulk retrieval and stricter rate limit.
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 use when needing all hexagrams, with a note on stricter rate limit, but does not explicitly compare to alternatives or state when not to use. Context from sibling names provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hexagramGet HexagramARead-onlyIdempotentInspect
One hexagram by King Wen number (1-64). Optional include level: summary, core (default), lines, full. Sibling tools cover the other cases: get_hexagrams for several numbers at once, get_all_hexagrams for the entire set, search_hexagrams to find hexagrams by text, and get_reading_context for a changing-line reading. Data © IChing.Rocks — attribution is a condition of the license terms: https://iching.rocks/mcp-terms.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Hexagram number, 1-64 (King Wen). | |
| include | No | Detail level, each nesting the previous: summary = identity, essence, url; core (default) = adds trigrams, judgment, image; lines = adds the six line texts; full = adds symbolic meaning and final comment. | core |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| name | No | |
| image | No | |
| lines | No | |
| binary | No | |
| pinyin | No | |
| source | No | |
| essence | No | |
| hex_font | No | |
| judgment | No | |
| trad_chinese | No | |
| final_comment | No | |
| trigram_above | No | |
| trigram_below | No | |
| symbolic_meaning | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the description adds context about data attribution and license terms, but no further behavioral traits.
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: first covers core purpose and parameter info, second lists siblings and attribution. Every sentence earns its place; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema, so return value explanation not needed. Description covers purpose, parameters, usage guidance, and attribution, making it complete for a read-only tool with good annotations.
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 baseline is high. The description adds value by explaining that include levels nest progressively (summary, core, lines, full).
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 retrieves one hexagram by King Wen number (1-64), with specific verb and resource. It also distinguishes itself from sibling tools by listing 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?
Explicit guidance on when to use this tool versus alternatives, listing get_hexagrams, get_all_hexagrams, search_hexagrams, and get_reading_context for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hexagramsGet Hexagrams (Batch)ARead-onlyIdempotentInspect
Batch hexagram lookup by King Wen numbers (max 16 ids per call). Optional include level: summary, core (default), lines, full. Data © IChing.Rocks — attribution is a condition of the license terms: https://iching.rocks/mcp-terms.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Hexagram numbers, 1-64 (King Wen), no duplicates, max 16 per call. | |
| include | No | Detail level, each nesting the previous: summary = identity, essence, url; core (default) = adds trigrams, judgment, image; lines = adds the six line texts; full = adds symbolic meaning and final comment. | core |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| source | No | |
| hexagrams | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint true, so the description does not need to repeat these. The description adds value by specifying the maximum ID limit and the data attribution/license condition, which are behavioral constraints beyond what annotations provide. 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 concise, consisting of three sentences. The first sentence front-loads the primary purpose and constraint (batch lookup, max 16). The second covers the optional parameter. The third adds a necessary legal note. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It adequately covers the tool's purpose, constraints, optional parameters, and legal attribution requirement. It is complete for a simple batch lookup tool, especially with the support of annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with detailed descriptions for both parameters (ids and include). The description briefly summarizes the include levels but does not add significant new meaning beyond the schema. The max 16 constraint is already in the schema's ids description. Thus, the description adds marginal value.
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 'Batch hexagram lookup by King Wen numbers' with a maximum of 16 IDs, distinguishing it from the sibling tool 'get_hexagram' (singular) and 'get_all_hexagrams' (all hexagrams). The verb 'lookup' is specific and the resource is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for batch lookups of multiple hexagrams. It explicitly states the maximum of 16 IDs, implying that for more than 16, one should use alternative tools. However, it does not explicitly state when not to use it or mention alternatives, but the sibling tool names provide implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reading_contextGet Reading ContextARead-onlyIdempotentInspect
Deterministic reading context for a primary hexagram (1-64) and 0-6 ascending changing lines. Empty changing_lines returns the primary hexagram only; one or more changing lines add the resulting hexagram, the transition, and the changing-line texts. No divination is performed. Data © IChing.Rocks — attribution is a condition of the license terms: https://iching.rocks/mcp-terms.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Detail level, each nesting the previous: summary = identity, essence, url; core (default) = adds trigrams, judgment, image; lines = adds the six line texts; full = adds symbolic meaning and final comment. | core |
| primary_id | Yes | Primary hexagram number, 1-64 (King Wen). | |
| changing_lines | Yes | Changing line numbers (1-6), strictly ascending, no duplicates. Empty for an unchanging reading. |
Output Schema
| Name | Required | Description |
|---|---|---|
| source | No | |
| primary | No | |
| resulting | No | |
| transition | No | |
| final_comment | No | |
| changing_line_texts | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds that the tool is deterministic and does not perform divination, reinforcing safety. It also discloses licensing and attribution requirements, which are behavioral constraints beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose and inputs, second explains behavior (empty vs non-empty changing_lines) and legal terms. No superfluous words; critical information 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?
Given the complexity (3 parameters, detail levels, output schema), the description covers all essential aspects: inputs, behavior, legal terms, and determinism. The presence of an output schema means return values don't need elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial context: 'changing_lines' must be strictly ascending, no duplicates, and empty returns only the primary hexagram. It explains the nesting behavior of the 'include' parameter with levels summary, core, lines, full. This significantly enhances understanding beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Deterministic reading context for a primary hexagram and 0-6 ascending changing lines.' It specifies the verb ('get'), resource ('reading context'), and inputs, distinguishing it from siblings by emphasizing 'deterministic' and 'no divination.'
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 says 'No divination is performed,' guiding agents to use it for deterministic lookups, not random readings. It also mentions attribution as a condition of license terms. However, it does not explicitly contrast with siblings like 'get_hexagram' or 'search_hexagrams,' which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_server_infoGet Server InfoARead-onlyIdempotentInspect
Build identity of the running iching.rocks MCP server: name, semantic version, git revision, protocol, and canonical MCP endpoint. Identity only — returns no hexagram data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | |
| version | No | |
| protocol | No | |
| git_revision | No | |
| mcp_endpoint | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds context that it returns identity only and no hexagram data, reinforcing safety and clarifying 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?
Two sentences, minimal and front-loaded, no extraneous information; every word 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 zero parameters and an existing output schema, the description fully covers what the tool does and what it returns, leaving no ambiguity.
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?
No parameters exist, so baseline of 4 applies; description does not need to add parameter details.
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?
Clearly states the tool builds identity of the server with specific fields (name, version, revision, protocol, endpoint) and explicitly says it returns no hexagram data, distinguishing it from all sibling tools which are hexagram-related.
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?
Implicitly guides when to use by specifying it returns identity only and no hexagram data, but does not explicitly state when not to use or name alternatives, though siblings are all distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trigramGet TrigramARead-onlyIdempotentInspect
One of the eight trigrams by exactly one identifier: binary (e.g. 010), english (e.g. Fire), chinese (pinyin, e.g. Li), symbolic (e.g. Radiance), or element (Chinese character, e.g. 火). This returns a single trigram; list_trigrams returns all eight. Data © IChing.Rocks — attribution is a condition of the license terms: https://iching.rocks/mcp-terms.
| Name | Required | Description | Default |
|---|---|---|---|
| binary | No | Three-bit trigram binary, e.g. 010 (canonical identifier). | |
| chinese | No | Pinyin romanization, e.g. Li. (This field holds pinyin; the Chinese character lives in element.) | |
| element | No | Chinese element character, e.g. 火. | |
| english | No | English name, e.g. Fire. | |
| symbolic | No | Symbolic name, e.g. Radiance. |
Output Schema
| Name | Required | Description |
|---|---|---|
| font | No | |
| binary | No | |
| source | No | |
| chinese | No | |
| element | No | |
| english | No | |
| function | No | |
| symbolic | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true, so the tool is safe and idempotent. The description adds important behavioral context: the data comes from IChing.Rocks with an attribution requirement and a link to license terms. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each densely packed with information. No wasted words; the first sentence states the core functionality, and the second adds necessary legal context. Ideal conciseness.
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 (not shown but in context), the description does not need to explain return values. It covers the tool's purpose, usage distinction, identifier constraints, and attribution requirement. Fully complete for an easy-to-use, safe 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 100% with descriptions for each parameter. The description adds crucial semantic information: exactly one identifier must be provided, and it clarifies that the 'chinese' field holds pinyin while 'element' holds the Chinese character. This goes 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 clearly states the tool returns one of the eight trigrams by specifying a single identifier (binary, english, etc.) and explicitly distinguishes itself from list_trigrams, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly tells when to use this tool (for a single trigram) and when to use the sibling list_trigrams (for all eight). However, it does not explicitly state when not to use it, but that's sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_hexagramsList HexagramsARead-onlyIdempotentInspect
Compact index of all 64 I Ching hexagrams (id, name, pinyin, characters, essence, trigrams, url). Optional order: kingwen (default), mawangdui, eightpalaces, binary. This is the summary index only; get_hexagram (or get_hexagrams) returns full detail for a known number, get_all_hexagrams returns the full dataset in one call, and search_hexagrams finds hexagrams by text. Data © IChing.Rocks — attribution is a condition of the license terms: https://iching.rocks/mcp-terms.
| Name | Required | Description | Default |
|---|---|---|---|
| order | No | Ordering: kingwen | mawangdui | eightpalaces | binary. Default kingwen. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| order | No | |
| source | No | |
| hexagrams | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds essential behavioral context including the compact nature of the response, optional ordering, and the attribution/license requirement, which go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose and output fields, and efficiently distinguishes from siblings and notes license in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set, output schema presence, and multiple sibling tools, the description fully covers what an agent needs to understand the tool's purpose, usage, and constraints, including licensing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no new information about the 'order' parameter beyond what is in the schema, such as valid values and default. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a compact index of all 64 I Ching hexagrams with specific fields, and explicitly distinguishes itself from sibling tools like get_hexagram, get_all_hexagrams, and search_hexagrams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives, stating it is a summary index and naming specific alternatives for full detail, full dataset, and text search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sequencesList SequencesARead-onlyIdempotentInspect
Describes the four canonical hexagram orderings (kingwen, mawangdui, eightpalaces, binary) with their 64-entry sequences. Data © IChing.Rocks — attribution is a condition of the license terms: https://iching.rocks/mcp-terms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| source | No | |
| sequences | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds meaningful behavioral context: the data source (IChing.Rocks), attribution requirement, and license terms link. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second adds attribution and license terms. No wasted words; efficiently front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and existence of output schema, the description fully covers the tool's function. It names the four orderings and notes license terms, providing enough context for 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?
No parameters exist, so description does not need to add parameter-level information. Schema coverage is 100% (none). Baseline 4 is appropriate; description adds no param info but none is needed.
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 describes four canonical hexagram orderings with their 64-entry sequences. The verb 'describes' and specific resource 'four canonical hexagram orderings' distinguish it from siblings like list_hexagrams or list_trigrams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs the sequences of hexagram orderings, but does not explicitly state when to use this tool versus alternatives like list_hexagrams or search_hexagrams. Context makes it clear, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_trigramsList TrigramsARead-onlyIdempotentInspect
All eight trigrams with font, binary, pinyin, symbolic name, english name, element character, and function. Data © IChing.Rocks — attribution is a condition of the license terms: https://iching.rocks/mcp-terms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| source | No | |
| trigrams | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds value by disclosing the data source and attribution requirements (license terms), which is important behavioral context.
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?
Single concise sentence with essential purpose, followed by necessary license attribution. No wasted words, front-loaded with core functionality.
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 no parameters and the presence of an output schema, the description fully explains what the tool returns and mentions license conditions. It is complete for this simple 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?
No parameters exist, so schema coverage is 100% trivially. Description does not need to add parameter details. Baseline score of 4 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?
Description clearly states it lists all eight trigrams with specific attributes. The tool name and title match. It is distinct from sibling tools like 'get_trigram' which retrieves a single trigram.
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?
Description implies listing all trigrams, but lacks explicit guidance on when to use this versus alternatives like get_trigram. However, context from sibling tools makes the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_hexagramsSearch HexagramsARead-onlyIdempotentInspect
Deterministic literal/keyword search over a closed whitelist of hexagram text fields (not semantic). Case-, diacritic-, and traditional/simplified Chinese-insensitive. Optional fields, order, and limit (default 10, max 64). Texts are an original IChing.Rocks translation; vocabulary from classic English translations (Wilhelm/Baynes, Legge, Blofeld) may not match literally. Data © IChing.Rocks — attribution is a condition of the license terms: https://iching.rocks/mcp-terms.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-64. Default 10. | |
| order | No | Ordering: kingwen | mawangdui | eightpalaces | binary. Default kingwen. | |
| query | Yes | Literal text to match (max 200 chars). Case-, diacritic-, and traditional/simplified Chinese-insensitive. | |
| fields | No | Whitelisted field paths to search; defaults to the documented default set. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| limit | No | |
| order | No | |
| query | No | |
| fields | No | |
| source | No | |
| results | No | |
| total_matches | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds extensive behavioral details beyond the annotations: case-/diacritic-/Chinese-insensitivity, optional fields/order/limit with defaults, translation source, and license requirements. The annotations only state readOnlyHint and idempotentHint, which the description supports. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core concept. It packs essential details efficiently, though the license attribution information might feel secondary for tool selection but is important for legal compliance.
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 an output schema present, the description does not need to explain return values. It covers search behavior, parameter details (limits, insensitivity), and legal/license context. This is sufficiently complete for an agent to decide to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for all 4 parameters. The description adds meaningful value by clarifying the default limit (10), max limit (64), the literal nature of the query, and that fields are optional. This goes beyond the schema, but the schema is already quite descriptive.
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 it is a 'deterministic literal/keyword search' over a closed whitelist of hexagram text fields, and explicitly notes it is not semantic. This distinguishes it from sibling tools like get_hexagram or list_hexagrams which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (for literal search, not semantic) and details about search behavior. However, it does not explicitly state when not to use it or mention alternatives, though the sibling names imply different tools for retrieving full hexagram data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!