Skip to main content
Glama
Sign In

I Ching

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Cast I Ching

cast_i_ching
Read-onlyIdempotent

Cast an I Ching hexagram using the traditional three-coin method (default) or the classical yarrow-stalk method, per James Legge's 1899 translation. Generates six line values (6/7/8/9) with the method’s real probabilities (coins: 1/8, 3/8, 3/8, 1/8 for 6/7/8/9; yarrow: 1/16, 5/16, 7/16, 3/16), builds the primary hexagram, lists any changing lines with their texts, and derives the resulting hexagram (null when nothing changes). Pass seed back to replay the exact same cast. The hexagram and line texts are traditional meanings for the calling agent to interpret in light of its own question — this tool does not answer the question itself.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "seed": "pipeworx-iching-smoke-1",
      "method": "coins",
      "question": "Should we ship the chance-pack family?"
    },
    "name": "cast_i_ching"
  }
}

Input Schema

NameRequiredDescriptionDefault
seedNoOptional seed for a reproducible cast. Omit for real randomness; the seed used is always returned so the cast can be replayed.
methodNoDivination method. "coins" (default): three-coin toss, six times. "yarrow": classical yarrow-stalk division, with different (narrower) probabilities.
questionNoOptional question being asked of the oracle. Echoed back verbatim in the result; never interpreted by this tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/destructive/idempotent, but the description adds substantial non-obvious behavior: exact probability distributions per method, the six line values produced, changing-line extraction, the derived hexagram being null when nothing changes, and that the seed is always returned. The only residual oddity is that idempotentHint=true is implicitly reconciled by the seed mechanism rather than stated outright.

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

Conciseness4/5

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

Method choice and defaults are front-loaded, then output shape, then the replay contract, then the interpretation caveat. The parenthetical probability lists are slightly dense but earn their place by justifying the method distinction; no sentence is pure padding.

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

Completeness5/5

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

With no output schema, the description carries the return-shape burden and does so fully: line values, primary hexagram, changing lines with texts, derived hexagram and its null case, and the echoed seed. An agent knows exactly what it will receive and what it must do with it (interpret, not delegate the answer).

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by spelling out the real probability vectors per method and the exact replay semantics of `seed`. That is genuine added meaning rather than restatement.

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

Purpose5/5

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

Opens with a specific verb and resource ('Cast an I Ching hexagram') and immediately pins down the two supported methods. The verb 'cast' inherently distinguishes it from the lookup-oriented siblings get_hexagram and search_hexagrams, so an agent can route correctly without reading the schema.

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

Usage Guidelines4/5

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

States that coins is the default, explains when to use `seed` (replay) vs omit it (real randomness), and carves out an explicit boundary: the tool does not answer the question itself. It stops short of naming the sibling to use when you want to look up an existing hexagram's text, which is the one obvious missing routing hint.

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

All I Ching toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources