AstroWay Divination and esoterica

Bind Rune

astroway_runes_bind_rune

Read-onlyIdempotent

Joins two to four runes on one stave (or the runes whose meanings name an intent), returning each rune with its poem stanza and SVG, the combined strokes as coordinates and a ready SVG of the bind rune.

[Group: Elder Futhark Runes] [Endpoint: POST /v1/runes/bind-rune] [Cost: 10 credits (Tier 1)]

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": "astroway_runes_bind_rune"
  }
}

Input Schema

Name	Required	Description
`runes`	No	Two to four Elder Futhark slugs to bind, e.g. ["algiz", "sowilo"].
`fields`	No	Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response.
`intent`	No	Without runes: a word such as protection, wealth or journey; the runes whose meanings name it are bound (up to three).
`precision`	No	Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn.

Output Schema

Name	Required	Description	Default
`note`	No
`basis`	No
`runes`	No
`intent`	No
`source`	No
`reading`	No
`bindRune`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value with the cost disclosure ('10 credits (Tier 1)') and the endpoint, but the bulk of the remaining text enumerates return payload details that the output schema already carries.

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?

One dense sentence front-loads the action, then the alternate mode, then the return payload; the bracketed group/endpoint/cost lines are compact and scannable. Slight waste in enumerating every return element when an output schema exists.

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

Completeness4/5

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 need not explain return values, and annotations carry the safety semantics, so the definition is close to complete for a 4-parameter, side-effect-free tool. The only meaningful gap is absent guidance about choosing this over sibling rune tools.

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?

Schema description coverage is 100%, so all four parameters are already documented in the schema, including the intent-vs-runes alternative and the 2–4 range. The description's parenthetical restates the intent mode but adds no syntax, format or edge-case meaning beyond the schema, so the baseline of 3 applies.

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?

The description opens with a concrete verb and object: 'Joins two to four runes on one stave', and names the artifact produced (a 'bind rune'). This is unmistakably distinct from the sibling spread tools (astroway_runes_single, _three, _five, _nine) and from astroway_runes_runes, so an agent can pick it without opening the schema.

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

Usage Guidelines3/5

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

Usage is implied through the two modes it sketches (supply `runes`, or supply `intent`), which is genuinely useful context. But it never states when to prefer this tool over the sibling rune tools, nor any exclusion or prerequisite, leaving the agent to infer the call site.

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

All AstroWay Divination and esoterica tools Inspect

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

Need Help?