Zodiac Compatibility

Birth chart

get_birth_chart

Read-onlyIdempotent

Returns a tropical birth chart with whole-sign houses: the Sun, Moon and rising signs, each planet's sign, degree and house, the Ascendant and Midheaven, and up to ten of the tightest major aspects. Without a birth time the planets keep every sign possible that day and the houses and angles are omitted.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "birthDate": "<birthDate>"
    },
    "name": "get_birth_chart"
  }
}

Input Schema

Name	Required	Description
`place`	No	A city from the website's list of 67 places, in any letter case, such as London, New York, Tokyo, Sydney or Mumbai.
`latitude`	No	Birthplace latitude in degrees, north positive.
`timeZone`	No	An IANA time zone name such as Europe/London, used instead of a city's zone.
`birthDate`	Yes	Birth date as YYYY-MM-DD, from 1900 to 2100.
`birthTime`	No	Local birth time as HH:MM on a 24-hour clock. Without it the chart keeps every sign possible that day.
`longitude`	No	Birthplace longitude in degrees, east positive.

Output Schema

Name	Required	Description	Default
`item`	Yes
`view`	Yes
`request`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower, and the description still adds real behavioral content: the tropical zodiac and whole-sign house system (a method choice that materially changes results), the cap of ten tightest major aspects, and the degraded output when birthTime is missing. What it does not cover is how an unresolvable 'place' is handled or whether latitude/longitude plus timeZone can replace a city, which matters for a tool with a fixed 67-place list.

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

Conciseness5/5

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

Two dense sentences with no filler: the first front-loads the output contract, the second front-loads the only significant edge case. Every clause carries information an agent would otherwise have to infer from the output schema.

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

Completeness4/5

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

An output schema exists, so the description needn't fully specify return shape, and it still summarizes the key contents plus the no-birth-time degradation. The remaining gap is input-resolution behavior — what happens when 'place' is not one of the listed cities and whether coordinates are a full substitute — which is relevant given the tool's dependence on a fixed place list.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including the YYYY-MM-DD and HH:MM formats, the 67-place constraint, and the meaning of latitude/longitude signs. The description reinforces only the birthTime semantics ('keeps every sign possible that day'), which the schema already states, and adds no new detail on place versus coordinates precedence. Baseline 3 is appropriate.

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?

The description opens with a specific verb and resource ('Returns a tropical birth chart with whole-sign houses') and then enumerates exactly what the chart contains: Sun, Moon and rising signs, each planet's sign/degree/house, Ascendant, Midheaven, and up to ten tightest major aspects. That enumeration implicitly separates it from the single-sign siblings such as find_sun_sign or find_rising_sign, which return one datum rather than a full chart.

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

Usage Guidelines3/5

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

Usage is only implied: the enumeration of chart contents tells an agent this is the comprehensive option versus the single-sign siblings, but no sibling is named and there is no explicit 'use this when / don't use this when' statement. The one decision-relevant rule given is the birth-time condition ('Without a birth time ... the houses and angles are omitted'), which is genuinely useful for choosing whether to ask the user for a time, but it is framed as output behavior rather than guidance.

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

All Zodiac Compatibility tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.