Astro Agents - verifiable planetary timing data and astrology

Token launch sky (crypto token chart)

token_chart

Read-onlyIdempotent

Crypto token launch sky (token astrology chart, data only): the planets' signs, degrees, retrogrades and aspects at a token's launch moment (block time of its deployment or mint), plus the exact UTC dates ahead when planets return to or aspect those positions (key astronomical dates, unix timestamps for backtests) and a shareable SVG card. E.g. {launch_datetime: '2018-08-03T19:28:24Z', token: {symbol: 'USDC'}, from: '2026-11-01'}. Give a token's launch moment (the block time of its contract deployment or mint, UTC, to the second) and get the geocentric sky at that instant: each planet's sign, degree, longitude and retrograde flag, the major aspects between them, element and modality balance (no houses: a token has no place). Then the key dates: the exact UTC minute, over up to 366 days from 'from', at which each transiting planet returns to its launch position or aspects a launch position, each with a unix timestamp and a stable key, in rows ready for pandas. result.card.svg is a server-rendered 1200x675 card (wheel, positions, next key dates) ready to post. Key astronomical dates, data only — never a signal or forecast. 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/token-chart (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": {
      "launch_datetime": "<launch_datetime>"
    },
    "name": "token_chart"
  }
}

Input Schema

Name	Required	Description
`card`	No	Include the shareable SVG card (result.card.svg).
`days`	No	How many days of key dates from 'from'.
`from`	No	First UTC date of the key dates, YYYY-MM-DD. Default: today (UTC); pass it for a reproducible call. Example: '2026-11-01'.
`limit`	No	Maximum key dates returned (counts.key_dates gives the total).
`token`	No	Optional label drawn on the card and echoed in the result. On-chain resolution of the launch time is not available yet: give launch_datetime.
`options`	No	Optional zodiac and aspect settings.
`transit_bodies`	No	Transiting bodies timed against the launch positions (default all nine).
`launch_datetime`	Yes	The token's launch moment in UTC: ISO 8601 with Z or an offset, to the second ('2018-08-03T19:28:24Z'), or unix seconds (an on-chain block time). Use the block time of the contract deployment or of the mint, from an explorer.

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 30, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses determinism (JPL DE440, no LLM), hash verification via meta.result_sha256, the exact pricing model ($0.25 per call, always paid, never free), payment mechanisms (x402 or MPP), and the REST endpoint. It also describes the card output (server-rendered 1200x675) and the pandas-ready row shape, which the annotations cannot convey.

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 core purpose is front-loaded and every block is relevant, but the prose is dense and repetitive: 'key astronomical dates' appears twice, the title concept is restated, and long parenthetical chains make it slow to scan for an agent parsing quickly.

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?

For a complex 8-parameter tool with nested objects, the description covers the input contract, output shape (rows, card.svg, result_sha256), pricing, and payment path. Since an output schema exists, return values need not be spelled out further; only error/rate-limit behavior is unaddressed.

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; the description earns a bump by showing a composed example ({launch_datetime, token:{symbol}, from}) and by clarifying intent behind the knobs — geocentric only, no houses, transits timed against launch positions with unix timestamps and stable keys. It still doesn't explain limit/card/days behavior beyond what the schema already states.

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 description names a specific verb and resource — the geocentric sky (planet signs, degrees, retrogrades, aspects) at a token's deployment/mint block time, plus forward transit dates and an SVG card. It is clearly distinguishable from siblings like natal_chart, transits, and token_synastry because the token-launch anchoring and 'no houses: a token has no place' framing are explicit.

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 concrete usage context: supply launch_datetime from an explorer's block time, pass 'from' for reproducibility, and it warns on-chain resolution of launch time is 'not available yet'. It also sets expectations that this is 'data only — never a signal or forecast'. It stops short of naming which sibling to use for alternative questions (e.g. token_synastry or transits).

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.