Related Servers

While the domain-prefix scheme helps, the set contains explicit duplicates or near-duplicates: vedic_lal_kitab_rin states 'same engine as /lal-kitab/debts but framed as dosha', vedic_jaimini_chara_karakas states 'same algorithm as /karakas', and vedic_compatibility_manglik_check states 'same canon as /vedic/doshas/parashara/mangal'. Additionally, roughly 50 vedic_dashas_*_{antar,pratyantar,sookshma,prana} tools share nearly identical boilerplate descriptions distinguishable only by cascade depth, making misselection likely.

The bulk follows a disciplined domain_prefix_specific snake_case convention (vedic_dashas_<system>_<level>, numerology_<system>_<number>, hellenistic_<tradition>_<technique>, tarot_<deck>_draw_<spread>). Deviations exist — bare core names (chart, planets, houses), dual hd_/ human_design_ prefixes, three spellings of kalasarpa (kaal_sarp/kalasarpa/kalsarpa), and the acg abbreviation — but they are minor relative to the 633-tool surface.

633 tools is an extreme mismatch for any MCP server, far past the 50+ threshold. Even a genuinely comprehensive astrology API would overwhelm agents with this many endpoints; the surface should be split into per-domain servers (vedic, tarot, numerology, human design, etc.) to be navigable.

Coverage across the declared multi-tradition domain is unusually deep: multiple dasha systems at 5 cascade levels, vargas D1-D60, Shadbala components, dosha detectors, muhurta scanners, synastry/report/AI interpretation layers. Minor gaps exist — placeholder Lal Kitab planet-house data, zeroed Shadbala sub-scores, deprecated endpoints, deferred Jaimini yogas — but agents can work around them.