Astro Agents - verifiable planetary timing data and astrology

Eclipse & Mercury retrograde calendar (market timing)

astro_event_calendar

Read-onlyIdempotent

Financial astrology event calendar for backtesting and trading bots (stocks, crypto, forex): the exact UTC minute and unix timestamp of every eclipse, Mercury retrograde and other station, ingress, new and full moon, planetary aspect, declination parallel and out-of-bounds between two dates, 1800-2200, each with a stable key to join on candles. E.g. {start: '2024-01-01', end: '2024-12-31', include: ['eclipse', 'station']}. A reproducible calendar of celestial events for backtests and alerts, historical or future: sign ingresses, retrograde/direct stations, new/full/quarter moons, solar eclipses (total, annular, hybrid, partial, with gamma) and lunar eclipses (with magnitudes), aspects between planets, declination parallels / contra-parallels and out-of-bounds crossings. Up to 366 days per call, geocentric or heliocentric, tropical or sidereal, Moon optional. Each event has exact_utc, a unix 'timestamp' to join on candle times and a stable 'key' for de-duplication across pages. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.25 per call via REST POST https://astro-agent.dev/v1/finance/events (x402 or MPP); always paid, never a free call.

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": {
      "start": "<start>",
      "end": "<end>"
    },
    "name": "astro_event_calendar"
  }
}

Input Schema

Name	Required	Description	Default
`end`	Yes	Last UTC date, YYYY-MM-DD, at most 366 days after start (inclusive).
`start`	Yes	First UTC date, YYYY-MM-DD, 1800..2199. Example: '2024-01-01'.
`bodies`	No	Planets searched. Default: Sun..Pluto (geo), Mercury..Pluto with Earth (helio).
`aspects`	No	Aspects timed between planets. Default: the 5 majors.
`include`	No	Event types to return. Default: all that apply to the perspective.
`options`	No	Optional zodiac settings.
`perspective`	No	Heliocentric gives ingresses and aspects only (no stations, lunations, eclipses).	geocentric
`include_moon`	No	Also the Moon's ingresses, aspects, parallels and out-of-bounds (geocentric; many events).

Output Schema

Name	Required	Description
`meta`	No	Provenance of the result.
`error`	No	x402 offer only: why payment is required.
`result`	No	The calculation result.
`accepts`	No	x402 offer only: the payment options (scheme, network, amount, asset, payTo, ...).
`endpoint`	No	The REST route that computed it, e.g. 'western/natal'.
`resource`	No	x402 offer only: the resource being paid for.
`extensions`	No	x402 offer only: protocol extensions (bazaar).
`x402Version`	No	x402 offer only: protocol version (2).

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 3, 2026

addedOutput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "endpoint",
+      "result",
+      "meta"
+    ]
+  },
+  {
+    "required": [
+      "x402Version",
+      "accepts"
+    ]
+  }
+]

addedOutput schema / properties / accepts

Added value: +{
+  "description": "x402 offer only: the payment options (scheme, network, amount, asset, payTo, ...).",
+  "items": {
+    "type": "object"
+  },
+  "minItems": 1,
+  "type": "array"
+}

addedOutput schema / properties / error

Added value: +{
+  "description": "x402 offer only: why payment is required.",
+  "type": "string"
+}

addedOutput schema / properties / extensions

Added value: +{
+  "description": "x402 offer only: protocol extensions (bazaar).",
+  "type": "object"
+}

addedOutput schema / properties / resource

Added value: +{
+  "description": "x402 offer only: the resource being paid for.",
+  "type": "object"
+}

addedOutput schema / properties / x402Version

Added value: +{
+  "description": "x402 offer only: protocol version (2).",
+  "type": "integer"
+}

removedOutput schema / required

Removed value: -[
-  "endpoint",
-  "result",
-  "meta"
-]

AddedOct 29, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive, but the description adds material behavior beyond them: mandatory payment ($0.25, REST POST to a named endpoint, x402/MPP, 'never a free call'), determinism via JPL DE440 with meta.result_sha256, stable keys for de-duplication across pages, and the perspective restriction that heliocentric returns ingresses/aspects only. These are exactly the facts an agent needs before spending money on a call.

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 critical facts (date range, joinable timestamps, cost) are front-loaded, but the middle is heavily redundant: the event-type list is enumerated twice in near-identical wording, and the 'stable key for de-duplication' idea is restated three times. Tightening would cut roughly a third of the text without losing information.

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?

For an 8-parameter tool with nested options, an output schema and paid access, the description supplies everything an agent needs: cost and access method, determinism and verifiability signal, per-call size limit, perspective caveat about suppressed event types, and a worked request example. Nothing decision-relevant is left unstated.

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 schema already documents every field including defaults, enums and ranges; baseline 3 applies. The description echoes a few parameters (include example array, 366-day window, Moon optional, geocentric/heliocentric, tropical/sidereal) but adds no syntax or interaction detail beyond what the schema states, such as how `ayanamsa` behaves when zodiac=tropical.

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 concrete verb+resource: an event calendar returning exact UTC minute, unix timestamp and a join key for eclipses, stations, ingresses, lunations, aspects, declinations and out-of-bounds crossings within a date range. The scope (1800-2200, per-date-range batch, joinable to candles) clearly separates it from point-in-time siblings like `sky_today`, `transits` or `aspects`.

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?

Usage context is explicit: backtesting, trading bots, alerts, historical or future, max 366 days per call, always paid at $0.25. What's missing is any explicit routing versus overlapping siblings (`aspects`, `transits`, `planet_positions`) — the agent must infer that a bounded date-range calendar is this tool's job rather than a single-moment query.

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

All Astro Agents - verifiable planetary timing data and astrology 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.