Skip to main content
Glama
Bibliomantic MCP Server

Bibliomantic MCP Server

by d4nshields

Cast a hexagram

cast_hexagram
Read-only

Casts a fresh I Ching hexagram with the three-coin method, returning tosses, line values, primary and transformed hexagrams, and changing lines for interpretation.

Instructions

Consult the I Ching once with the three-coin method.

    Returns the full record of the cast: the six coin tosses, the line values
    (6, 7, 8, 9), the primary hexagram with its complete text, the changing lines,
    and the transformed hexagram if any lines change. Every call casts fresh coins.
    Interpreting the result for the user's situation is up to you.
    

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cast_hexagram"
  }
}

Input Schema

NameRequiredDescriptionDefault
questionNoThe user's question, echoed back verbatim. Optional; the server never reads or analyses it.

Output Schema

NameRequiredDescriptionDefault
noticeYes
tossesYesSix tosses, bottom line first.
valuesYesLine values 6/7/8/9, bottom line first.
primaryYes
questionYesEchoed verbatim. The server never analyses it.
transformedYesPrimary with changing lines flipped.
changing_linesYesPositions whose value is 6 or 9.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint false), so the description adds the genuinely non-obvious traits: every call produces fresh random coins with no caching, and interpretation is the caller's responsibility, not the server's. It doesn't mention rate limits or any cost per cast, but the core behavioral quirks are disclosed.

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

Conciseness5/5

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

Front-loads the action and method in the first sentence, then enumerates the return contents and closes with the division of responsibility. Every sentence carries information an agent needs; there is no filler.

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?

A zero-required-parameter tool with a full output schema, so return shape is already structured, yet the description still tells the agent the result is non-deterministic and that interpretation falls to the agent. Nothing needed to invoke or use the result correctly is missing.

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

Parameters3/5

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

The single optional 'question' parameter is fully documented in the schema at 100% coverage, including the key fact that the server echoes it verbatim and never analyses it. The description adds nothing about it, which is acceptable given the schema already carries the meaning, but no extra value is provided.

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?

States a specific verb-plus-resource (cast a hexagram) plus the exact method (three-coin), which clearly separates it from the sibling get_hexagram that only retrieves an existing hexagram. An agent can tell what this produces 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.

Usage Guidelines4/5

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

Says to consult the I Ching 'once' and that every call casts fresh coins, which implies this is the entry point rather than a lookup, and that repeat calls are not idempotent reads. It never explicitly names get_hexagram or describe_method as alternatives or states when-not-to-use, so exclusivity is inferable rather than stated.

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