Skip to main content
Glama

AstroWay Divination and esoterica

Amissio: Loss

astroway_geomancy_amissio
Read-onlyIdempotent

Loss, letting go, slipping away.

[Group: Geomancy (Agrippa)] [Endpoint: POST /v1/geomancy/amissio] [Cost: 10 credits (Tier 1)]

Input Schema

NameRequiredDescriptionDefault
fieldsNoCompact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response.
precisionNoCompact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn.

Output Schema

NameRequiredDescriptionDefault
figureNo
sourceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuine behavioral context the annotations lack: the POST /v1/geomancy/amissio endpoint and the cost of 10 credits (Tier 1), which lets an agent budget calls.

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

Conciseness3/5

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

The description is short and front-loads the figure's meaning, with endpoint and cost in bracketed tags at the end. It wastes no words, but it is under-specified rather than concise — there is no wasted text because there is barely any text.

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

Completeness3/5

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

An output schema exists, so return values need not be described, and the 100% schema coverage handles parameters. What is missing is the operational framing — what the call actually produces for a geomancy figure and when it is the right figure to request — leaving a simple lookup tool only minimally complete.

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 coverage is 100% and both parameters (fields, precision) are fully documented in the schema itself. The description adds nothing about parameters, so the baseline 3 applies — the schema does all the work.

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

Purpose3/5

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

The description gives the figure's gloss ('Loss, letting go, slipping away') but never states the operation — there is no verb such as 'retrieve' or 'interpret'. An agent can infer this returns the Amissio geomancy figure's reading and can distinguish it from siblings like astroway_geomancy_acquisitio by the meaning gloss, but the purpose remains implied rather than stated.

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

Usage Guidelines2/5

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance anywhere in the description. With 15 sibling geomancy figure tools plus other divination systems, nothing tells the agent how to pick Amissio over the other figures.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources