Skip to main content
Glama
Sign In
HellenicStar Astrology MCP Server

HellenicStar Astrology MCP Server

by qingxiayi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

render_jones_pattern

Read-onlyIdempotent

Renders a 720px PNG Jones distribution ring from exact birth data, showing occupied fans, longitude dots, angles, and boundary status for whole-chart pattern analysis.

Instructions

Render a 720px PNG Jones distribution ring: ten planetary glyphs, occupied fans, true-longitude dots, gap, angles and focus points, with pattern and boundary status. Use for the whole-chart distribution visual; use render_natal_chart for a standard natal wheel or calculate_classical_factors for Jones classification alongside classical factors. Requires exact local birth date/time and confirmed birthplace location_id. Boundary cases are not a unique psychological diagnosis. 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.
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. Changed7 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 / 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 already declare a safe read-only, idempotent, closed-world operation, and the description adds substantial context beyond them: it calculates and validates its own source with no prior call needed, returns an inline MCP PNG, has no public URL over stdio and requires image-content client support. It also specifies failure behavior precisely (needs_clarification on missing inputs, error without an image on invalid input).

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-loads the render output and contents before routing and caveats, and every clause carries information. It is dense and long for a single paragraph, but no sentence is filler.

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?

With no output schema, the description still covers the return value (inline PNG), the transport constraint, the no-precalculation shortcut, and both failure modes. Nothing an agent needs to invoke and interpret this tool is missing.

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 meaning is already documented; the description's contribution is elevating the requirement level ('requires exact local birth date/time and confirmed birthplace location_id') even though the schema marks all seven params optional. It adds no further syntax detail, which is fine given the schema's completeness.

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+resource ('Render a 720px PNG Jones distribution ring') and enumerates the visual contents (glyphs, fans, longitude dots, gap, angles, focus points). It explicitly contrasts itself with render_natal_chart and calculate_classical_factors, so an agent can separate it from siblings without opening the schema.

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?

Gives an explicit when-to-use ('whole-chart distribution visual') and names two alternatives with the conditions that select them. It also states prerequisites (exact local birth date/time plus confirmed birthplace location_id) and warns that boundary cases are not a diagnosis.

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