Cazimi: retrograde planets

Chart for a moment and place

natal_chart

Read-onlyIdempotent

Chart geometry for a birth or event moment at a place: planets and North Node with sign, degree, speed, retrograde flag and house; Ascendant and Midheaven; twelve house cusps (Placidus by default, or whole-sign or equal; whole-sign above 66° latitude); and the Ptolemaic aspects within orb (8°, sextile 6°, +2° for Sun and Moon). The caller converts local birth time to UTC first. No interpretation. 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.02 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

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "datetime": "<datetime>",
      "lat": "<lat>",
      "lon": "<lon>"
    },
    "name": "natal_chart"
  }
}

Input Schema

Name	Required	Description
`lat`	Yes	Latitude in degrees, north positive
`lon`	Yes	Longitude in degrees, east positive
`houses`	No	House system, default placidus
`datetime`	Yes	Moment in UTC, ISO 8601, e.g. 1990-06-15T10:30:00Z

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description wisely spends its space on traits annotations cannot express: computation source (astronomy-engine, ~1′ accuracy), frame conventions (tropical, true ecliptic of date, geocentric, UTC), the whole-sign fallback above 66° latitude, and the x402 payment flow ($0.02/call, HTTP 402, retry with PAYMENT-SIGNATURE). The pricing and payment-retry behavior is critical and appears nowhere in structured fields.

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?

Purpose and return contents are front-loaded in one dense sentence, followed by preconditions, computation provenance, and pricing in a logical order. The only waste is the near-duplicate 'No interpretation.' and 'Astronomical positions only, no interpretation.', which say the same thing twice.

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?

There is no output schema, and the description compensates by enumerating every returned component and its fields, plus accuracy, zodiac frame, and house-system behavior. For a paid, four-parameter tool it also covers the payment handshake that an agent must handle to call it successfully, leaving nothing material unstated.

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 adds real meaning beyond the schema: house systems are Placidus by default with whole-sign forced above 66° latitude, and datetime must already be UTC rather than local. Aspect orbs (8°, 6° for sextile, +2° for Sun/Moon) are output-affecting parameters that the schema does not expose at all.

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 opening clause names a specific resource ('chart geometry for a birth or event moment at a place') and then enumerates exactly what is returned: planets and Node with sign/degree/speed/retrograde/house, Ascendant and Midheaven, twelve cusps, and Ptolemaic aspects within orb. This clearly separates it from siblings like planet_positions and moon_now, which cover narrower slices of the same data.

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?

It gives a concrete precondition ('the caller converts local birth time to UTC first') and steers simple queries elsewhere with 'Free tools cover the current status and the next retrograde.' It does not name a specific sibling or state explicit exclusions (e.g. 'do not use for historical ephemeris ranges'), so it stops short of full routing guidance.

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

All Cazimi: retrograde planets 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?