Astro Agents - verifiable planetary timing data and astrology

Sky today: retrogrades, Moon phase, next events

sky_today

Read-onlyIdempotent

Astrology sky today (no birth data): planet positions, retrogrades and the Moon phase now, plus the exact times of the next ingresses, Mercury retrograde and other stations, new and full moons and planetary aspects over the coming days. For agents and bots that follow the sky itself (market timing, daily content, alerts): positions with retrograde flags and the Moon's phase and illumination at a moment (default: now, UTC), then every sign ingress, retrograde/direct station, lunation (new, quarter, full) and major aspect between the planets over the next 1-90 days, each to the minute. Tropical or sidereal. Pass 'datetime' for a reproducible call. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.01 per call via REST POST https://astro-agent.dev/v1/western/sky (x402 or MPP); each client gets 1 free call on the $0.01-0.02 tools, this one included.

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

Input Schema

Name	Required	Description	Default
`date`	No	YYYY-MM-DD (use with 'time' instead of 'datetime').
`days`	No	How many days ahead to list events. Example: 30.
`time`	No	HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning).
`options`	No	Optional zodiac settings.
`datetime`	No	Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'.
`latitude`	No	Decimal degrees, north positive.
`timezone`	No	IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date.
`longitude`	No	Decimal degrees, east positive.
`time_basis`	No	What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time.	civil
`ambiguous_time`	No	Which occurrence to use when a local time happens twice (DST fall-back).	earlier

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.1/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, so safety is covered; the description adds real value beyond that — deterministic JPL DE440 computation with no LLM, a per-result meta.result_sha256 for verification, and a $0.01 REST payment requirement (x402 or MPP) plus one free call. It does not describe response size or pagination for the 1-90 day event list, which is the main remaining gap.

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 output scope are front-loaded, and the deterministic/hashing/pricing facts are relevant to an agent. The closing sentence is a dense run-on stacking endpoint, payment rail, price and free-call policy, which could be split for readability but is not wasteful.

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, full parameter coverage and rich annotations, the description only needs to supply the extras and it does: determinism, hash verification, cost, timezone resolution behavior and time basis. Only the shape/size of the returned event list is left unexplained, a minor omission for a 10-parameter tool.

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% with nested options and enum descriptions, so the baseline is 3. The description adds one genuinely new semantic point — passing 'datetime' makes the call reproducible and the default is 'now, UTC' — but defers everything else (timezone resolution, ayanamsa pairing, time_basis) to the schema.

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 and resource — planet positions, retrogrades, Moon phase now, plus exact times of future ingresses/stations/lunations/aspects — and explicitly scopes out birth data, which separates it from natal_chart and similar siblings. An agent can distinguish it from transits or planet_positions without opening either schema.

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 a clear when-to-use context ('For agents and bots that follow the sky itself (market timing, daily content, alerts)') and the 'no birth data' qualifier implicitly routes birth-based questions elsewhere. It never names an alternative sibling such as transits or natal_chart explicitly, so the exclusion is inferential rather than stated.

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.