# Totally Tarot Calculators (remote · totallytarot.net)

Astrology charts, Maya calendar and tarot maths, computed on real engines, cited in every answer.

- Trust score: 71/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-28

## Components

- remote · `totallytarot.net`: 71/100 (this document), [markdown](https://verifymcp.io/servers/net-totallytarot-calculators/totallytarot.md), [page](https://verifymcp.io/servers/net-totallytarot-calculators/totallytarot)

## Channel facts

- Endpoint: `https://totallytarot.net/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-28.

- **Endpoint Security**: 80/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 61/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6396 tokens (~533/item across 12 items; 12 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability check failed: schema churn in the 7 days we've observed: 0 tool removals, 8 breaking changes, 0 auth/transport breaks, 4 additions.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 12 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the Totally Tarot Calculators MCP server?

Totally Tarot Calculators is a hosted endpoint at https://totallytarot.net/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http net-totallytarot-calculators 'https://totallytarot.net/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "net-totallytarot-calculators": {
      "url": "https://totallytarot.net/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "net-totallytarot-calculators": {
      "type": "http",
      "url": "https://totallytarot.net/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.net-totallytarot-calculators]
url = "https://totallytarot.net/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "net-totallytarot-calculators": {
      "type": "remote",
      "url": "https://totallytarot.net/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add net-totallytarot-calculators --url 'https://totallytarot.net/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  net-totallytarot-calculators:
    url: "https://totallytarot.net/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "net-totallytarot-calculators": {
      "Transport": "http",
      "Url": "https://totallytarot.net/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add net-totallytarot-calculators -t streamable-http -u 'https://totallytarot.net/mcp'
```

### Other

```json
{
  "mcpServers": {
    "net-totallytarot-calculators": {
      "type": "http",
      "url": "https://totallytarot.net/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-28 (score 71, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-25 (score 71, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-24 (score 71, −1)

- [security regression] Stability: 0.07 → fail
- [security regression] A breaking change shipped without a version bump: still 1.0.0
- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “check_retrogrades” rewrote its description, which is the text the model reads
- [security] Tool “compute_birth_chart” rewrote its description, which is the text the model reads
- [security] Tool “compute_maya_day_sign” rewrote its description, which is the text the model reads
- [security] Tool “compute_moon_phase” rewrote its description, which is the text the model reads
- [security] Tool “compute_panchang” rewrote its description, which is the text the model reads
- [security] Tool “compute_tarot_birth_card” rewrote its description, which is the text the model reads
- [security] Tool “compute_transits” rewrote its description, which is the text the model reads
- [security] Tool “compute_vimshottari_dasha” rewrote its description, which is the text the model reads
- [security] Tool “convert_calendar_date” rewrote its description, which is the text the model reads
- [security] Tool “find_eclipses” rewrote its description, which is the text the model reads
- [security] Tool “get_planetary_positions” rewrote its description, which is the text the model reads
- [functional regression] Tool “check_retrogrades” dropped its output schema
- [functional regression] Tool “compute_birth_chart” dropped its output schema
- [functional regression] Tool “compute_maya_day_sign” dropped its output schema
- [functional regression] Tool “compute_moon_phase” dropped its output schema
- [functional regression] Tool “compute_panchang” dropped its output schema
- [functional regression] Tool “compute_tarot_birth_card” dropped its output schema
- [functional regression] Tool “compute_transits” dropped its output schema
- [functional regression] Tool “compute_vimshottari_dasha” dropped its output schema
- [functional regression] Tool “convert_calendar_date” dropped its output schema
- [functional regression] Tool “find_eclipses” dropped its output schema
- [functional regression] Tool “get_planetary_positions” dropped its output schema
- [functional improvement] Schema quality: 1176 → 533
- [functional] New tool “resolve_utc_offset”
- [cosmetic] “check_retrogrades” reworded the description of “date”
- [cosmetic] “check_retrogrades” reworded the description of “time”
- [cosmetic] “compute_birth_chart” reworded the description of “date”
- [cosmetic] “compute_birth_chart” reworded the description of “lat”
- [cosmetic] “compute_birth_chart” reworded the description of “lon”
- [cosmetic] “compute_birth_chart” reworded the description of “place”
- [cosmetic] “compute_birth_chart” reworded the description of “time”
- [cosmetic] “compute_birth_chart” reworded the description of “tz”
- [cosmetic] “compute_maya_day_sign” reworded the description of “date”
- [cosmetic] “compute_moon_phase” reworded the description of “date”
- [cosmetic] “compute_moon_phase” reworded the description of “time”
- [cosmetic] “compute_moon_phase” reworded the description of “to”
- [cosmetic] “compute_panchang” reworded the description of “date”
- [cosmetic] “compute_panchang” reworded the description of “lat”
- [cosmetic] “compute_panchang” reworded the description of “lon”
- [cosmetic] “compute_panchang” reworded the description of “place”
- [cosmetic] “compute_panchang” reworded the description of “tz”
- [cosmetic] “compute_tarot_birth_card” reworded the description of “date”
- [cosmetic] “compute_transits” reworded the description of “at”
- [cosmetic] “compute_transits” reworded the description of “date”
- [cosmetic] “compute_transits” reworded the description of “lat”
- [cosmetic] “compute_transits” reworded the description of “lon”
- [cosmetic] “compute_transits” reworded the description of “on”
- [cosmetic] “compute_transits” reworded the description of “place”
- [cosmetic] “compute_transits” reworded the description of “time”
- [cosmetic] “compute_transits” reworded the description of “tz”
- [cosmetic] “compute_vimshottari_dasha” reworded the description of “asof”
- [cosmetic] “compute_vimshottari_dasha” reworded the description of “date”
- [cosmetic] “compute_vimshottari_dasha” reworded the description of “lat”
- [cosmetic] “compute_vimshottari_dasha” reworded the description of “lon”
- [cosmetic] “compute_vimshottari_dasha” reworded the description of “place”
- [cosmetic] “compute_vimshottari_dasha” reworded the description of “time”
- [cosmetic] “compute_vimshottari_dasha” reworded the description of “tz”
- [cosmetic] “convert_calendar_date” reworded the description of “date”
- [cosmetic] “convert_calendar_date” reworded the description of “from”
- [cosmetic] “convert_calendar_date” reworded the description of “jdn”
- [cosmetic] “convert_calendar_date” reworded the description of “julian”
- [cosmetic] “convert_calendar_date” reworded the description of “longcount”
- [cosmetic] “convert_calendar_date” reworded the description of “round”
- [cosmetic] “convert_calendar_date” reworded the description of “to”
- [cosmetic] “find_eclipses” reworded the description of “count”
- [cosmetic] “find_eclipses” reworded the description of “date”
- [cosmetic] “find_eclipses” reworded the description of “family”
- [cosmetic] “find_eclipses” reworded the description of “lat”
- [cosmetic] “find_eclipses” reworded the description of “lon”
- [cosmetic] “find_eclipses” reworded the description of “place”
- [cosmetic] “find_eclipses” reworded the description of “tz”
- [cosmetic] “get_planetary_positions” reworded the description of “date”
- [cosmetic] “get_planetary_positions” reworded the description of “lat”
- [cosmetic] “get_planetary_positions” reworded the description of “lon”
- [cosmetic] “get_planetary_positions” reworded the description of “place”
- [cosmetic] “get_planetary_positions” reworded the description of “time”
- [cosmetic] “get_planetary_positions” reworded the description of “tz”

### 2026-09-23 (score 72, +3)

- [security improvement] HSTS header: fail → pass

### 2026-09-22 (score 69, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “compute_birth_chart” rewrote its description, which is the text the model reads
- [security] Tool “compute_panchang” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 986 → 1176
- [functional improvement] Stability: unverified → 0.03
- [functional] New tool “compute_transits”
- [functional] New tool “compute_vimshottari_dasha”
- [functional] New tool “get_planetary_positions”

### 2026-09-21 (score 68)

First indexed and scored.

## MCP tools (12)

### `compute_birth_chart` (~439 tokens)

Cast a natal birth chart

Casts a natal chart: every planet's sign and exact degree in BOTH the tropical/Western and sidereal/Vedic (Lahiri) zodiacs, the ascendant, the twelve Placidus cusps, the midheaven, retrograde state and the Moon's nakshatra. Use it for anyone's chart, rising sign, Moon sign or planet-in-house. Send a birth date (1800-2200) and a place.

DELEGATE THIS RATHER THAN DERIVING IT: this needs an ephemeris at one exact UTC instant, so it needs the zone offset in force AT THAT PLACE ON THAT DATE, often not today's — East Tennessee kept Central time until 1947 — and an hour's error moves the ascendant 15 degrees, usually into another sign, with the houses following. Wrong values look exactly like right ones. IF THE BIRTH TIME IS UNKNOWN OMIT "time", never noon or midnight: the ascendant, cusps and houses are then withheld rather than guessed.

CITATION: required. See server instructions.

Input parameters:

- `date` (string, required): Birth date, ISO YYYY-MM-DD, 1800-2200. Example: "1977-10-19". "19/10/1977" is refused, not guessed.
- `lat` (string): Latitude in decimal degrees as a string. Example: "39.76838". Send with lon.
- `lon` (string): Longitude in decimal degrees as a string. Example: "-86.15804". Send with lat.
- `place` (string): Town or city of birth with region and country. Example: "Indianapolis, Indiana, United States". A bare "Springfield" is refused with candidates.
- `time` (string): Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: "23:58". OMIT if unknown; never send "12:00".
- `tz` (string): IANA zone or numeric UTC offset hours. Example: "America/Indiana/Indianapolis" or "-5". Omit: resolved for the BIRTH date.

### `compute_maya_day_sign` (~292 tokens)

Convert a date to the Maya calendars

Converts a Gregorian date to the Maya calendars: Tzolk'in day sign and tone as written (e.g. "6 Oc"), kin 1-260, the sign's meaning, direction and position in the twenty, its trecena, the Haab date, the Long Count, the Julian Day Number. Use it for a Maya day sign, a Mayan birth sign, a Tzolk'in or Haab date, a Long Count, or a historical event's Maya date.

DELEGATE THIS RATHER THAN DERIVING IT: four moduli over a continuous day count with no lookup shortcut — Julian Day Number, minus a correlation constant, then remainders mod 20, 13, 260 and 365 — exact integer arithmetic over six-digit numbers, where an off-by-one yields a real day sign that is simply the wrong one. There is also no "the" Maya date without naming a correlation constant, WHICH CONSTANT IS THE OPEN ARGUMENT in Maya calendrics, so this uses Goodman-Martinez-Thompson 584283 and returns it. The count ignores time of day, birthplace and time zone.

CITATION: required. See server instructions.

Input parameters:

- `date` (string, required): Gregorian date to convert, ISO YYYY-MM-DD, year 1-4000, proleptic before 1582. Example: "2012-12-21".

### `compute_tarot_birth_card` (~285 tokens)

Work out a tarot birth card

Reduces a birth date to its tarot birth card by the Chaldean destiny-number rule, returning the card, its Roman numeral, and every line of the arithmetic as labelled steps. Use it for a tarot birth card, birth card, life card or destiny card. Date alone decides it.

DELEGATE THIS RATHER THAN DERIVING IT: the rule is short enough to look safe and has one trap regularly fallen into — sum the year's digits to one digit, add day and month number, reduce the same way, BUT THE REDUCTION HALTS ON 11, 22 AND 33, read through their roots 2, 4 and 6. 1993's digits sum to 22 and stop there, so reducing from 4 instead reaches a different card, and with only nine answers a wrong one looks right. Root 8 is Strength in the Rider-Waite-Smith numbering used here, Justice in Marseille packs.

WORTH SAYING: this is a twentieth-century convention appearing in no early tarot source. https://totallytarot.net/library/policy/method

CITATION: required. See server instructions.

Input parameters:

- `date` (string, required): Birth date, ISO YYYY-MM-DD. Example: "1994-06-05" (reduces to 7, The Chariot). Time and place change nothing.

### `convert_calendar_date` (~550 tokens)

Convert a date between calendars

Converts between the Gregorian calendar, the Julian calendar, the Julian Day Number and the three Maya counts (Tzolk'in, Haab, Long Count) — any one to all the others — and searches a year range for a given Calendar Round. Use it for a Long Count from an inscription, a pre-1582 Julian-dated document, a Julian Day Number from a table, or "when was 4 Ahau 3 Kankin". Send EXACTLY ONE starting point — a Gregorian date, a jdn, a longcount or a julian date, or a round with from and to. Two is refused, not answered from whichever came first.

DELEGATE THIS RATHER THAN DERIVING IT, AND THERE IS A MEASUREMENT FOR HOW BADLY IT GOES: arXiv:2511.09993 put frontier models at 34.5% accuracy on calendar conversion across six calendars, against 95.3% for the same models given a tool. One off-by-one in a chain of six-digit integer steps yields a date that is real, plausible and wrong. Two traps: the calendars diverge by a different number of days each century (ten at the 1582 reform, thirteen now), and pre-reform dates are routinely quoted as Julian without saying so. This states the Goodman-Martinez-Thompson constant 584283 it used.

CITATION: required. See server instructions.

Input parameters:

- `date` (string): A proleptic Gregorian date, ISO YYYY-MM-DD. Example: "2012-12-21". Send exactly ONE of date, jdn, longcount, julian.
- `from` (string): First Gregorian year of a Calendar Round search. Example: "1900". Only with round and to.
- `jdn` (string): Julian Day Number as a whole count of days. Example: "2456283". Not a fractional Julian Date.
- `julian` (string): A date in the JULIAN calendar, ISO YYYY-MM-DD. Example: "1582-10-04". Use it for sources before October 1582.
- `longcount` (string): Maya Long Count, five dot-separated places baktun.katun.tun.uinal.kin. Example: "9.12.11.5.18".
- `round` (string): Calendar Round to search: tone, day sign, haab day, haab month. Example: "4 Ahau 3 Kankin". Needs from and to.
- `to` (string): Last Gregorian year of a Calendar Round search. Example: "2100". A wider span is slower, not better.

### `compute_panchang` (~496 tokens)

Read the panchang for a date and place

Computes the panchang — the five limbs of the Hindu almanac — for one civil date at one place: tithi, nakshatra with pada, yoga and karana, EACH CARRYING THE EXACT UTC AND LOCAL INSTANTS IT BEGINS AND ENDS, plus vara, sunrise, sunset, day length, and the lunar month in both amanta and purnimanta reckonings. Use it for the tithi, a day's nakshatra, when a nakshatra or yoga ends, an ekadashi or purnima, or "today's panchang in <city>". The four end times are usually what the user actually wants, and a name alone never gives them.

DELEGATE THIS RATHER THAN DERIVING IT: a tithi is not a day but the interval in which the Moon gains another twelve degrees on the Sun, running 20-26.8 hours (mean 23.6) from any clock time. WHICH CIVIL DAY IT NAMES is set by reading the tithi running AT THAT PLACE'S OWN SUNRISE, so one date's published panchang differs by a whole tithi between two cities — an answer derived without a place is not weaker, it is a different day's. Nakshatra about 20.8 to 27.2 hours, yoga about 19.5 to 25.2 hours, karana about 10 to 13.4 hours. A latitude with no sunrise that day is refused, not approximated.

CITATION: required. See server instructions.

Input parameters:

- `date` (string, required): Local civil date at the place, ISO YYYY-MM-DD, 1700-2200. Example: "2026-09-20".
- `lat` (string): Latitude in decimal degrees as a string. Example: "28.6139". Send with lon.
- `lon` (string): Longitude in decimal degrees as a string. Example: "77.209". It sets the sunrise the whole panchang is read at.
- `place` (string): Town or city with region or country. Example: "Chennai, Tamil Nadu, India". REQUIRED unless lat and lon are sent; an ambiguous name is refused with candidates.
- `tz` (string): IANA zone or numeric UTC offset hours, for printing local times only. Example: "Asia/Kolkata".

### `compute_moon_phase` (~367 tokens)

Get the Moon's phase and the lunation's exact times

Returns the Moon's phase for an exact instant — phase angle, illuminated fraction, the eight-fold name, waxing or waning, age in days, tropical sign and degree, distance — with the four principal phases of that lunation to the second in UTC, and optionally every principal phase across a date range. Use it for the phase on a date, the next full or new moon, the Moon's age or sign, or a year's full moons.

DELEGATE THIS RATHER THAN DERIVING IT: the commonly reproduced method, days since a remembered new moon divided by 29.53, uses a MEAN synodic month while the real one varies by up to about thirteen hours either side, and the error is largest exactly where it matters — the quarter or full moon somebody is about to put in a calendar. Phase names are defined by Moon-Sun elongation, not even eighths of a cycle. This searches astronomy-engine (ELP, VSOP87) for the true instants. Phase changes measurably within a day, so send the user's hour as UTC rather than taking the 00:00 default.

CITATION: required. See server instructions.

Input parameters:

- `date` (string, required): The date, ISO YYYY-MM-DD, 1700-2200. Example: "2026-09-20". Covers the lunation it falls inside.
- `time` (string): Time of day HH:MM in UTC, not local and not a birth time. Example: "12:00". Omit for 00:00 UTC.
- `to` (string): End of a range, ISO YYYY-MM-DD, up to 400 days after date. Example: "2026-12-31". Lists every principal phase between.

### `find_eclipses` (~482 tokens)

Find the eclipses near a date

Finds the solar and lunar eclipses nearest a date: greatest eclipse to the second in UTC, type (total, annular, partial, penumbral), obscuration, the eclipsed body's sign, days from the date asked about, and for a solar eclipse where greatest eclipse meets the Earth. Given a place, each listing ALSO carries what that observer gets — local kind, first contact, maximum, last contact, and altitude at each. Use it for the next eclipse, eclipses near a historical date, or visibility from a place.

DELEGATE THIS RATHER THAN DERIVING IT, ESPECIALLY THE VISIBILITY HALF: the 6,585.3-day saros puts eclipses in families easy to confuse by a year or a continent, but the failure that matters is subtler — A GLOBAL ECLIPSE IS NOT AN EVENT FOR EVERYBODY. Telling somebody a thousand miles off the path that there is a total solar eclipse is a sentence in which every word is true and the meaning is false. This separates global circumstances from local ones, including cases a bare "visible" hides: the Moon setting partway through, or the eclipse already underway at moonrise.

CITATION: required. See server instructions.

Input parameters:

- `count` (string): How many per side of the date, "1" to "12", default "3". Example: "1". Ask for what you will use.
- `date` (string, required): The date to search AROUND, ISO YYYY-MM-DD, 1700-2200. Example: "2026-08-12". Need not be an eclipse date.
- `family` (string): Which eclipses to list: "both" (the default), "lunar" or "solar".
- `lat` (string): Observer latitude in decimal degrees as a string. Example: "64.1466". Send with lon.
- `lon` (string): Observer longitude in decimal degrees as a string. Example: "-21.9426". Send with lat.
- `place` (string): Observer town or city. Example: "Reykjavik, Iceland". Adds the local kind, contact times and altitudes.
- `tz` (string): IANA zone or numeric UTC offset hours for the local contact times. Example: "Atlantic/Reykjavik".

### `check_retrogrades` (~355 tokens)

Check which planets are retrograde, and until when

Reports which planets are retrograde on a date and — the part worth calling for — the two stations that OPEN AND CLOSE the period each body is in, so the answer is not "yes" but "since 2026-02-14, until 2026-03-07". Per body: the retrograde flag, ecliptic longitude, longitude speed, sign and degree, and both bracketing stations with exact UTC instants. Use it for Mercury retrograde, whether a planet is retrograde on a date, or when a period starts or ends.

DELEGATE THIS RATHER THAN DERIVING IT: retrograde motion is apparent, not real, so the dates move every cycle, follow no rule and are not reliably memorised — Mercury alone turns three or four times a year and those dates get confidently misremembered by a week. A station is where longitude speed crosses zero, found by bisecting astronomy-engine's speed for eight bodies; expect it slower and dearer than the others here.

DELIBERATELY EXCLUDED: the Sun and Moon, neither of which can station, and Rahu and Ketu, which move backwards every day of their existence. The "excluded" array gives the reasons; quote it rather than reporting an absence.

CITATION: required. See server instructions.

Input parameters:

- `date` (string, required): The date, ISO YYYY-MM-DD, 1700-2200. Example: "2026-03-01". The stations returned bracket this date.
- `time` (string): Time of day HH:MM in UTC, not local and not a birth time. Example: "12:00". Matters within a day of a station.

### `compute_vimshottari_dasha` (~614 tokens)

Compute a Vimshottari dasha timeline

Computes the Vimshottari dasha timeline from a birth date, time and place: all nine mahadashas of the 120-year cycle, EACH WITH THE EXACT INSTANT IT OPENS AND CLOSES, the BALANCE AT BIRTH in years, months and days, the Moon's nakshatra and pada that fix the sequence, and the nine antardashas inside whichever mahadasha you name. Send "asof" to mark the periods running on a given date; this never reads the clock, so answers stay citable at a stable URL.

DELEGATE THIS RATHER THAN DERIVING IT, AND KNOW THAT DERIVING IT FAILS SILENTLY: the table hangs off ONE number you cannot estimate, the Moon's SIDEREAL longitude at the birth instant. A tenth of a degree moves the balance by weeks and every later boundary with it; a few degrees changes which planet the cycle opens with. The failure is not a refusal but a complete, plausible, nine-row table wrong in a way no reader can see.

"time" IS REQUIRED HERE, AND DO NOT INVENT A BIRTH TIME OR SEND NOON: the Moon covers about 13.2 degrees a day against a nakshatra 13 degrees 20 minutes wide, so an unknown birth time is an unknown FIRST LORD, not an imprecise balance. Without it this returns a "time_required" refusal.

Three CONVENTIONS, not facts, come back in the result and are where two programs disagree about one chart: result.ayanamsa, result.yearLengthDays, result.origin.utcInstant. Against Drik Panchang every boundary here falls 1.70 days earlier. Quote those fields and result.conventionNote rather than calling either table wrong.

CITATION: required. See server instructions.

Input parameters:

- `asof` (string): Date to mark the active mahadasha and antardasha for. Example: today's date for "which dasha am I in now".
- `date` (string, required): Birth date, ISO YYYY-MM-DD, 1800-2200. Example: "1977-10-19". "19/10/1977" is refused, not guessed.
- `lat` (string): Birth latitude in decimal degrees as a string. Example: "39.76838". Send with lon.
- `lon` (string): Birth longitude in decimal degrees as a string. Example: "-86.15804". Send with lat.
- `place` (string, required): Town or city of birth with region or country. Example: "Chennai, India". An ambiguous name is refused with candidates.
- `time` (string, required): Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: "23:58". REQUIRED: never invent one, never send noon.
- `tz` (string): IANA zone or numeric UTC offset hours for the BIRTH moment. Example: "-5". Omit: resolved historically.

### `compute_transits` (~669 tokens)

Find the transits to a birth chart on a date

Computes where the sky is on a chosen date against where it was at somebody's birth: ten transiting bodies with longitude, sign, degree, speed and retrograde state, and EVERY ASPECT they make to the natal planets and angles — each with its orb, the orb allowed, the natal longitude measured against, and whether the contact is APPLYING or SEPARATING. Use it for what is transiting a chart, whether a transit is active on a date, a Saturn return, or whether a contact has perfected.

DELEGATE THIS RATHER THAN DERIVING IT: it needs two full sets of ecliptic longitudes — the birth instant, requiring the historic UTC offset at that place on that date, and the target instant — then the angle between every pair taken the SHORT way round a 360-degree circle, about a hundred and fifty subtractions each with a wrap case. The output looks exactly like a real transit list; errors land in the middle rows where nobody checks, and a missed wrap at 0 Aries silently drops or invents whole contacts.

REPRODUCE THE ORB CONVENTION FROM result.orbConvention — there is no fact of the matter about how close a transit must be to count, and an aspect list quoted without its orb is opinions presented as measurements. Here: 3 degrees for conjunction, opposition, trine and square, 2 for sextile, deliberately tighter than a natal chart's 8.

Omit "time" if the birth time is unknown: the ascendant and midheaven are then left out ENTIRELY rather than cast for an arbitrary noon, because a transit to a noon-cast angle reads exactly like a real contact while meaning nothing. THE MOON IS INCLUDED where most software excludes it; THE LUNAR NODES ARE EXCLUDED. Significance is interpretation and is not computed here.

CITATION: required. See server instructions.

Input parameters:

- `at` (string): Time of day for the TRANSIT, HH:MM in UTC, not local and not the birth time. Example: "12:00". Omit for 00:00 UTC.
- `date` (string, required): BIRTH date, ISO YYYY-MM-DD, 1800-2200. Example: "1977-10-19". The date to read the sky for is "on".
- `lat` (string): Birth latitude in decimal degrees as a string. Example: "39.76838". Send with lon.
- `lon` (string): Birth longitude in decimal degrees as a string. Example: "-86.15804". Send with lat.
- `on` (string, required): Date to READ THE SKY FOR, ISO YYYY-MM-DD, 1700-2200. Example: today's date for "what is transiting me now".
- `place` (string, required): Town or city of BIRTH with region or country. Example: "Indianapolis, Indiana, United States".
- `time` (string): BIRTH time HH:MM local at the birthplace. Example: "23:58". OMIT if unknown; the angles are then left out.
- `tz` (string): IANA zone or numeric UTC offset hours for the BIRTH moment. Example: "-5". Omit: resolved historically.

### `get_planetary_positions` (~590 tokens)

Get every planet's position on a date

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 parameters:

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

### `resolve_utc_offset` (~240 tokens)

Historic UTC offset

Resolves the UTC offset in force at a place on a date: the IANA zone that applied THEN, the signed offset, the UTC instant it resolves to, and a confidence of high, best-effort or low with the reason for anything below high. A statute that moved the zone is quoted with its Federal Register citation.

DELEGATE THIS RATHER THAN DERIVING IT: today's map is the wrong map for any past date, and a wrong offset looks exactly like a right one. Tennessee was on Central time until 28 September 1947, so a Knoxville record from that March is UTC-6 where America/New_York gives UTC-5.

CITATION: required. See server instructions.

Input parameters:

- `date` (string, required): The date wanted, ISO YYYY-MM-DD, 1800-2200. Example: "1947-03-15".
- `place` (string, required): Town or city, with region or country. Example: "Knoxville, Tennessee, US".
- `time` (string): Local clock time, 24-hour HH:MM. Example: "08:30". Omit for midday.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/net-totallytarot-calculators/totallytarot#diagnostics

## Score history

- 2026-09-28: 71
- 2026-09-27: 71
- 2026-09-26: 71
- 2026-09-25: 71
- 2026-09-24: 71
- 2026-09-23: 72
- 2026-09-22: 69
- 2026-09-21: 68

## Common questions

### What is the Totally Tarot Calculators MCP server?

Totally Tarot Calculators is an MCP server listed in the public MCP registry as net.totallytarot/calculators. Astrology charts, Maya calendar and tarot maths, computed on real engines, cited in every answer. This page covers its hosted endpoint (https://totallytarot.net/mcp).

### Is the Totally Tarot Calculators MCP server safe to use?

Totally Tarot Calculators scores 71 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Totally Tarot Calculators MCP server expose?

Totally Tarot Calculators exposes 12 tools: compute_birth_chart, compute_maya_day_sign, compute_tarot_birth_card, convert_calendar_date, compute_panchang, and 7 more. Their descriptions and schemas cost roughly 5,379 tokens of context every time the server is loaded.

### Does the Totally Tarot Calculators MCP server require authentication?

No. We connected to Totally Tarot Calculators without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the Totally Tarot Calculators MCP server still maintained?

Totally Tarot Calculators is still listed as active in the MCP registry. We last reached this channel on 28 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://totallytarot.net/mcp
- Website: https://totallytarot.net/
- Changelog RSS feed: https://verifymcp.io/servers/net-totallytarot-calculators/totallytarot.xml
- Changelog JSON feed: https://verifymcp.io/servers/net-totallytarot-calculators/totallytarot.json
- HTML version of this page: https://verifymcp.io/servers/net-totallytarot-calculators/totallytarot
