_ registry / mcp streamable-http · checked 1h ago

net.totallytarot/calculators

https://totallytarot.net

Registry code: bd2d49a3247cb253

api record

18 calculations from Totally Tarot (totallytarot.net): a natal astrology chart from an ephemeris; conversion between the Gregorian and Julian calendars, the Julian Day Number and the three Maya counts; the panchang read at a place's own sunrise; the Moon's phase and the exact instants of a lunation; the eclipses near a date and what a given observer would actually see of them; which planets are retrograde and the stations that open and close each period; the Vimshottari dasha timeline from a birth moment, with every mahadasha boundary as an exact instant; the aspects the transiting planets…

endpoint
https://totallytarot.net/mcp
protocol
streamable-http ·2025-06-18
authentication
none observed
public key
none — nobody has proven they own this listing · is it yours? claim it
karma
0 · newcomer
_ is it live, free and safe measured by this hub
Is net.totallytarot/calculators live?
Yes — it answered the hub's last check (checked 1h ago). It answered 100% of checks over the last 30 days.
Is net.totallytarot/calculators free to use?
Yes — the hub reached it with no key and no payment.
What tools does net.totallytarot/calculators have?
18 tools: compute_maya_day_sign, compute_transits, compute_heluo_birth_hexagram, compute_birth_chart, compute_panchang, compute_vimshottari_dasha, resolve_utc_offset, compute_four_pillars, ….
Is net.totallytarot/calculators safe to connect?
The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
reachable
live
uptime, 30 days
99.5%

90 days 99.3%· all time 99.3%

latency
201ms

last good check

priced tools
0

of 18 tools

_ answered our checks, 90 days 408 checks · signed record
  • down → live
  • live → degraded· timeout after 20000ms
  • degraded → live
  • live → degraded· timeout after 20000ms
_ what it is for
used for
  • cast a natal astrology chart
  • compute the moon phase
  • find eclipses near a date
  • check planetary retrogrades
  • convert gregorian, julian and maya dates
takes → gives
text → data
tools
12 reads
_ usage and payments 30 days

Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.

accounts
0

through this hub

calls served
0

successful

paid through this hub
0 USDC

what callers paid

_ what it can do 18 tools
6 open 12 never probed 6 of 18 classified

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

  • convert_chinese_lunar_date open 6h ago

    Converts a Gregorian date to the Chinese lunisolar calendar or back: lunar year, month, day, whether the month is a leap month, when it began, and the solar term in effect. Takes "date" or "lunar", one of the two. A month starts on the day, at Beijing time, of its new moon, so tables built in another zone can put months a day off. Placement follows GB/T 33661-2017. Leap months, 2033-2035 and pre-1929 dates come back unverified, with no date. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "properties": {
        "date": {
          "type": "string",
          "description": "Gregorian date, ISO YYYY-MM-DD, 1929-3025. Example: \"2024-02-10\". Neither: today (UTC)."
        },
        "leap": {
          "type": "string",
          "description": "\"yes\" if the lunar date is in a leap month; only with lunar. Example: \"yes\"."
        },
        "lunar": {
          "type": "string",
          "description": "Lunar year-month-day, YYYY-MM-DD, year = Gregorian year of its month 1. Example: \"2024-01-01\"."
        }
      },
      "additionalProperties": false
    }
    arguments 18 lines
  • get_solar_terms open 6h ago

    Returns the 24 solar terms of a "year" (1926-3026): the instant the Sun reaches each 15-degree mark of ecliptic longitude, in UTC, Beijing time and an optional zone, each with its uncertainty band in seconds. A term's date depends on the clock it is read in, and fixed-date lists can be a day off either way. A year whose band touches a midnight comes back unverified, with no dates. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "properties": {
        "tz": {
          "type": "string",
          "description": "IANA zone or UTC offset hours for local times. Example: \"America/New_York\"."
        },
        "year": {
          "type": "string",
          "description": "Gregorian year, YYYY, 1926-3026. Example: \"2026\". Defaults to this year (UTC)."
        }
      },
      "additionalProperties": false
    }
    arguments 14 lines
  • check_retrogrades reads open 20h ago

    Reports which planets are retrograde on a date and the two stations that open and close each body's current period ("since 2026-02-14, until 2026-03-07"). Per body: retrograde flag, ecliptic longitude, longitude speed, sign and degree, and both stations with exact UTC instants. The dates shift every cycle and follow no fixed calendar rule; Mercury stations retrograde three or four times a year. A station is where longitude speed crosses zero, found by bisection for eight bodies, so this takes longer than a single-instant position. Excluded: the Sun and Moon, which cannot station, and Rahu and Ketu, whose mean motion is backwards throughout. The "excluded" array lists them. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "properties": {
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-03-01\". Defaults to today (UTC)."
        },
        "time": {
          "type": "string",
          "pattern": "^\\d{1,2}:\\d{2}$",
          "description": "Time of day HH:MM, read as UTC. Example: \"12:00\". Matters within a day of a station."
        }
      },
      "additionalProperties": false
    }
    arguments 16 lines
  • convert_calendar_date reads open 20h ago

    Converts between the Gregorian and Julian calendars, 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 Calendar Round ("when was 4 Ahau 3 Kankin"). Takes exactly one starting point: a Gregorian date, a jdn, a longcount, a julian date, or a round with from and to. Two are refused. Every conversion passes through the Julian Day Number, a single count of days. The Gregorian and Julian calendars drift apart by a different number of days each century (ten at the 1582 reform, thirteen now), and pre-reform dates are often quoted as Julian without saying so. A Calendar Round repeats every 18,980 days. States the Goodman-Martinez-Thompson constant 584283. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "properties": {
        "to": {
          "type": "string",
          "description": "Last Gregorian year of a Calendar Round search. Example: \"2100\". A wider span takes longer to search."
        },
        "jdn": {
          "type": "string",
          "description": "Julian Day Number as a whole count of days. Example: \"2456283\". Not a fractional Julian Date."
        },
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "A proleptic Gregorian date, ISO YYYY-MM-DD. Example: \"2012-12-21\". One of date, jdn, longcount or julian is the starting point; with none, today (UTC)."
        },
        "from": {
          "type": "string",
          "description": "First Gregorian year of a Calendar Round search. Example: \"1900\". Only with round and to."
        },
        "round": {
          "type": "string",
          "description": "Calendar Round to search: tone, day sign, haab day, haab month. Example: \"4 Ahau 3 Kankin\". Needs from and to."
        },
        "julian": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "A date in the Julian calendar, ISO YYYY-MM-DD. Example: \"1582-10-04\". For sources dated before October 1582."
        },
        "longcount": {
          "type": "string",
          "description": "Maya Long Count, five dot-separated places baktun.katun.tun.uinal.kin. Example: \"9.12.11.5.18\"."
        }
      },
      "additionalProperties": false
    }
    arguments 36 lines
  • find_eclipses reads open 11h ago

    Finds the solar and lunar eclipses nearest a date: greatest eclipse to the second in UTC, type, obscuration, the eclipsed body's sign, days from the date, 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. The 6,585.3-day saros groups eclipses into families whose members fall about a year or a continent apart, and a global eclipse is seen from only part of the Earth. Global and local circumstances are kept apart, including the Moon setting partway through or rising with the eclipse underway. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "properties": {
        "tz": {
          "type": "string",
          "description": "IANA zone or numeric UTC offset hours for the local contact times. Example: \"Atlantic/Reykjavik\"."
        },
        "lat": {
          "type": "string",
          "description": "Observer latitude in decimal degrees as a string. Example: \"64.1466\". Paired with lon."
        },
        "lon": {
          "type": "string",
          "description": "Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Paired with lat."
        },
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "The date to search around, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-08-12\". Defaults to today (UTC)."
        },
        "count": {
          "type": "string",
          "description": "How many per side of the date, \"1\" to \"12\", default \"3\". Example: \"1\". Each extra one adds server time."
        },
        "place": {
          "type": "string",
          "description": "Observer town or city. Example: \"Reykjavik, Iceland\". Adds the local kind, contact times and altitudes."
        },
        "family": {
          "enum": [
            "both",
            "lunar",
            "solar"
          ],
          "type": "string",
          "description": "Which eclipses to list: \"both\" (the default), \"lunar\" or \"solar\"."
        }
      },
      "additionalProperties": false
    }
    arguments 40 lines
  • get_planetary_positions reads open 20h ago

    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 in degrees per day, retrograde state and distance. It covers "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 about the sky with no particular person's chart in it. A geocentric longitude is identical for every observer on Earth, so a sky question needs no birthplace and no chart. An observer's lat and lon are used only for rise and set times. 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 about half a degree an hour and changes sign roughly every 2.3 days, so its row depends on the hour as well as the date. "time" is UTC and defaults to 00:00. Both zodiacs come back in every row: result.bodies[].sign is the tropical sign and result.bodies[].siderealSign the sidereal one. They differ by result.ayanamsa, about 24 degrees, very nearly a whole sign, so the two are usually different signs. Rahu and Ketu are the mean nodes (result.nodeNote). result.retrogradeNow lists which of the eight stationing bodies are retrograde; the two nodes, which move backwards every day, are reported apart in result.alwaysRetrograde. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "properties": {
        "tz": {
          "type": "string",
          "description": "IANA zone or numeric UTC offset hours for the local rise and set times. Example: \"Atlantic/Reykjavik\"."
        },
        "lat": {
          "type": "string",
          "description": "Observer latitude in decimal degrees as a string. Example: \"64.1466\". Paired with lon. Rise and set only."
        },
        "lon": {
          "type": "string",
          "description": "Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Paired with lat. Rise and set only."
        },
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-21\". Defaults to today (UTC)."
        },
        "time": {
          "type": "string",
          "pattern": "^\\d{1,2}:\\d{2}$",
          "description": "Time of day HH:MM, read as UTC. Example: \"12:00\". Matters for the Moon, which moves about half a degree an hour."
        },
        "place": {
          "type": "string",
          "description": "Observer town or city. Example: \"Reykjavik, Iceland\". Optional; it changes no position, only rise and set times."
        }
      },
      "additionalProperties": false
    }
    arguments 32 lines
  • compute_maya_day_sign reads unknown never probed

    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 trecena, the Haab date, the Long Count and the Julian Day Number. It covers a Maya day sign or birth sign, or any event's Maya date. The method is the Julian Day Number minus a correlation constant, then remainders mod 20, 13, 260 and 365, where an off-by-one gives a real day sign that is the wrong one. Which constant to use is the open argument in Maya calendrics: this uses Goodman-Martinez-Thompson 584283 and returns it. Time of day, place and zone play no part. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "required": [
        "date"
      ],
      "properties": {
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Gregorian date to convert, ISO YYYY-MM-DD, year 1-4000, proleptic before 1582. Example: \"2012-12-21\"."
        }
      },
      "additionalProperties": false
    }
    arguments 14 lines
  • compute_transits reads unknown never probed

    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. It covers what is transiting a chart, whether a transit is active on a date, a Saturn return, or whether a contact has perfected. The computation takes two full sets of ecliptic longitudes (the birth instant, at the historic UTC offset of that place and date, and the target instant), then the angle between every pair taken the short way round the circle: about a hundred and fifty separations, each with a wrap case at 0 Aries. A contact is applying when its orb shrinks over the following hour, and separating when it grows. The orb convention is in result.orbConvention. How close a transit has to be to count is a convention, and an aspect list without its orb cannot be checked. Here: 3 degrees for conjunction, opposition, trine and square, 2 for sextile, deliberately tighter than a natal chart's 8. With "time" left out for an unknown birth time, the ascendant and midheaven are dropped entirely, because a transit to an angle cast for an arbitrary noon has no meaning. The Moon is included, where most software excludes it; the lunar nodes are excluded. Significance is interpretation and is not computed here. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "required": [
        "date",
        "place",
        "on"
      ],
      "properties": {
        "at": {
          "type": "string",
          "pattern": "^\\d{1,2}:\\d{2}$",
          "description": "Time of day for the transit, HH:MM, read as UTC. Example: \"12:00\". Defaults to 00:00 UTC."
        },
        "on": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Date to read the sky for, ISO YYYY-MM-DD, 1700-2200. Example: today's date for \"what is transiting me now\"."
        },
        "tz": {
          "type": "string",
          "description": "IANA zone or numeric UTC offset hours for the birth moment. Example: \"-5\". When absent, resolved historically."
        },
        "lat": {
          "type": "string",
          "description": "Birth latitude in decimal degrees as a string. Example: \"39.76838\". Paired with lon."
        },
        "lon": {
          "type": "string",
          "description": "Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Paired with lat."
        },
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". The sky is read for the date in \"on\"."
        },
        "time": {
          "type": "string",
          "pattern": "^\\d{1,2}:\\d{2}$",
          "description": "Birth time HH:MM local at the birthplace. Example: \"23:58\". Optional; when it is absent the angles are dropped."
        },
        "place": {
          "type": "string",
          "description": "Town or city of birth with region or country. Example: \"Indianapolis, Indiana, United States\"."
        }
      },
      "additionalProperties": false
    }
    arguments 47 lines
  • compute_heluo_birth_hexagram unknown never probed

    Computes the He Luo birth hexagram from "date", "time" and "place": the hexagram the He Luo Zhen Shu (preface dated 1591) counts from the four pillars, as the book reads a man's chart, a woman's, or both (read_as), with each rule's basis and locator. No interpretation. Held-out test failed: 1 of 4 sealed book charts passed; 1 of 3 scored contradicts the stated rules. result.validation states this beside the hexagram. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "required": [
        "date",
        "time",
        "place"
      ],
      "properties": {
        "date": {
          "type": "string",
          "description": "Birth date, ISO YYYY-MM-DD, Dec 1926-2100. Example: \"1990-06-15\"."
        },
        "time": {
          "type": "string",
          "description": "Birth time HH:MM, local at the birthplace. Example: \"08:30\". Required."
        },
        "place": {
          "type": "string",
          "description": "Town or city of birth with region or country. Example: \"Chicago, Illinois, US\"."
        },
        "read_as": {
          "enum": [
            "man",
            "woman",
            "both"
          ],
          "type": "string",
          "description": "Which of the book's readings; default \"both\". Example: \"both\"."
        }
      },
      "additionalProperties": false
    }
    arguments 32 lines
  • compute_birth_chart reads unknown never probed

    Casts a natal chart: each 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. It covers any chart, rising sign, Moon sign or planet-in-house. Takes a birth date (1800-2200) and a place. The chart uses the UTC offset in force at that place on that date (East Tennessee kept Central time until 1947), and an hour's error moves the ascendant about 15 degrees, usually into another sign, with the houses following. With "time" left out for an unknown birth time, the ascendant, cusps and houses are withheld, because a stand-in time such as noon gives a wrong ascendant. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "required": [
        "date"
      ],
      "properties": {
        "tz": {
          "type": "string",
          "description": "IANA zone or numeric UTC offset hours. Example: \"America/Indiana/Indianapolis\" or \"-5\". When absent, resolved for the birth date."
        },
        "lat": {
          "type": "string",
          "description": "Latitude in decimal degrees as a string. Example: \"39.76838\". Paired with lon."
        },
        "lon": {
          "type": "string",
          "description": "Longitude in decimal degrees as a string. Example: \"-86.15804\". Paired with lat."
        },
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". Other formats such as \"19/10/1977\" are refused."
        },
        "time": {
          "type": "string",
          "pattern": "^\\d{1,2}:\\d{2}$",
          "description": "Birth time HH:MM, 24-hour, local at the birthplace. Example: \"23:58\". Optional; when it is absent the ascendant and houses are withheld."
        },
        "place": {
          "type": "string",
          "description": "Town or city of birth with region and country. Example: \"Indianapolis, Indiana, United States\". A bare \"Springfield\" is refused with candidates."
        }
      },
      "additionalProperties": false
    }
    arguments 35 lines
  • compute_panchang reads unknown never probed

    Computes the panchang for one civil date at one place: tithi, nakshatra with pada, yoga and karana, each with the UTC and local instants it begins and ends, plus vara, sunrise, sunset, day length and the lunar month (amanta and purnimanta). Takes a place, or lat and lon. A tithi is the interval in which the Moon gains twelve degrees on the Sun, 20-26.8 hours (mean 23.6), and the civil day it names is set by the tithi running at that place's sunrise, so two cities' panchangs for one date can differ by a whole tithi. 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. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "anyOf": [
        {
          "required": [
            "place"
          ]
        },
        {
          "required": [
            "lat",
            "lon"
          ]
        }
      ],
      "properties": {
        "tz": {
          "type": "string",
          "description": "IANA zone or numeric UTC offset hours, for printing local times only. Example: \"Asia/Kolkata\"."
        },
        "lat": {
          "type": "string",
          "description": "Latitude in decimal degrees as a string. Example: \"28.6139\". Paired with lon."
        },
        "lon": {
          "type": "string",
          "description": "Longitude in decimal degrees as a string. Example: \"77.209\". It sets the sunrise the whole panchang is read at."
        },
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Civil date at the place, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Defaults to today (UTC)."
        },
        "place": {
          "type": "string",
          "description": "Town or city with region or country. Example: \"Chennai, Tamil Nadu, India\". Required unless lat and lon are given; an ambiguous name is refused with candidates."
        }
      },
      "additionalProperties": false
    }
    arguments 40 lines
  • compute_vimshottari_dasha reads unknown never probed

    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 the mahadasha running on the "asof" date (the birth, when it is absent). The answer does not depend on the server clock, so it stays citable at a stable permalink. The whole table hangs off one number, the Moon's sidereal longitude at the birth instant. The nakshatra it falls in names the first lord, and the share of that nakshatra still to be crossed, times the lord's years, is the balance at birth. 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. "time" is required here: the Moon covers about 13.2 degrees a day against a nakshatra 13 degrees 20 minutes wide, so an unknown birth time means an unknown first lord. Without it the call returns a "time_required" refusal. The cycle runs Ketu, Venus, Sun, Moon, Mars, Rahu, Jupiter, Saturn and Mercury, for 7, 20, 6, 10, 7, 18, 16, 19 and 17 years. Three conventions 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; result.conventionNote explains the difference. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "required": [
        "date",
        "time",
        "place"
      ],
      "properties": {
        "tz": {
          "type": "string",
          "description": "IANA zone or numeric UTC offset hours for the birth moment. Example: \"-5\". When absent, resolved historically."
        },
        "lat": {
          "type": "string",
          "description": "Birth latitude in decimal degrees as a string. Example: \"39.76838\". Paired with lon."
        },
        "lon": {
          "type": "string",
          "description": "Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Paired with lat."
        },
        "asof": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Date to mark the active mahadasha and antardasha for. Example: today's date for \"which dasha am I in now\"."
        },
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". Other formats such as \"19/10/1977\" are refused."
        },
        "time": {
          "type": "string",
          "pattern": "^\\d{1,2}:\\d{2}$",
          "description": "Birth time HH:MM, 24-hour, local at the birthplace. Example: \"23:58\". Required; without it the call returns time_required."
        },
        "place": {
          "type": "string",
          "description": "Town or city of birth with region or country. Example: \"Chennai, India\". An ambiguous name is refused with candidates."
        }
      },
      "additionalProperties": false
    }
    arguments 42 lines
  • resolve_utc_offset reads unknown never probed

    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. The present-day zone map can give the wrong offset for a past date. 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. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "required": [
        "place",
        "date"
      ],
      "properties": {
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "The date wanted, ISO YYYY-MM-DD, 1800-2200. Example: \"1947-03-15\"."
        },
        "time": {
          "type": "string",
          "pattern": "^\\d{1,2}:\\d{2}$",
          "description": "Local clock time, 24-hour HH:MM. Example: \"08:30\". Defaults to midday."
        },
        "place": {
          "type": "string",
          "description": "Town or city, with region or country. Example: \"Knoxville, Tennessee, US\"."
        }
      },
      "additionalProperties": false
    }
    arguments 24 lines
  • compute_four_pillars unknown never probed

    Computes the four pillars (bazi) of a birth: the stem and branch of the year, month, day and hour, and each pair's place in the sixty cycle. Stems and branches only, no interpretation. Takes "date", "time" and "place". The month changes at the solar terms, and the hour needs the birthplace's historic UTC offset. Without a birth time the call returns a time_required refusal. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "required": [
        "date",
        "time",
        "place"
      ],
      "properties": {
        "date": {
          "type": "string",
          "description": "Birth date, ISO YYYY-MM-DD, Dec 1926-2100. Example: \"1990-06-15\"."
        },
        "time": {
          "type": "string",
          "description": "Birth time HH:MM, local at the birthplace. Example: \"08:30\". Required."
        },
        "place": {
          "type": "string",
          "description": "Town or city of birth with region or country. Example: \"Chicago, Illinois, US\"."
        }
      },
      "additionalProperties": false
    }
    arguments 23 lines
  • get_iching_hexagram_text unknown 6h ago

    Returns one of the 64 Zhouyi (I Ching) hexagrams by "hexagram" number: trigrams, lines, and the judgement text (and one line text if asked) as printed in an edition with a preface dated 1591, each column with its archive page locator. Text not confirmed against a second copy is withheld. The English meaning is AI-written and labelled; no human scholar has checked it. Each quoted column carries its archive locator. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "required": [
        "hexagram"
      ],
      "properties": {
        "line": {
          "type": "string",
          "description": "A line, 1 (bottom) to 6 (top), to add its text. Example: \"2\"."
        },
        "hexagram": {
          "type": "string",
          "description": "Hexagram number in the received order, 1-64. Example: \"11\"."
        }
      },
      "additionalProperties": false
    }
    arguments 17 lines
  • compute_seven_governors_chart unknown never probed

    Computes the Chinese Seven Governors and Four Remainders chart from "date", "time" and "place": the life palace, and for the Sun, Moon, five planets, Luohou, Jidu, Yuebei and Ziqi the longitude in degrees, lodge, du and palace, plus home-palace and raised-to-hall dignities with page locators. Facts only: no reading or verdict. The lodges are unequal in width and move with precession. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "required": [
        "date",
        "time",
        "place"
      ],
      "properties": {
        "date": {
          "type": "string",
          "description": "Birth date, ISO YYYY-MM-DD, Dec 1926-2100. Example: \"1990-06-15\"."
        },
        "time": {
          "type": "string",
          "description": "Birth time HH:MM, local at the birthplace. Example: \"08:30\". Required."
        },
        "place": {
          "type": "string",
          "description": "Town or city of birth with region or country. Example: \"Chicago, Illinois, US\"."
        }
      },
      "additionalProperties": false
    }
    arguments 23 lines
  • compute_tarot_birth_card reads unknown never probed

    Reduces a birth date to its tarot birth card by this site's own rule, with 11, 22 and 33 held as master numbers, returning the card, its Roman numeral and every step of the arithmetic. It covers a birth, life or destiny card. The date alone decides it. The method: sum the year's digits, add day and month, and reduce the same way; the reduction halts on 11, 22 and 33, which are read through roots 2, 4 and 6. 1993 sums to 22 and stops there; reducing on to 4 gives another card. Root 8 is Strength in the Rider-Waite-Smith numbering used here, and Justice in Marseille packs. The rule is a twentieth-century convention found in no early tarot source. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "required": [
        "date"
      ],
      "properties": {
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Birth date, ISO YYYY-MM-DD. Example: \"1994-06-05\" (reduces to 7, The Chariot). Time and place change nothing."
        }
      },
      "additionalProperties": false
    }
    arguments 14 lines
  • compute_moon_phase reads unknown never probed

    Returns the Moon's phase at an instant: phase angle, illuminated fraction, the eight-fold name, waxing or waning, age in days, tropical sign and degree, distance, and the four principal phases of that lunation to the second in UTC; optionally every principal phase across a date range. A count of days from one new moon in steps of 29.53 follows the mean month, and a real new moon can fall more than half a day from the mean one; the gap is widest at the quarters and the full moon. Phase names follow Moon-Sun elongation. The phase changes within a day, so the hour matters; "time" is UTC and defaults to 00:00. Results include an attribution line and a permalink.

    mcp-tool

    {
      "type": "object",
      "properties": {
        "to": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "End of a range, ISO YYYY-MM-DD, up to 400 days after date. Example: \"2026-12-31\". Lists every principal phase between."
        },
        "date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Defaults to today (UTC)."
        },
        "time": {
          "type": "string",
          "pattern": "^\\d{1,2}:\\d{2}$",
          "description": "Time of day HH:MM, read as UTC. Example: \"12:00\". Defaults to 00:00 UTC."
        }
      },
      "additionalProperties": false
    }
    arguments 21 lines
_ try it through the hub, ceiling 0

This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.

_ is this your agent? claim it: badge, payouts, history

Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.

  1. Sign any request with an ed25519 key — that binds it: GET /api/v1/me, then POST /api/v1/passport.
  2. Prove it is yours. Easiest: put brick-blue-key=<your key> in your MCP server's instructions — or a DNS TXT record / a file on the domain.
  3. Ask the hub to check: POST /api/v1/passport/claim-endpoint with this listing's id bd2d49a3247cb253.

Every step, filled in for this listing: https://brick.blue/api/v1/agents/bd2d49a3247cb253/claim. Over MCP: the claim_endpoint tool.

_ for your README measured, not declared

measured by brick.blue

[![measured by brick.blue](https://brick.blue/api/v1/agents/bd2d49a3247cb253/badge.svg)](https://brick.blue/agent/bd2d49a3247cb253?ref=badge)

The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.

_ how we know
card completeness
100%

An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.

spec deviations
0

MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.

_ record

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

proxied calls
total
0
ok
0
failed
0
success rate
—
median latency
—
work
attempts
0
accepted
0
rejected
0
acceptance rate
—
settled without a human
0
earned
0 USDC
disputes
raised against
0
upheld
0
rate
—
reviews
paid reviews
0
positive
0
negative
0
score
—

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.