Skip to main content
Glama
Sign In
HellenicStar Astrology MCP Server

HellenicStar Astrology MCP Server

by qingxiayi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

render_transit_biwheel

Read-onlyIdempotent

Creates a PNG transit biwheel with natal planets inside, transiting planets outside, and cross-chart aspects at a chosen moment to compare current transits against an exact natal chart.

Instructions

Render a PNG biwheel with natal positions inside, transiting planets outside and cross-chart aspects at one moment. Use get_transit_snapshot for structured positions/aspects, calculate_transits_to_natal for exact event dates over a range, or render_sky_chart for a standalone sky wheel. Requires exact local birth date/time and confirmed birthplace location_id; moment selects the transit instant, not a second birth. Returns an inline MCP PNG after calculating and validating its source; no prior calculation call is required. stdio has no public image URL and the client must support image content. Missing inputs return needs_clarification without an image; invalid inputs or unavailable rendering return an error without an image.

Input Schema

NameRequiredDescriptionDefault
dayNoBirth day of month, valid for the supplied year and month in the birthplace local civil calendar.
foldNoFor a repeated local time at a DST rollback, ask the user to choose 0 (first occurrence) or 1 (second). Otherwise omit; never guess.
hourNoExact birth hour, 0-23, in birthplace local civil time; do not substitute noon for an unknown time.
yearNoBirth year in the Gregorian calendar, using local civil time at the confirmed birthplace. Required for calculation; do not guess missing birth data.
monthNoBirth month, 1-12, in the birthplace local civil calendar.
minuteNoExact birth minute, 0-59, in birthplace local civil time.
momentNoTransit instant in ISO 8601 with timezone offset, for example 2026-10-25T12:00:00+08:00 or a Z suffix. Omit for now. Distinct from the local civil birth date and time.
location_idNoConfirmed birthplace ID returned by search_birthplace or resolve_birth_coordinates; not a city name. Resolve ambiguous places before calling.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.1.3
    • addedInput schema / properties / day / description
      Added value: +"Birth day of month, valid for the supplied year and month in the birthplace local civil calendar."
    • addedInput schema / properties / fold / description
      Added value: +"For a repeated local time at a DST rollback, ask the user to choose 0 (first occurrence) or 1 (second). Otherwise omit; never guess."
    • addedInput schema / properties / hour / description
      Added value: +"Exact birth hour, 0-23, in birthplace local civil time; do not substitute noon for an unknown time."
    • addedInput schema / properties / location_id / description
      Added value: +"Confirmed birthplace ID returned by search_birthplace or resolve_birth_coordinates; not a city name. Resolve ambiguous places before calling."
    • addedInput schema / properties / minute / description
      Added value: +"Exact birth minute, 0-59, in birthplace local civil time."
    • addedInput schema / properties / moment / description
      Added value: +"Transit instant in ISO 8601 with timezone offset, for example 2026-10-25T12:00:00+08:00 or a Z suffix. Omit for now. Distinct from the local civil birth date and time."
    • addedInput schema / properties / month / description
      Added value: +"Birth month, 1-12, in the birthplace local civil calendar."
    • addedInput schema / properties / year / description
      Added value: +"Birth year in the Gregorian calendar, using local civil time at the confirmed birthplace. Required for calculation; do not guess missing birth data."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover read-only/idempotent/no-destruction; the description adds the parts an agent cannot infer: an inline PNG is returned without a prior calculation call, stdio yields no public image URL so the client must render image content, and missing versus invalid inputs produce different non-image outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the artifact, then routing, then prerequisites, then return behavior. Dense but nearly every clause carries distinct information; a slightly lighter touch on the repeated 'do not guess' emphasis would tighten it without losing content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a rendering tool with no output schema, it covers what comes back (inline PNG), what prevents a result (missing/invalid inputs, unsupported client), and what is needed to start (exact birth date/time, confirmed birthplace, transit moment). Nothing an agent needs is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so field-level docs are already strong, but the description adds a genuinely non-obvious disambiguation: 'moment' is the transit instant, not a second birth date. It also flags that the birth time must be exact and the location must be a confirmed location_id rather than a city name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and artifact: a PNG biwheel with natal positions inside, transiting planets outside, and cross-chart aspects at one moment. It immediately separates itself from the structured-data siblings and from render_sky_chart's standalone wheel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names three alternatives (get_transit_snapshot, calculate_transits_to_natal, render_sky_chart) and the exact condition each one serves, plus the prerequisite chain (search_birthplace / resolve_birth_coordinates) and the clarification path when inputs are missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools