Natal Chart Lab MCP

Birth chart planet signs

get_birth_placements

Read-only

Computes Sun, Moon and planet signs from a local birth date, clock time and UTC offset. Use it for sign placements only; rising sign and houses require the birth place.

Instructions

Sun, Moon and planet signs for a local birth date and clock time. Give the UTC offset that was in force at the birth (including daylight saving). Does not compute the rising sign or houses, which need the birth place; the result links to the free full calculator.

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": {
      "date": "<date>",
      "time": "<time>",
      "utc_offset": "<utc_offset>"
    },
    "name": "get_birth_placements"
  }
}

Input Schema

Name	Required	Description
`date`	Yes	Birth date, YYYY-MM-DD
`time`	Yes	Local clock time, HH:MM 24-hour. Use 12:00 if unknown (the Moon may then be off by a sign).
`utc_offset`	Yes	UTC offset at the birth, e.g. -05:00, +01:00, +05:30

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 14, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine behavioral context on top: the deliberate omission of the ascendant and houses, the reason for the omission, and the fact that results link out to a fuller calculator.

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?

Two sentences, front-loaded with the capability, followed by the input requirement and the limitation. No filler, though the trailing 'links to the free full calculator' phrasing is slightly promotional rather than purely functional.

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?

With three required params, no output schema, and a flat input shape, the description covers what an agent needs: inputs, the DST subtlety, and what the result contains (signs plus a link). It does not specify the response structure, but the pointer to linked output is adequate for a no-output-schema tool.

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% and the schema itself already explains the HH:MM default and its effect on the Moon, so the baseline would be 3. The description adds real meaning for utc_offset — 'the offset in force at the birth (including daylight saving)' — which clarifies a genuine ambiguity the schema's bare 'UTC offset at the birth' leaves open.

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

Purpose4/5

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

States a specific resource and scope: 'Sun, Moon and planet signs for a local birth date and clock time.' An agent can tell this is a natal-chart sign lookup rather than a current-sky or transit tool. It stops short of naming which sibling to prefer, so 4 rather than 5.

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

Usage Guidelines4/5

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

Gives clear when-to-use context (a birth date and clock time) and an explicit exclusion: it does not compute the rising sign or houses, which need the birth place. It also points to the free full calculator as the fallback, which functions as an alternative route, though no sibling tool is named.

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

Deploy Server