78 astrology calculations, Tarot, symbolic readings and Vedic calendars via two scoped MCP tools.
Scored across 2 tools
The two tools are broadly separable (live calculation vs. symbolic/divinatory work), but the boundary is muddied because the 'symbolic' tool also performs 'supplemental Vedic calculation', so 'calculate' appears in both scopes. An agent choosing between a natal chart calculation and a Vedic calculation has no clear rule.
Both names share the same server prefix and snake_case style, which is predictable. However, the suffixes mix a verb ('calculate') with an adjective/noun ('symbolic'), so the pattern isn't a uniform verb_noun convention.
Two tools are far too few for a surface that spans ephemeris calculations, Tarot draws, symbolic readings, and Vedic calculations. Each tool is a mega-operation bundling many unenumerable capabilities, leaving the agent to guess what a 'calculation' or 'symbolic' request will actually do.
The descriptions explicitly flag dead ends: no access to private saved readings or account PDFs, and no way to list prior draws or check quota/key-budget status despite heavy emphasis on credits and quotas. There is no discoverability of available operations or routes, so agents cannot plan beyond a single call.
Run one live Cosmic Ephemeris calculation. The supplied API key must permit the selected operation. Each admitted call uses the route's normal quota and key-budget accounting; do not automatically retry failures.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The exact JSON body for the selected operation at https://cosmicephemeris.com/openapi.json. Standard civil dates: 1800–2200. Explicit historical date objects: 1000 BCE–2500 CE on all 77 date-bearing operations; require a proleptic calendar and, for timed calculations, UT1 or fixed UT1 offset. Numerology requires an explicit year_convention; place-search is date-independent. See https://cosmicephemeris.com/docs.html#historical-dates. Never guess a calendar, timezone, or birth time. Tarot and supplementary Vedic/readings operations use the separate cosmicephemeris_symbolic tool. | |
| operation | Yes | Live Cosmic Ephemeris calculation operation, without the /api/astro/ prefix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses auth requirements (key must permit the operation), quota and key-budget accounting, and a retry prohibition. It omits whether calculations are read-only/no-side-effect, what a failure or quota-exhaustion response looks like, and whether calls are metered per-route, leaving meaningful gaps for a gateway to 77 operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action, and every sentence carries operational substance (auth, quota, no-retry). Minor deduction because the quota/budget sentence is somewhat dense while higher-value context, such as what a call returns, is absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description says nothing about the shape or variability of results across 77 operations. For a complex multi-operation gateway with nested input and no annotations, this is adequate but leaves the agent guessing about response form and failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema text is unusually rich (date ranges, calendar conventions, the /api/astro/ prefix, redirection to the symbolic tool). The description adds nothing about `operation` or `input`, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Run one live Cosmic Ephemeris calculation.' An agent can tell this is the live-calculation gateway. It does not itself distinguish the tool from the sibling cosmicephemeris_symbolic; that separation lives only in the input schema, so sibling differentiation is missing from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides operational guidance ('the supplied API key must permit the selected operation', 'do not automatically retry failures') but never says when to choose this tool over cosmicephemeris_symbolic or what to do if the key is rejected. Usage context is implied rather than stated as an explicit when/when-not rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a new Tarot draw, fact-linked symbolic reading, or supplemental Vedic calculation. Each admitted attempt consumes one standard credit; never automatically retry. AI-assisted interpretations are for symbolic reflection, not predictive advice. This tool cannot access private saved readings or account PDFs.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Exact request from https://cosmicephemeris.com/readings-openapi.json. Use explicit user choices for locale, tradition, calendar, region and birth inputs. Historical dates require calendar and UT1 conventions. Tarot draws are random; daily draws require an explicit UTC date. Do not invent missing personal data. | |
| operation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=false; the description adds the critical consequence — every admitted attempt costs a credit and must not be retried — which is exactly the context non-idempotency demands. It also discloses scope limits (no private saved readings or account PDFs), though it leaves open whether a failed admission is billed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with what the tool produces before the credit and scope caveats. No filler, though the reading-for-reflection clause and the saved-readings clause could be tightened into one scope sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description never characterizes what a draw, reading, or Vedic result looks like, so the agent cannot anticipate the response. Combined with a nested input object whose authoritative definition lives at an external URL, the definition is adequate but not self-sufficient for a billed, non-idempotent tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 50% schema coverage, the description carries part of the load: the three operation values are echoed in prose, and the nested input parameter's constraints (explicit user choices, calendar/UT1 for historical dates, explicit UTC date for daily draws, no invented personal data) are largely restated from the schema rather than expanded. The instruction to pull the exact request shape from an external OpenAPI URL is not actionable for an agent at call time.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Generate) and enumerates three concrete resources — Tarot draw, fact-linked symbolic reading, supplemental Vedic calculation — which map directly onto the operation enum. It does not explicitly distinguish itself from the sibling cosmicephemeris_calculate, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real usage conditions: each admitted attempt consumes a standard credit, never auto-retry, output is for symbolic reflection rather than predictive advice, and it cannot reach saved readings or account PDFs. What's missing is explicit routing guidance against the sibling calculate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cosmicephemeris_calculatecosmicephemeris_symbolicProfessional Vedic astrology tools for AI agents via MCP.
34-tool Caelus MCP for validated astrology: charts, transits, Vedic, facts, sky view, synthetic.
Official Divine API MCP for Western Astrology: Natal, Synastry, Transit, Composite, Progressions.
Vedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
Add one secure layer between your agents and this server.
