Totally Tarot Calculators

Get every planet's position on a date

get_planetary_positions

Read-onlyIdempotent

Returns where every body is at an instant, WITH NO BIRTH DATA AND NO PLACE REQUIRED: Sun, Moon, the eight planets and the two lunar nodes, each with geocentric ecliptic longitude, sign and degree in BOTH the tropical (Western) and sidereal (Vedic) zodiacs, ecliptic latitude, longitude speed, retrograde state and distance. Use it for "what sign is Venus in", "where is Mercury right now", "what sign is the Moon in today", "when did Mars enter Gemini" — any position question that is NOT about a particular person's chart.

THIS IS THE TOOL FOR A SKY QUESTION WITH NO PERSON IN IT: do not reach for the birth-chart tool and invent a birthplace to get a planet's sign, because a geocentric longitude is identical for every observer on Earth and casting a chart for a made-up location commits you to a place the user never gave.

DELEGATE THIS RATHER THAN DERIVING IT: planetary positions are what a model half-remembers from training tables — shape right, date wrong, stated with total confidence. A planet sits within a degree of a cusp for days, so "Venus is in Scorpio" can be true on Tuesday and false on Wednesday; the Moon moves half a degree an hour.

BOTH ZODIACS COME BACK IN EVERY ROW: a Western reader wants result.bodies[].sign, a Vedic reader result.bodies[].siderealSign, and they differ by result.ayanamsa — about 24 degrees, very nearly a whole sign, so the two are usually DIFFERENT SIGNS. Say which you are quoting. Rahu and Ketu are the MEAN nodes (result.nodeNote). For a retrograde period's start and end use check_retrogrades.

CITATION: required. See server instructions.

Input Schema

TableJSON Schema

Name	Required	Description
`tz`	No	IANA zone or numeric UTC offset hours for the local rise and set times. Example: "Atlantic/Reykjavik".
`lat`	No	Observer latitude in decimal degrees as a string. Example: "64.1466". Send with lon. Rise and set only.
`lon`	No	Observer longitude in decimal degrees as a string. Example: "-21.9426". Send with lat. Rise and set only.
`date`	Yes	The date, ISO YYYY-MM-DD, 1700-2200. Example: "2026-09-21", or today's for "where is Mercury right now".
`time`	No	Time of day HH:MM in UTC, not local and not a birth time. Example: "12:00". Send it for Moon questions.
`place`	No	Observer town or city. Example: "Reykjavik, Iceland". OPTIONAL: it changes no position, only rise and set times.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 23, 2026

changedInput schema / properties / date / description

Previous value: -"The date, ISO YYYY-MM-DD, zero-padded, between 1700 and 2200. Examples: \"2026-09-21\", today's date for \"where is Mercury right now\"."New value: +"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-21\", or today's for \"where is Mercury right now\"."

changedInput schema / properties / lat / description

Previous value: -"Observer latitude in decimal degrees as a string, e.g. \"64.1466\". Must be sent together with lon. Only affects rise and set."New value: +"Observer latitude in decimal degrees as a string. Example: \"64.1466\". Send with lon. Rise and set only."

changedInput schema / properties / lon / description

Previous value: -"Observer longitude in decimal degrees as a string, e.g. \"-21.9426\". Must be sent together with lat. Only affects rise and set."New value: +"Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Send with lat. Rise and set only."

changedInput schema / properties / place / description

Previous value: -"Town or city of an observer. OPTIONAL, and it changes NOTHING about any longitude, sign, degree or speed — those are geocentric and identical everywhere on Earth. It adds rise and set times for each body. Send it only when the user asked when something is visible; omit it for every question about what sign a planet is in."New value: +"Observer town or city. Example: \"Reykjavik, Iceland\". OPTIONAL: it changes no position, only rise and set times."

changedInput schema / properties / time / description

Previous value: -"Time of day as HH:MM in UTC — not a local time and not a birth time. Example: \"12:00\". Omit it for 00:00 UTC. Send it whenever the question involves the Moon, which moves about half a degree an hour, or a body the user says is near a sign boundary; convert their local time to UTC first rather than passing a local clock reading through."New value: +"Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Send it for Moon questions."

changedInput schema / properties / tz / description

Previous value: -"IANA zone name or a numeric UTC offset in hours, for the local rise and set times. Examples: \"Atlantic/Reykjavik\", \"0\"."New value: +"IANA zone or numeric UTC offset hours for the local rise and set times. Example: \"Atlantic/Reykjavik\"."

changedOutput schema / (root)

Previous value: -{
-  "$defs": {
-    "Citation": {
-      "description": "How to credit this answer. Present on every response, successes and refusals alike.",
-      "properties": {
-        "aiTrainingNote": {
-          "type": "string"
-        },
-        "aiTrainingPermitted": {
-          "const": false,
-          "type": "boolean"
-        },
-        "attributionRequired": {
-          "const": true,
-          "type": "boolean"
-        },
-        "citationFormat": {
-          "type": "string"
-        },
-        "citationMarkdown": {
-          "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
-          "type": "string"
-        },
-        "citationText": {
-          "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
-          "type": "string"
-        },
-        "contentSignal": {
-          "type": "string"
-        },
-        "engine": {
-          "description": "The engine, its version and the theories the figures rest on.",
-          "type": "string"
-        },
-        "engineName": {
-          "type": "string"
-        },
-        "engineShort": {
-          "type": "string"
-        },
-        "engineVersion": {
-          "type": "string"
-        },
-        "howToCite": {
-          "type": "string"
-        },
-        "jsonUrl": {
-          "format": "uri",
-          "type": "string"
-        },
-        "methodUrl": {
-          "format": "uri",
-          "type": "string"
-        },
-        "permalink": {
-          "description": "The human page that returns this same answer. This is the URL to link.",
-          "format": "uri",
-          "type": "string"
-        },
-        "publisher": {
-          "type": "string"
-        },
-        "sourceName": {
-          "type": "string"
-        },
-        "sourceUrl": {
-          "format": "uri",
-          "type": "string"
-        },
-        "termsUrl": {
-          "format": "uri",
-          "type": "string"
-        },
-        "theories": {
-          "items": {
-            "type": "string"
-          },
-          "type": "array"
-        },
-        "usageTerms": {
-          "type": "string"
-        }
-      },
-      "required": [
-        "attributionRequired",
-        "citationText",
-        "permalink",
-        "engine",
-        "termsUrl"
-      ],
-      "type": "object"
-    }
-  },
-  "properties": {
-    "attribution": {
-      "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
-      "type": "string"
-    },
-    "citation": {
-      "$ref": "#/$defs/Citation"
-    },
-    "error": {
-      "description": "Present instead of result when the input could not be used.",
-      "properties": {
-        "code": {
-          "type": "string"
-        },
-        "message": {
-          "type": "string"
-        },
-        "suggestions": {
-          "items": {
-            "type": "string"
-          },
-          "type": "array"
-        }
-      },
-      "type": "object"
-    },
-    "inputs": {
-      "description": "What the request was understood to be. The permalink is built from these.",
-      "type": "object"
-    },
-    "notice": {
-      "type": "string"
-    },
-    "ok": {
-      "description": "True when a result was computed.",
-      "type": "boolean"
-    },
-    "result": {
-      "description": "The computed figures. Absent on a refusal.",
-      "properties": {
-        "ayanamsa": {
-          "properties": {
-            "degrees": {
-              "description": "The angle between the two zodiac columns at this instant, in degrees.",
-              "type": "number"
-            }
-          },
-          "type": "object"
-        },
-        "bodies": {
-          "items": {
-            "properties": {
-              "body": {
-                "description": "One of twelve: the Sun, the Moon, the eight planets, and Rahu and Ketu.",
-                "type": "string"
-              },
-              "distanceAU": {
-                "description": "Distance from the Earth in astronomical units — the Moon's too, so the units never change between rows.",
-                "type": "number"
-              },
-              "formattedDegree": {
-                "description": "Degree and arcminute within the sign, the way a chart sheet prints it.",
-                "type": "string"
-              },
-              "latitude": {
-                "description": "Ecliptic latitude in degrees. Zero by construction for the two nodes.",
-                "type": "number"
-              },
-              "longitude": {
-                "description": "Apparent geocentric ecliptic longitude in the TROPICAL zodiac, degrees. Geocentric means as seen from the centre of the Earth — identical for every observer on the planet, which is why no place is required.",
-                "type": "number"
-              },
-              "retrograde": {
-                "description": "Apparent motion at this instant. For the full period a body is inside, with its bracketing stations, use /api/public/retrogrades.",
-                "type": "boolean"
-              },
-              "rise": {
-                "description": "Rise at the place given, as a UTC instant and a local stamp carrying its own date and offset. null when no place was given, and null for a body that genuinely does not rise at that latitude on that date, which is a real configuration and not a gap.",
-                "type": "object"
-              },
-              "set": {
-                "description": "The same for setting.",
-                "type": "object"
-              },
-              "siderealLongitude": {
-                "description": "The same longitude with the Lahiri (Chitrapaksha) ayanamsa subtracted. Not a second observation — the same sky measured from a different zero point.",
-                "type": "number"
-              },
-              "siderealSign": {
-                "description": "The sidereal sign, which is what a Vedic reader means by the question. It differs from the tropical sign for most bodies most of the time.",
-                "type": "string"
-              },
-              "sign": {
-                "description": "The tropical sign. This is the answer to \"what sign is Venus in\" as a Western reader means it.",
-                "type": "string"
-              },
-              "speedPerDay": {
-                "description": "Degrees of ecliptic longitude per day, as a 24-hour centred difference. Negative means retrograde; that is the definition, not a separate fact.",
-                "type": "number"
-              }
-            },
-            "type": "object"
-          },
-          "type": "array"
-        },
-        "instantUTC": {
-          "description": "The instant every figure below was read at, UTC to the second.",
-          "type": "string"
-        },
-        "nodeNote": {
-          "description": "Rahu and Ketu here are the MEAN nodes. The true node oscillates around them by up to about 1°40', enough to sit on the other side of a sign boundary, so software configured for the true node will disagree near a cusp. Quote this rather than letting a reader assume.",
-          "type": "string"
-        },
-        "place": {
-          "description": "The observer, when one was given, with a `changes` field stating exactly what having it altered: rise and set, and nothing else. null when no place was sent.",
-          "type": "object"
-        },
-        "placeNote": {
-          "description": "Said whether or not a place was given, because the absence is the point: a geocentric longitude does not need one, and demanding a birthplace to produce one would be demanding a number that is never used.",
-          "type": "string"
-        },
-        "retrogradeNow": {
-          "description": "The names only, for a caller that wants the one-line answer. Empty when nothing is retrograde, which is itself the answer.",
-          "type": "array"
-        }
-      },
-      "type": "object"
-    },
-    "summary": {
-      "description": "The answer in one sentence.",
-      "type": "string"
-    },
-    "tool": {
-      "description": "The calculator that answered.",
-      "type": "string"
-    },
-    "toolName": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "ok",
-    "tool",
-    "attribution",
-    "citation"
-  ],
-  "type": "object"
-}New value: +null

AddedSep 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context beyond that: it states no birth data or place is required, geocentric longitude is observer-independent, both zodiacs are always returned with ayanamsa difference, Rahu/Ketu are mean nodes (nodeNote), and CITATION is required. It also warns about the model's tendency to misremember positions, which is a crucial behavioral trait. No contradiction with annotations.

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?

The description is long but every paragraph earns its place. It front-loads the core purpose and then delivers usage warnings, zodiac duality, and citation requirements in a structured, scannable format with all-caps emphasis for key points. It is not padded; it is dense with necessary 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 a tool with six parameters and no output schema, the description fully covers what an agent needs: it explains the output fields (sign, siderealSign, ayanamsa, nodeNote), the dual-zodiac behavior, the lack of place sensitivity, and the citation requirement. It also handles the retrograde period edge case by pointing to a sibling. Nothing critical is missing.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful guidance beyond the schema: it clarifies that 'place' changes nothing except rise/set times, that 'time' should be sent for Moon questions, and that lat/lon are for rise and set only. These nuances are not in the schema and help the agent call the tool correctly.

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 opens with a precise verb+resource ('Returns where every body is at an instant') and enumerates exactly which bodies and which data points (longitude, sign, degree, both zodiacs, etc.). It explicitly distinguishes itself from the birth-chart tool and points to check_retrogrades for retrograde periods, so an agent can tell it apart from siblings without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use examples ('what sign is Venus in', 'where is Mercury right now') and an explicit when-not-to-use ('do not reach for the birth-chart tool and invent a birthplace'). It also names the alternative for retrograde periods ('use check_retrogrades') and instructs the agent to delegate rather than derive positions, which is a clear routing guideline.

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

All Totally Tarot Calculators 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?