_ registry / mcp streamable-http

vedaksha-mcp

https://vedaksha.net

Registry code: b6231f3cf09966a5

api record

Canonical introspection mirror for the vedaksha library's MCP surface. tools/list returns the live tool catalog (schema drift-tested in CI). tools/call is not hosted here. To run these tools, self-host the library (cargo install vedaksha-mcp · pip install vedaksha · npm i vedaksha-wasm · ghcr.io/arthiqlabs/vedaksha-mcp) or build from source at github.com/arthiqlabs/vedaksha. There is no hosted execution surface.

endpoint
https://vedaksha.net/api/mcp
protocol
streamable-http ·2025-06-18
authentication
none observed
public key
none — nobody has proven they own this listing
karma
0 · newcomer
reachable
unknown
uptime
—
latency
—

last good check

priced tools
0

of 17 tools

_ used through this hub 30 days

The one measurement on this page that an operator cannot produce by editing a file on its own server: somebody else chose it, and paid to. Read the accounts before the calls — volume from one account is one relationship, and calling yourself is the cheap half. Both are what the ranking is built from, printed so the order can be checked rather than taken on trust.

accounts
0

distinct, expensive to fake

calls served
0

successful, last 30 days

_ what it can do 17 tools
17 never probed 0 of 17 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.

  • compute_natal_chart unknown never probed

    Compute a natal astrological chart for a given time and location. Returns a ChartGraph in JSON format containing planetary positions, house cusps, aspects, nakshatras, and dignities.

    mcp-tool

    {
  "type": "object",
  "required": [
    "julian_day",
    "latitude",
    "longitude"
  ],
  "properties": {
    "latitude": {
      "type": "number",
      "description": "Geographic latitude in degrees [-90, +90]"
    },
    "ayanamsha": {
      "enum": [
        "IndianOfficial",
        "FaganBradley",
        "Krishnamurti",
        "Raman",
        "SuryaSiddhanta",
        "Yukteshwar",
        "RevatiPaksha",
        "PushyaPaksha",
        "TrueChitra",
        "ChandraHari",
        "GalacticCenter0Sag",
        "Tropical"
      ],
      "type": "string",
      "default": "Tropical",
      "description": "Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession | FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP | Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr | Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 | SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 | Yukteshwar = Yukteswar, The Holy Science (1894) | RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos | PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa | TrueChitra [star] = Self-describing condition; Spica per Hipparcos | ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 | GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49."
    },
    "longitude": {
      "type": "number",
      "description": "Geographic longitude in degrees [-180, +180], east positive"
    },
    "julian_day": {
      "type": "number",
      "description": "Julian Day number in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms (planetary positions, nutation, obliquity) and evaluates the Earth-rotation term — sidereal time, and hence the ascendant, the MC and all twelve house cusps — at this UT1 value directly. Supplying a TDB Julian Day rotates every cusp by 0.289° (17.3') at today's ΔT ≈ 69 s."
    },
    "house_system": {
      "type": "string",
      "default": "Placidus",
      "description": "House system: Placidus, Koch, Equal, WholeSign, etc."
    }
  }
}
    arguments 46 lines
  • compute_dasha unknown never probed

    Compute Vedic dasha (planetary period) sequences. Supports five classical systems: Vimshottari, Ashtottari, Yogini (Moon-longitude based, require `moon_longitude`); Chara, Narayana (sign based, require BOTH `lagna_sign` AND `graha_signs`, since each sign's period length is counted to the sign its lord occupies in this chart). `graha_signs` takes the eight `sign_index` values compute_natal_chart already returns; Ketu is derived from Rahu and must not be supplied. Returns a JSON dasha tree with start/end Julian Days.

    mcp-tool

    {
  "type": "object",
  "required": [
    "birth_jd"
  ],
  "properties": {
    "levels": {
      "type": "integer",
      "default": 3,
      "maximum": 5,
      "minimum": 1,
      "description": "Number of nested dasha levels (1–5). Ignored by Chara and Narayana."
    },
    "system": {
      "enum": [
        "Vimshottari",
        "Ashtottari",
        "Yogini",
        "Chara",
        "Narayana"
      ],
      "type": "string",
      "default": "Vimshottari",
      "description": "Dasha system selector"
    },
    "birth_jd": {
      "type": "number",
      "description": "Birth Julian Day used as the dasha epoch, in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day. This epoch is only added to, never converted: every returned start_jd/end_jd is on the same UT1 scale as the input."
    },
    "lagna_sign": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Lagna (ascendant) sign 0–11 (0 = Aries). Required for Chara, Narayana. This is the same 0-indexed convention compute_natal_chart, compute_bhavas and compute_vargas all serve as `sign_index`, so an ascendant read from any of them passes straight through. Through v8.1.0 this one parameter was 1-indexed while every other tool was 0-indexed; that mismatch is resolved here."
    },
    "graha_signs": {
      "type": "object",
      "required": [
        "sun",
        "moon",
        "mars",
        "mercury",
        "jupiter",
        "venus",
        "saturn",
        "rahu"
      ],
      "properties": {
        "sun": {
          "type": "integer",
          "maximum": 11,
          "minimum": 0,
          "description": "Sun's natal sign, 0-11 (0 = Aries)."
        },
        "mars": {
          "type": "integer",
          "maximum": 11,
          "minimum": 0,
          "description": "Mars's natal sign, 0-11 (0 = Aries)."
        },
        "moon": {
          "type": "integer",
          "maximum": 11,
          "minimum": 0,
          "description": "Moon's natal sign, 0-11 (0 = Aries)."
        },
        "rahu": {
          "type": "integer",
          "maximum": 11,
          "minimum": 0,
          "description": "Rahu's (north lunar node's) natal sign, 0-11 (0 = Aries)."
        },
        "venus": {
          "type": "integer",
          "maximum": 11,
          "minimum": 0,
          "description": "Venus's natal sign, 0-11 (0 = Aries)."
        },
        "saturn": {
          "type": "integer",
          "maximum": 11,
          "minimum": 0,
          "description": "Saturn's natal sign, 0-11 (0 = Aries)."
        },
        "jupiter": {
          "type": "integer",
          "maximum": 11,
          "minimum": 0,
          "description": "Jupiter's natal sign, 0-11 (0 = Aries)."
        },
        "mercury": {
          "type": "integer",
          "maximum": 11,
          "minimum": 0,
          "description": "Mercury's natal sign, 0-11 (0 = Aries)."
        }
      },
      "description": "Natal sign positions of the seven classical grahas plus Rahu, 0-11 each (0 = Aries), as served by compute_natal_chart's sign_index. Required for Chara, Narayana, whose period lengths are chart-dependent — each sign's duration is the count from that sign to the sign its lord actually occupies. Sign indices are used rather than longitudes: they chain directly from compute_natal_chart's sign_index with no conversion, carry no tropical-vs-sidereal ambiguity, and avoid the boundary question of a planet at exactly 30.0 degrees. Ketu is not a field: it is derived as (rahu + 6) mod 12, since the two lunar nodes are always exactly opposite."
    },
    "moon_longitude": {
      "type": "number",
      "maximum": 360,
      "minimum": 0,
      "description": "Natal Moon sidereal longitude in degrees [0, 360). Required for Vimshottari, Ashtottari, Yogini."
    }
  }
}
    arguments 107 lines
  • compute_karakas unknown never probed

    Compute Jaimini Chara Karaka assignments from sidereal planet longitudes. Ranks planets by degrees within their current sign: highest = Atmakaraka (soul significator), lowest = Darakaraka (spouse significator). Supports 7-karaka (Sun–Saturn) and 8-karaka (adds Rahu) schemes.

    mcp-tool

    {
  "type": "object",
  "required": [
    "sun",
    "moon",
    "mars",
    "mercury",
    "jupiter",
    "venus",
    "saturn"
  ],
  "properties": {
    "sun": {
      "type": "number",
      "description": "Sidereal longitude of Sun [0, 360)"
    },
    "mars": {
      "type": "number",
      "description": "Sidereal longitude of Mars [0, 360)"
    },
    "moon": {
      "type": "number",
      "description": "Sidereal longitude of Moon [0, 360)"
    },
    "rahu": {
      "type": "number",
      "description": "Sidereal longitude of Rahu [0, 360). Required for scheme '8'."
    },
    "venus": {
      "type": "number",
      "description": "Sidereal longitude of Venus [0, 360)"
    },
    "saturn": {
      "type": "number",
      "description": "Sidereal longitude of Saturn [0, 360)"
    },
    "scheme": {
      "enum": [
        "7",
        "8"
      ],
      "type": "string",
      "default": "7",
      "description": "Karaka scheme: '7' (default, Sun–Saturn) or '8' (adds Rahu + Pitrikaraka)"
    },
    "jupiter": {
      "type": "number",
      "description": "Sidereal longitude of Jupiter [0, 360)"
    },
    "mercury": {
      "type": "number",
      "description": "Sidereal longitude of Mercury [0, 360)"
    }
  }
}
    arguments 55 lines
  • compute_combustion unknown never probed

    Compute combustion state for each planet relative to the Sun: principle per BPHS Ch.7 vv.28-29, orbs per Surya Siddhanta IX.6-8 and X.1 (Moon 12, Mars 17, Mercury 14 or 12 retrograde, Jupiter 11, Venus 10 or 8 retrograde, Saturn 15 deg). Returns Combust, DeeplyCombust, or None for Moon, Mars, Mercury, Jupiter, Venus, Saturn with degrees of separation. This is a low-level tool over already-known positions, not a natal-chart tool: call compute_natal_chart first and pass its planets[].longitude (matched by planets[].name) and planets[].retrograde values straight through as this tool's inputs — do not recompute or re-derive them.

    mcp-tool

    {
  "type": "object",
  "required": [
    "sun",
    "moon",
    "mars",
    "mercury",
    "jupiter",
    "venus",
    "saturn"
  ],
  "properties": {
    "sun": {
      "type": "number",
      "description": "Sidereal longitude of Sun [0, 360). From compute_natal_chart's planets[] entry where name == \"Sun\", field longitude."
    },
    "mars": {
      "type": "number",
      "description": "Sidereal longitude of Mars [0, 360). From compute_natal_chart's planets[] entry where name == \"Mars\", field longitude."
    },
    "moon": {
      "type": "number",
      "description": "Sidereal longitude of Moon [0, 360). From compute_natal_chart's planets[] entry where name == \"Moon\", field longitude."
    },
    "venus": {
      "type": "number",
      "description": "Sidereal longitude of Venus [0, 360). From compute_natal_chart's planets[] entry where name == \"Venus\", field longitude."
    },
    "saturn": {
      "type": "number",
      "description": "Sidereal longitude of Saturn [0, 360). From compute_natal_chart's planets[] entry where name == \"Saturn\", field longitude."
    },
    "jupiter": {
      "type": "number",
      "description": "Sidereal longitude of Jupiter [0, 360). From compute_natal_chart's planets[] entry where name == \"Jupiter\", field longitude."
    },
    "mercury": {
      "type": "number",
      "description": "Sidereal longitude of Mercury [0, 360). From compute_natal_chart's planets[] entry where name == \"Mercury\", field longitude."
    },
    "mars_retrograde": {
      "type": "boolean",
      "default": false,
      "description": "True if Mars is retrograde. Accepted for symmetry; Mars's orb is 17 deg either way (Surya Siddhanta IX.6 gives it no retrograde figure), so this does not change the result. From compute_natal_chart's Mars entry, field retrograde."
    },
    "venus_retrograde": {
      "type": "boolean",
      "default": false,
      "description": "True if Venus is retrograde, which narrows its combustion orb from 10 deg to 8 deg (Surya Siddhanta IX.7). From compute_natal_chart's Venus entry, field retrograde."
    },
    "saturn_retrograde": {
      "type": "boolean",
      "default": false,
      "description": "True if Saturn is retrograde. Accepted for symmetry; Saturn's orb is 15 deg either way, so this does not change the result. From compute_natal_chart's Saturn entry, field retrograde."
    },
    "jupiter_retrograde": {
      "type": "boolean",
      "default": false,
      "description": "True if Jupiter is retrograde. Accepted for symmetry; Jupiter's orb is 11 deg either way, so this does not change the result. From compute_natal_chart's Jupiter entry, field retrograde."
    },
    "mercury_retrograde": {
      "type": "boolean",
      "default": false,
      "description": "True if Mercury is retrograde, which narrows its combustion orb from 14 deg to 12 deg (Surya Siddhanta IX.8). From compute_natal_chart's Mercury entry, field retrograde."
    }
  }
}
    arguments 67 lines
  • compute_shadbala unknown never probed

    Compute six-fold Shadbala (Sthana, Dig, Kala, Cheshta, Naisargika, Drik Bala) per planet, with the Sthana sub-components (uccha, ojhayugma, kendradi, drekkana) and ishta/kashta phala, per BPHS Ch.27-28. Sthana Bala omits Saptavargaja Bala and Kala Bala covers Nathonnatha and Paksha only.

    mcp-tool

    {
  "type": "object",
  "required": [
    "planets"
  ],
  "properties": {
    "planets": {
      "type": "array",
      "items": {
        "type": "object",
        "required": [
          "planet",
          "sign",
          "longitude",
          "bhava",
          "speed",
          "average_speed"
        ],
        "properties": {
          "sign": {
            "type": "integer",
            "maximum": 11,
            "minimum": 0,
            "description": "Sidereal sign index, which must agree with longitude (floor(longitude / 30))."
          },
          "bhava": {
            "type": "integer",
            "maximum": 12,
            "minimum": 1,
            "description": "House occupied, 1-12. Drives Dig Bala and Kendradi Bala."
          },
          "speed": {
            "type": "number",
            "description": "Current apparent speed in degrees per day, negative when retrograde. Drives Cheshta Bala."
          },
          "planet": {
            "type": "string",
            "description": "Planet name: Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn"
          },
          "longitude": {
            "type": "number",
            "maximum": 360,
            "minimum": 0,
            "description": "Sidereal longitude in degrees [0, 360). Drives Uchcha, Ojhayugma and Drekkana Bala."
          },
          "average_speed": {
            "type": "number",
            "description": "Mean daily motion in degrees per day, compared against speed for Cheshta Bala."
          },
          "benefic_aspect_count": {
            "type": "integer",
            "default": 0,
            "description": "Number of benefic aspects received. Drives Drik Bala."
          },
          "malefic_aspect_count": {
            "type": "integer",
            "default": 0,
            "description": "Number of malefic aspects received, subtracted in Drik Bala."
          }
        }
      },
      "description": "Array of planet data objects."
    },
    "is_daytime": {
      "type": "boolean",
      "default": false,
      "description": "True if the birth moment falls between sunrise and sunset. Feeds Nathonnatha Bala within Kala Bala."
    },
    "moon_phase_waxing": {
      "type": "boolean",
      "default": false,
      "description": "True during shukla paksha (waxing Moon). Feeds Paksha Bala within Kala Bala."
    }
  }
}
    arguments 75 lines
  • compute_vargas unknown never probed

    Compute Vedic divisional charts (vargas). Given a time and place, returns one chart per requested division: the varga lagna, and for each of the ten bodies compute_natal_chart returns — the seven grahas plus the mean, true and osculating lunar node — its rashi longitude, the sign it occupies within that varga, its dignity in that sign, and its whole-sign bhava counted from the varga lagna. Ketu is not listed separately: it is the node's opposite point, 180 degrees away. The nodes carry no dignity, so that field is absent for them. Supply planet_longitude instead to divide a single longitude without an ephemeris lookup, in which case no graha name, dignity or bhava is returned because none is defined. Vargas are classically read on a sidereal zodiac: pass an ayanamsha, or accept the Tropical default this surface uses everywhere. Source: BPHS Ch. 6-7.

    mcp-tool

    {
  "type": "object",
  "required": [
    "julian_day",
    "latitude",
    "longitude",
    "divisions"
  ],
  "properties": {
    "latitude": {
      "type": "number",
      "description": "Geographic latitude in degrees [-90, +90]"
    },
    "ayanamsha": {
      "enum": [
        "IndianOfficial",
        "FaganBradley",
        "Krishnamurti",
        "Raman",
        "SuryaSiddhanta",
        "Yukteshwar",
        "RevatiPaksha",
        "PushyaPaksha",
        "TrueChitra",
        "ChandraHari",
        "GalacticCenter0Sag",
        "Tropical"
      ],
      "type": "string",
      "description": "Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession | FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP | Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr | Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 | SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 | Yukteshwar = Yukteswar, The Holy Science (1894) | RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos | PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa | TrueChitra [star] = Self-describing condition; Spica per Hipparcos | ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 | GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49."
    },
    "divisions": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "minItems": 1,
      "description": "Varga division codes to compute, e.g. [\"D1\", \"D9\", \"D10\"]"
    },
    "longitude": {
      "type": "number",
      "description": "Geographic longitude in degrees [-180, +180], east positive"
    },
    "tradition": {
      "enum": [
        "modality",
        "element"
      ],
      "type": "string",
      "default": "modality",
      "description": "Which Parashari reading to use where the texts diverge. 'modality' (default) starts the division from a movable/fixed/dual sign; 'element' starts it from a fire/earth/air/water sign. This changes D16, D20, D30 and D45 only; every other varga is identical under both. Source: BPHS Ch. 6; Phala Deepika Ch. 2."
    },
    "julian_day": {
      "type": "number",
      "description": "Julian Day number in UT1 (Universal Time) — not TT, not TDB. Same scale as compute_natal_chart's julian_day: the engine converts to TT internally for the dynamical terms and uses UT1 directly for the Earth-rotation term."
    },
    "planet_longitude": {
      "type": "number",
      "description": "Sidereal longitude of a single body in degrees [0, 360). When supplied, only this longitude is divided and no ephemeris is consulted; the result carries no graha name, dignity or bhava."
    }
  }
}
    arguments 62 lines
  • emit_graph unknown never probed

    Turn a chart into a queryable property graph. Accepts the output of compute_natal_chart directly (pass latitude and longitude alongside it), or an existing ChartGraph. Emits Neo4j Cypher, SurrealDB SurrealQL, JSON-LD, plain JSON, or RAG embedding text.

    mcp-tool

    {
  "type": "object",
  "required": [
    "chart_json",
    "format"
  ],
  "properties": {
    "format": {
      "enum": [
        "cypher",
        "surreal",
        "jsonld",
        "json",
        "embedding"
      ],
      "type": "string",
      "description": "Target output format"
    },
    "latitude": {
      "type": "number",
      "maximum": 90,
      "minimum": -90,
      "description": "Observer latitude, degrees north. Required when chart_json is a computed chart; a chart result does not record where it was cast. Ignored for an existing ChartGraph."
    },
    "longitude": {
      "type": "number",
      "maximum": 180,
      "minimum": -180,
      "description": "Observer longitude, degrees east. Required when chart_json is a computed chart."
    },
    "chart_json": {
      "type": "object",
      "description": "Either the output of compute_natal_chart ({planets, houses, aspects, ...}), which is converted to a graph here, or an existing ChartGraph ({nodes, edges, chart_id, classification})"
    },
    "classification": {
      "type": "string",
      "description": "Optional label or session ID attached to emitted nodes"
    }
  }
}
    arguments 40 lines
  • compute_transit unknown never probed

    Compute transiting planet positions relative to a natal chart at a specific moment. Returns planet longitudes for the transit time alongside natal positions, enabling aspect calculation between transit and natal placements.

    mcp-tool

    {
  "type": "object",
  "required": [
    "natal_jd",
    "natal_lat",
    "natal_lon",
    "transit_jd"
  ],
  "properties": {
    "natal_jd": {
      "type": "number",
      "description": "Julian Day of the natal chart in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms."
    },
    "natal_lat": {
      "type": "number",
      "description": "Natal geographic latitude in degrees [-90, +90]"
    },
    "natal_lon": {
      "type": "number",
      "description": "Natal geographic longitude in degrees [-180, +180], east positive"
    },
    "transit_jd": {
      "type": "number",
      "description": "Julian Day of the transit moment to compute, in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms."
    }
  }
}
    arguments 27 lines
  • search_transits unknown never probed

    Search for transiting planet–natal planet aspects within a time window. Supply natal positions and a Julian Day range; receive a list of exact transit moments with aspect type, orb, and applying/separating status.

    mcp-tool

    {
  "type": "object",
  "required": [
    "natal_positions",
    "start_jd",
    "end_jd"
  ],
  "properties": {
    "bodies": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Transiting bodies to include. Defaults to all planets."
    },
    "end_jd": {
      "type": "number",
      "description": "End of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB."
    },
    "aspects": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Aspect types to filter (e.g. conjunction, opposition, trine). Defaults to major aspects."
    },
    "max_orb": {
      "type": "number",
      "default": 1,
      "description": "Maximum orb in degrees (default 1.0)"
    },
    "start_jd": {
      "type": "number",
      "description": "Start of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms; each event's exact_jd is returned on this same UT1 scale."
    },
    "natal_positions": {
      "type": "array",
      "items": {
        "type": "object",
        "required": [
          "name",
          "longitude"
        ],
        "properties": {
          "name": {
            "type": "string",
            "description": "Planet name (e.g. Mars, Venus)"
          },
          "longitude": {
            "type": "number",
            "description": "Natal sidereal longitude in degrees [0, 360)"
          }
        }
      },
      "minItems": 1,
      "description": "Array of natal planet positions to check transits against"
    }
  }
}
    arguments 59 lines
  • search_muhurta unknown never probed

    Search for auspicious time windows (muhurta) within a given period for a geographic location. Returns ranked muhurta candidates with quality scores based on tithi, nakshatra, yoga, karana, and planetary positions. The search window is capped at 30 days (see MUHURTA_SEARCH_RANGE_TOO_LARGE) — the per-candidate vara and tithi/nakshatra refinement make this tool far more expensive per day of range than a transit search, so a wider span would make a single call take minutes.

    mcp-tool

    {
  "type": "object",
  "required": [
    "start_jd",
    "end_jd",
    "latitude",
    "longitude"
  ],
  "properties": {
    "end_jd": {
      "type": "number",
      "description": "End of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The span from start_jd to end_jd must not exceed 30 days."
    },
    "latitude": {
      "type": "number",
      "description": "Geographic latitude in degrees [-90, +90]"
    },
    "start_jd": {
      "type": "number",
      "description": "Start of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms and uses UT1 directly for sunrise, which each candidate's vara is reckoned from; every returned jd, tithi_end_jd and nakshatra_end_jd is on this same UT1 scale. The span from start_jd to end_jd must not exceed 30 days."
    },
    "longitude": {
      "type": "number",
      "description": "Geographic longitude in degrees [-180, +180], east positive"
    },
    "elevation_m": {
      "type": "number",
      "default": 0,
      "maximum": 9000,
      "minimum": -500,
      "description": "Observer elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise, which is what each candidate's vara is reckoned from — at 3650 m (Lhasa) 9.2 minutes earlier. Pass the same value as compute_panchanga for the same observer, or the two tools can report different weekdays for one instant."
    },
    "min_quality": {
      "type": "number",
      "default": 0.5,
      "maximum": 1,
      "minimum": 0,
      "description": "Minimum quality score [0.0, 1.0] for muhurta inclusion (default 0.5)"
    },
    "tz_offset_minutes": {
      "type": "integer",
      "default": 0,
      "maximum": 840,
      "minimum": -720,
      "description": "Offset of the observer's civil clock from UT, in minutes. Names the vara (weekday) reported for each candidate — it does not change which sunrise bounds the vara, only what that vara is called. Default 0 (UT)."
    }
  }
}
    arguments 48 lines
  • compute_ashtakavarga unknown never probed

    Compute Bhinna Ashtakavarga (raw bindu tables) and Sarvashtakavarga for all 7 planets from sign positions. Source: BPHS Ch.66 vv.13-68. Trikona/Ekadhipatya Shodhana and Pinda Sadhana are not included.

    mcp-tool

    {
  "type": "object",
  "required": [
    "sun",
    "moon",
    "mars",
    "mercury",
    "jupiter",
    "venus",
    "saturn",
    "lagna"
  ],
  "properties": {
    "sun": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Sign index of Sun (0=Aries…11=Pisces)"
    },
    "mars": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Sign index of Mars (0=Aries…11=Pisces)"
    },
    "moon": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Sign index of Moon (0=Aries…11=Pisces)"
    },
    "lagna": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Sign index of Lagna (Ascendant)"
    },
    "venus": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Sign index of Venus (0=Aries…11=Pisces)"
    },
    "saturn": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Sign index of Saturn (0=Aries…11=Pisces)"
    },
    "jupiter": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Sign index of Jupiter (0=Aries…11=Pisces)"
    },
    "mercury": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Sign index of Mercury (0=Aries…11=Pisces)"
    }
  }
}
    arguments 63 lines
  • compute_gochara unknown never probed

    Compute Gochara (transit interpretation) for the seven grahas against a natal reference sign per BPHS Ch.29. Returns favourable/unfavourable verdict, house from natal, and raw vedha (obstruction) candidates per planet. The natal reference sign is the caller's choice — typically the natal Moon's sign (Chandra Gochara) or the natal Lagna's sign. Rahu and Ketu are not included.

    mcp-tool

    {
  "type": "object",
  "required": [
    "sun",
    "moon",
    "mars",
    "mercury",
    "jupiter",
    "venus",
    "saturn",
    "natal_reference_sign"
  ],
  "properties": {
    "sun": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Transit sign index of Sun (0=Aries … 11=Pisces)"
    },
    "mars": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Transit sign index of Mars"
    },
    "moon": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Transit sign index of Moon"
    },
    "venus": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Transit sign index of Venus"
    },
    "saturn": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Transit sign index of Saturn"
    },
    "school": {
      "enum": [
        "Geometry",
        "Parashari"
      ],
      "type": "string",
      "default": "Geometry",
      "description": "Exemption profile applied to the raw vedha candidate list"
    },
    "jupiter": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Transit sign index of Jupiter"
    },
    "mercury": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Transit sign index of Mercury"
    },
    "vedha_table": {
      "enum": [
        "Bphs29"
      ],
      "type": "string",
      "default": "Bphs29",
      "description": "Vedha pair table source"
    },
    "natal_reference_sign": {
      "type": "integer",
      "maximum": 11,
      "minimum": 0,
      "description": "Sign index of the natal reference point — natal Moon for Chandra Gochara, natal Lagna for Lagna-based Gochara"
    }
  }
}
    arguments 80 lines
  • compute_panchanga unknown never probed

    Compute the panchanga — the five limbs of the Vedic almanac — for an instant: tithi (lunar day, with paksha and lord), vara (weekday reckoned from local sunrise, with its lord and the Rahu and Gulika Kalam windows as Julian Days), nakshatra (with pada), yoga (one of the 27 nithya yogas, with degrees remaining), and karana (half-tithi). Takes sidereal longitudes; all returned instants are Julian Days (UT). vara.from_sunrise reports HOW the weekday was reckoned: true means it was taken from an actual local sunrise (the Vedic definition); false means no sunrise exists to reckon from — the polar day or polar night, above about ±66.5° latitude — and the value is the observer's local CIVIL weekday as a documented fallback, which is a different quantity. Check it before presenting the vara at high latitude. vara.rahu_kalam being null is NOT the same signal: the Kalam windows can also be null while from_sunrise is true.

    mcp-tool

    {
  "type": "object",
  "required": [
    "jd",
    "sun",
    "moon",
    "latitude",
    "longitude"
  ],
  "properties": {
    "jd": {
      "type": "number",
      "description": "Julian Day number in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms and uses UT1 directly for sunrise, which the vara is reckoned from; every returned instant, the Rahu and Gulika Kalam bounds included, is on this same UT1 scale. Supplying a TT/TDB Julian Day shifts sunrise by ΔT (≈ 69 s today), enough to move the vara for an instant near sunrise."
    },
    "sun": {
      "type": "number",
      "description": "Sidereal longitude of Sun [0, 360)"
    },
    "moon": {
      "type": "number",
      "description": "Sidereal longitude of Moon [0, 360)"
    },
    "latitude": {
      "type": "number",
      "maximum": 90,
      "minimum": -90,
      "description": "Observer latitude in degrees. Required — the vara is reckoned from local sunrise, so it depends on the observer."
    },
    "longitude": {
      "type": "number",
      "maximum": 180,
      "minimum": -180,
      "description": "Observer longitude in degrees, east positive. Required."
    },
    "elevation_m": {
      "type": "number",
      "default": 0,
      "maximum": 9000,
      "minimum": -500,
      "description": "Observer elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise — at 3650 m (Lhasa) 9.2 minutes earlier, enough to change the vara in that window. Pass the same value as search_muhurta for the same observer, or the two tools can report different weekdays for one instant."
    },
    "tz_offset_minutes": {
      "type": "integer",
      "default": 0,
      "maximum": 840,
      "minimum": -720,
      "description": "Offset of the observer's civil clock from UT, in minutes, in [-720, 840] (UTC-12:00 to UTC+14:00). Used only to name the vara's weekday."
    }
  }
}
    arguments 50 lines
  • compute_drishti unknown never probed

    Compute graha drishti — Vedic sign aspects — for all nine grahas. Unlike Western aspects, drishti is cast from sign to sign and is asymmetric: every graha aspects the 7th from itself, and Mars additionally aspects the 4th and 8th, Jupiter the 5th and 9th, Saturn the 3rd and 10th. Returns each aspect with its graded strength (Full, ThreeQuarter, Half, Quarter) and the house distance.

    mcp-tool

    {
  "type": "object",
  "required": [
    "sun",
    "moon",
    "mars",
    "mercury",
    "jupiter",
    "venus",
    "saturn",
    "rahu",
    "ketu"
  ],
  "properties": {
    "sun": {
      "type": "number",
      "description": "Sidereal longitude of Sun [0, 360)"
    },
    "ketu": {
      "type": "number",
      "description": "Sidereal longitude of Ketu [0, 360)"
    },
    "mars": {
      "type": "number",
      "description": "Sidereal longitude of Mars [0, 360)"
    },
    "moon": {
      "type": "number",
      "description": "Sidereal longitude of Moon [0, 360)"
    },
    "rahu": {
      "type": "number",
      "description": "Sidereal longitude of Rahu [0, 360)"
    },
    "venus": {
      "type": "number",
      "description": "Sidereal longitude of Venus [0, 360)"
    },
    "saturn": {
      "type": "number",
      "description": "Sidereal longitude of Saturn [0, 360)"
    },
    "jupiter": {
      "type": "number",
      "description": "Sidereal longitude of Jupiter [0, 360)"
    },
    "mercury": {
      "type": "number",
      "description": "Sidereal longitude of Mercury [0, 360)"
    }
  }
}
    arguments 52 lines
  • compute_bhavas unknown never probed

    Compute the whole-sign bhava (house) chart from an ascendant. In the Vedic whole-sign system the entire sign containing the ascendant is the 1st bhava, the next sign the 2nd, and so on — houses do not have cusps within signs. Returns the sign of each of the twelve bhavas with its kendra / trikona / dusthana / upachaya classification, and optionally places supplied grahas into their bhavas.

    mcp-tool

    {
  "type": "object",
  "required": [
    "ascendant"
  ],
  "properties": {
    "planets": {
      "type": "object",
      "description": "Optional map of graha name to sidereal longitude, e.g. {\"Mars\": 200.4}. Each is placed into its bhava.",
      "additionalProperties": {
        "type": "number"
      }
    },
    "ascendant": {
      "type": "number",
      "description": "Sidereal longitude of the ascendant [0, 360)"
    }
  }
}
    arguments 19 lines
  • compute_synastry unknown never probed

    Compute synastry — the aspects each graha in one chart makes to each graha in another chart. Every graha in chart A is tested against every graha in chart B (the two charts do not need the same graha names), and each hit is returned with its aspect type, orb in degrees and strength (1.0 at exact, falling linearly to 0.0 at the orb boundary). Orbs are the traditional Lilly values — conjunction, trine and opposition 8°, square 7°, sextile 6°, minors 2° — scaled by orb_factor. Longitudes only: this tool needs no birth time, place or ephemeris.

    mcp-tool

    {
  "type": "object",
  "required": [
    "chart_a",
    "chart_b"
  ],
  "properties": {
    "chart_a": {
      "type": "object",
      "description": "Map of graha name to sidereal longitude [0, 360) for the first chart, e.g. {\"Sun\": 10.0, \"Moon\": 130.0}.",
      "additionalProperties": {
        "type": "number"
      }
    },
    "chart_b": {
      "type": "object",
      "description": "Map of graha name to sidereal longitude [0, 360) for the second chart. Need not use the same names as chart_a.",
      "additionalProperties": {
        "type": "number"
      }
    },
    "aspect_set": {
      "enum": [
        "major",
        "all"
      ],
      "type": "string",
      "default": "major",
      "description": "'major' (default) tests the five Ptolemaic aspects; 'all' adds semi-sextile, semi-square, quintile, sesquiquadrate, bi-quintile and quincunx."
    },
    "orb_factor": {
      "type": "number",
      "default": 1,
      "description": "Multiplier on the default orbs. 1.0 (default) is standard, 0.5 is tight. Must be greater than 0 and at most 5.0, above which the major-aspect windows cover every separation."
    }
  }
}
    arguments 37 lines
  • compute_composite unknown never probed

    Compute the midpoint composite chart of two charts: for each graha, the shorter-arc midpoint of its longitude in the two charts, and the arithmetic mean of its two speeds. The two charts must carry the SAME graha names — each graha is paired with its namesake, not with whatever happens to sit at the same position in a list — and a name present in one chart but not the other is an error naming that graha. Longitudes only: this tool needs no birth time, place or ephemeris.

    mcp-tool

    {
  "type": "object",
  "required": [
    "chart_a",
    "chart_b"
  ],
  "properties": {
    "chart_a": {
      "type": "object",
      "description": "Map of graha name to position for the first chart, e.g. {\"Sun\": {\"longitude\": 350.0, \"speed\": 1.0}}. `speed` is optional and defaults to 0.",
      "additionalProperties": {
        "type": "object",
        "required": [
          "longitude"
        ],
        "properties": {
          "speed": {
            "type": "number",
            "description": "Daily motion in degrees/day; negative when retrograde"
          },
          "longitude": {
            "type": "number",
            "description": "Sidereal longitude [0, 360)"
          }
        }
      }
    },
    "chart_b": {
      "type": "object",
      "description": "Map of graha name to position for the second chart. Must have exactly the same graha names as chart_a.",
      "additionalProperties": {
        "type": "object",
        "required": [
          "longitude"
        ],
        "properties": {
          "speed": {
            "type": "number",
            "description": "Daily motion in degrees/day; negative when retrograde"
          },
          "longitude": {
            "type": "number",
            "description": "Sidereal longitude [0, 360)"
          }
        }
      }
    }
  }
}
    arguments 49 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.

_ for your README measured, not declared

measured by brick.blue

[![measured by brick.blue](https://brick.blue/api/v1/agents/b6231f3cf09966a5/badge.svg)](https://brick.blue/agent/b6231f3cf09966a5)

The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Own the domain? Prove it and the listing carries a verified badge here too: passport.

_ 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.