Skip to main content
Glama

Cazimi: retrograde planets

Void-of-course Moon periods

void_of_course
Read-onlyIdempotent

Every void-of-course Moon period between two dates (up to 62 days): start (the Moon's last exact Ptolemaic aspect to the Sun or a planet in its sign), end (entry into the next sign), length in hours, the last aspect and the signs. Computed live from the ephemeris (astronomy-engine, about 1′), tropical zodiac on the true ecliptic of date, geocentric, UTC. Astronomical positions only, no interpretation. Paid tool: $0.01 per call in USDC on Base via x402 (HTTP 402 with payment requirements; retry with a PAYMENT-SIGNATURE header). Free tools cover the current status and the next retrograde.

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

Input Schema

NameRequiredDescriptionDefault
toNoRange end, YYYY-MM-DD (end of day) or ISO UTC. Defaults to 14 days after from.
fromNoRange start, YYYY-MM-DD (start of day) or ISO UTC. Defaults to now.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world; the description goes far beyond that with computation provenance (ephemeris, astronomy-engine, ~1′ accuracy), coordinate conventions (tropical zodiac, true ecliptic of date, geocentric, UTC), and an explicit no-interpretation caveat. Critically, it discloses the paid x402 flow including the $0.01 USDC/Base price and the PAYMENT-SIGNATURE retry mechanism, which an agent cannot infer from any structured field.

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?

Front-loaded with the returned fields, then the computation conventions, then the payment mechanics — a sensible order with no filler sentences. It is dense and slightly long as a single unbroken paragraph, but every clause carries information an agent needs.

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 compensates by enumerating every returned field. Combined with the range cap, timezone convention, and payment protocol, an agent has everything required to decide, call, and handle a 402 response correctly.

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 the baseline is 3. The description adds one genuinely new constraint not present in the schema — the 62-day maximum span — but does not explain the from/to default interaction or the date-vs-ISO granularity beyond what the parameter descriptions already say.

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 resource (void-of-course Moon periods) with a concrete scope (between two dates, up to 62 days) and enumerates exactly what is returned (start, end, length in hours, last aspect, signs). This is clearly distinguishable from siblings like moon_now or moon_calendar, which the description implicitly contrasts by calling out the free-status alternative.

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?

Gives practical usage context: the 62-day range cap, the default window behavior, and a pointer that free tools cover current status and the next retrograde, which helps an agent decide when the paid call is warranted. It stops short of naming the exact sibling tools to use for adjacent needs (e.g., moon phases vs. retrograde dates), so routing is inferred rather than explicit.

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