Loading ToolBench
MCP server for the Immanuel Python astrology library, exposing chart generation and configuration functionalities as MCP tools with error handling and validation
Server defines 6 astrological tools with mostly complete schemas and descriptions. Naming is clear and action-oriented (generate_*, get_*). Descriptions are detailed and contextual, averaging 180-220 characters, above the 194-char baseline. All tools are READ_ONLY with documented behavior. Schemas are well-formed with typed parameters and descriptions. However, output schemas are NOT documented, callers cannot see what fields to expect from natal charts, lunations, or transits. Error handling is minimal; no recovery guidance or error categorization visible in tool definitions. Tools lack input validation constraints (e.g., house_system enum, min/max for count). Some parameter relationships undocumented (e.g., timezone inference from coordinates). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all being read-only. Per-tool averages range from 58-68; consistent 'B' grade quality.
Generates a compact natal chart with essential information. This tool provides a streamlined version of the natal chart, focusing on the most critical astrological data: major celestial objects, their positions, and major aspects. It omits more detailed data like weightings and chart shape for a faster and more concise output.
Calculate lunar return chart for specified month/year. A lunar return occurs when the Moon returns to its natal position, happening approximately every 27-28 days. This is a monthly predictive technique showing themes and energies for the coming month. Return charts are conventionally cast for where the person is at the return moment, not the birthplace: pass return_latitude/return_longitude to relocate. The return moment itself (found by ephemeris search from the birth-location natal Moon) stays identical; only the houses/angles change. Relocated charts report the return moment in the return location's zone.
Generates a natal (birth) chart for a specific person or event.
Get a simplified summary of key chart information.
List upcoming new moons, full moons and eclipses from a given moment. Lunations mark the monthly cycle of beginnings (new moon) and culminations (full moon); eclipses are the lunations that fall near the nodes and carry a longer arc of influence.
Output schemas not documented. Callers cannot see what fields natal charts, ingresses, lunations, or return charts return. LLMs cannot extract relevant fields or plan downstream operations without discovering output structure through trial.
generate_natal_chart has minimal description (12 characters: 'Generates a natal (birth) chart for a specific person or event.'). Description does not distinguish it from generate_compact_natal_chart, LLM cannot determine when to use which.
Parameters lack constraint enums and validation hints. house_system accepts arbitrary strings instead of enum (CAMPANUS, PLACIDUS, WHOLE_SIGN, etc.). count parameter has no min/max bounds, LLM could pass 999 or -1. timezone lacks hint that IANA names are required, not arbitrary strings.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
List the dates on which planets change zodiac sign, from a given moment. An ingress marks a shift in the tone of a planet's expression, and for the slow bodies it opens a chapter lasting years. Retrograde re-entries are included: a planet often crosses a sign boundary three times before it settles, and all three crossings are listed in date order.
No tool annotations despite all tools being read-only. Tools should include 'readOnlyHint: true' in metadata to signal to agents/clients that these operations are safe for retry and logging.
Error handling not visible in tool definitions. No indication of what errors can occur (invalid date format, timezone not found, invalid coordinates), what recovery steps are available, or whether errors are retryable.
Undocumented parameter relationships. timezone parameter states 'inferred from coordinates if omitted' but coordinates parameter doesn't explain how it infers timezone. count parameter in get_sign_ingresses states 'How many ingresses to return per planet (1-24)' but upper bound is not enforced as schema constraint.
get_lunations_and_eclipses accepts optional latitude/longitude/timezone for 'local-time column' but semantics unclear. Does this relocate the ephemeris? Does it only affect display? Dependencies between these params undocumented.