Skip to main content
Glama

Astro Agents - verifiable planetary timing data and astrology

Sky analogues (matching skies)

sky_analogues
Read-onlyIdempotent

Financial astrology sky analogues (matching skies, planetary cycle analogues): find the past or future dates whose planetary positions best match a reference sky (a moment, now, positions you give, or a birth sky: compare a birth sky to past/future dates), ranked by a stated angular distance, to line up market history (stocks, crypto) with similar skies in a backtest. E.g. {reference: '2026-10-29T00:00Z', direction: 'past', bodies: ['jupiter', 'saturn'], min_separation_days: 3650}. Data only. Matching skies by geometry, data only: give a reference (a UTC moment, 'now', your own positions, or a birth sky: compare a birth sky to past/future dates — data only) and get the dates in a range (past, future or both, 1800-2200, 1h..1w grid) whose sky is closest, ranked by a weighted mean of circular longitude differences (geocentric and/or heliocentric), pair angles (aspects), declination differences and retrograde-flag mismatches, in degrees. Each match gives its date, unix timestamp, score, every body's exact longitude and retrograde flag and each feature's distance, in columns ready for pandas. The metric formula is in the response; the same request returns the same bytes and hash, future dates included. Up to 100 matches and 36,600 candidate dates per call; no market data. Data for your own analysis — 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/analogues (x402 or MPP); always paid, never a free call.

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_analogues"
  }
}

Input Schema

NameRequiredDescriptionDefault
rangeNoCandidate dates. Default (a reference with a time): the longest window the caps allow, up to 100 years in the chosen direction (50 on each side for 'both').
top_nNoHow many matches.
bodiesNoBodies to match. Default: Sun..Pluto (geo), Mercury..Pluto with Earth (helio).
formatNo'columns' (pandas.DataFrame(result['matches'])) or 'rows' (one object per match).columns
optionsNoOptional zodiac settings.
weightsNoOptional {feature id: weight}, default 1 each, e.g. {'geo.jupiter': 2}. Feature ids: '<geo|helio>.<body>' (longitude, 0-360), '<geo|helio>.<a>-<b>:angle' (separation, 0-180), '<geo|helio>.<body>:declination' (degrees) and 'geo.<body>:retrograde' (true/false).
featuresNoWhat to compare: 'longitude' (default), 'aspects' (the angle between every pair of bodies), 'declination', 'retrograde' (geocentric flags, Mercury..Pluto).
directionNoSearch before the reference (a birth: before the birth moment), after it, or both (default; the only choice with reference.values without 'datetime').both
referenceNoThe sky to match: 'now' (default; the current UTC hour or day, echoed in result.reference.date_utc), a UTC moment ('2026-10-29T00:00Z' or 'YYYY-MM-DD'), {datetime: ...}, your own configuration {values: {feature id: value}} (add 'datetime' to anchor direction and range at a time), or a birth sky {birth: {datetime: local '1990-05-15T14:30', latitude, longitude, timezone?}} to compare a birth sky to past/future dates. The birth moment is resolved as in /v1/western/positions (time zone from the coordinates or 'timezone'); a date alone means 12:00 local with a TIME_UNKNOWN warning (the Moon is then approximate, Jupiter..Pluto stay reliable). No houses or ascendant. meta.reference_resolution gives the equivalent {values, datetime} request, which returns the same result and result_sha256. Feature ids: '<geo|helio>.<body>' (longitude, 0-360), '<geo|helio>.<a>-<b>:angle' (separation, 0-180), '<geo|helio>.<body>:declination' (degrees) and 'geo.<body>:retrograde' (true/false).
resolutionNoStep of the candidate grid. At most 36,600 candidate dates per call, and at most 660,000 dates x ephemeris series (one per body and perspective, plus one per retrograde-flagged body).1d
perspectiveNoPositions seen from the Earth, from the Sun, or both.geocentric
max_distanceNoOptional: only matches whose score (degrees) is at most this.
min_separation_daysNoMinimum gap between two matches and between a match and the reference time, so one passage gives one match. Raise it (e.g. 3650) to skip the current cycle of slow planets.
require_same_retrogradeNoKeep only dates whose retrograde flags equal the reference's.

Output Schema

NameRequiredDescriptionDefault
metaNoProvenance of the result.
errorNox402 offer only: why payment is required.
resultNoThe calculation result.
acceptsNox402 offer only: the payment options (scheme, network, amount, asset, payTo, ...).
endpointNoThe REST route that computed it, e.g. 'western/natal'.
resourceNox402 offer only: the resource being paid for.
extensionsNox402 offer only: protocol extensions (bazaar).
x402VersionNox402 offer only: protocol version (2).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • 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"
      -]
  2. Changed5 schema fields changed
    • changedInput schema / properties / direction / description
      Previous value: -"Search before the reference, after it, or both (default; the only choice with reference.values, which has no time)."New value: +"Search before the reference (a birth: before the birth moment), after it, or both (default; the only choice with reference.values without 'datetime')."
    • changedInput schema / properties / range / description
      Previous value: -"Candidate dates. Default (datetime reference only): the longest window the caps allow, up to 100 years in the chosen direction (50 on each side for 'both')."New value: +"Candidate dates. Default (a reference with a time): the longest window the caps allow, up to 100 years in the chosen direction (50 on each side for 'both')."
    • changedInput schema / properties / reference / description
      Previous value: -"The sky to match: 'now' (default; the current UTC hour or day, echoed in result.reference.date_utc), a UTC moment ('2026-10-29T00:00Z' or 'YYYY-MM-DD'), {datetime: ...}, or your own configuration {values: {feature id: value}}. Feature ids: '<geo|helio>.<body>' (longitude, 0-360), '<geo|helio>.<a>-<b>:angle' (separation, 0-180), '<geo|helio>.<body>:declination' (degrees) and 'geo.<body>:retrograde' (true/false)."New value: +"The sky to match: 'now' (default; the current UTC hour or day, echoed in result.reference.date_utc), a UTC moment ('2026-10-29T00:00Z' or 'YYYY-MM-DD'), {datetime: ...}, your own configuration {values: {feature id: value}} (add 'datetime' to anchor direction and range at a time), or a birth sky {birth: {datetime: local '1990-05-15T14:30', latitude, longitude, timezone?}} to compare a birth sky to past/future dates. The birth moment is resolved as in /v1/western/positions (time zone from the coordinates or 'timezone'); a date alone means 12:00 local with a TIME_UNKNOWN warning (the Moon is then approximate, Jupiter..Pluto stay reliable). No houses or ascendant. meta.reference_resolution gives the equivalent {values, datetime} request, which returns the same result and result_sha256. Feature ids: '<geo|helio>.<body>' (longitude, 0-360), '<geo|helio>.<a>-<b>:angle' (separation, 0-180), '<geo|helio>.<body>:declination' (degrees) and 'geo.<body>:retrograde' (true/false)."
    • changedInput schema / properties / reference / examples
      Previous value: -[
      -  "2026-10-29T00:00Z"
      -]New value: +[
      +  "2026-10-29T00:00Z",
      +  {
      +    "birth": {
      +      "datetime": "1990-05-15T14:30",
      +      "latitude": 48.8566,
      +      "longitude": 2.3522
      +    }
      +  }
      +]
    • changedInput schema / properties / reference / oneOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "properties": {
      -      "datetime": {
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "datetime"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "properties": {
      -      "values": {
      -        "additionalProperties": {
      -          "type": [
      -            "number",
      -            "boolean"
      -          ]
      -        },
      -        "type": "object"
      -      }
      -    },
      -    "required": [
      -      "values"
      -    ],
      -    "type": "object"
      -  }
      -]New value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "properties": {
      +      "datetime": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "datetime"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "properties": {
      +      "datetime": {
      +        "type": "string"
      +      },
      +      "values": {
      +        "additionalProperties": {
      +          "type": [
      +            "number",
      +            "boolean"
      +          ]
      +        },
      +        "type": "object"
      +      }
      +    },
      +    "required": [
      +      "values"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "properties": {
      +      "birth": {
      +        "properties": {
      +          "datetime": {
      +            "description": "Local birth time, e.g. '1990-05-15T14:30', or the date alone if the time is unknown.",
      +            "type": "string"
      +          },
      +          "latitude": {
      +            "maximum": 90,
      +            "minimum": -90,
      +            "type": "number"
      +          },
      +          "longitude": {
      +            "maximum": 180,
      +            "minimum": -180,
      +            "type": "number"
      +          },
      +          "timezone": {
      +            "description": "IANA zone, e.g. 'Europe/Paris'; optional with latitude/longitude or an offset in datetime.",
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "datetime"
      +        ],
      +        "type": "object"
      +      }
      +    },
      +    "required": [
      +      "birth"
      +    ],
      +    "type": "object"
      +  }
      +]
  3. Added

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations it discloses determinism (JPL DE440, no LLM), byte-identical repeat requests, meta.result_sha256 on every result, hard caps (100 matches, 36,600 candidate dates), and the paid-API cost model ($0.25 per call, never a free call). It also explains what the response contains, which is exactly the behavioral context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the text repeats itself heavily: 'data only' appears three times, 'matching skies' twice, and the birth-sky parenthetical ('compare a birth sky to past/future dates') is restated verbatim within the same sentence. Several sentences re-list feature ids and limits already covered in the schema, so length is not earning its place.

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 a 14-parameter tool with nested objects and an output schema, the description covers what an agent still needs: determinism and hashing, cost/payment, caps, the 'now' default and its echo in result.reference.date_utc, and the meta.reference_resolution equivalence guarantee. Return-value details are correctly left to the output schema.

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% and the nested reference/weights/options descriptions are already thorough, so the schema does the heavy lifting. The description adds a composed example showing reference/direction/bodies/min_separation_days together for a backtest, but contributes no new syntax or constraints beyond what the schema states, so the baseline 3 applies.

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 verb and resource: 'find the past or future dates whose planetary positions best match a reference sky ... ranked by a stated angular distance.' The scope (1800-2200, 1h..1w grid, up to 100 matches) and the sibling-distinguishing framing ('matching skies' rather than ephemeris lookup or transit events) are explicit, so an agent can tell it apart from transits, planet_positions or sky_today.

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 use case ('to line up market history (stocks, crypto) with similar skies in a backtest') plus a boundary condition ('no market data', 'never a signal or forecast'), and the worked example shows a concrete intended call. It never names an alternative sibling or states when NOT to use this tool, which keeps it below a 5.

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.