Open Ephemeris

Human Design Transit Overlay

explore_human_design_transit

Read-only

Compute live Human Design transits for a bodygraph and see which gates, channels, and centers the current sky activates, now or at a chosen datetime.

Instructions

Use this when the user asks 'what are today's Human Design transits for me', 'what gates are being activated for me right now' or 'how is the current sky affecting my bodygraph'. Returns an interactive overlay bodygraph (inline in Claude and ChatGPT; text summary elsewhere) with the channels the transit completes and centers it defines, now or at a chosen datetime. Birthplace may be a place name (location).

CREDIT COST: 5 credits per call (chart 3 + render 2; +1 per place name). Human Design was originated by Ra Uru Hu; Open Ephemeris is an independent calculation service, not affiliated with Jovian Archive.

Input Schema

Name	Required	Description
`theme`	No	Set by the embedded app. Default dark.
`layout`	No	Set by the embedded app. Default graph.
`datetime`	Yes	Natal birth: ISO 8601 with a required zone, or local time with `timezone`.
`latitude`	No	Natal latitude (optional with `location`).
`location`	No	Natal place name, e.g. 'New York, NY'; geocoded. Give this or lat/lon.
`timezone`	No	IANA zone for a local birth time.
`longitude`	No	Natal longitude (optional with `location`).
`render_token`	No	Set by the embedded app.
`transit_datetime`	No	ISO 8601; must include Z/offset. Default now.

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv4.29.0Oct 28, 2026

changedInput schema / properties / datetime / description

Previous value: -"Natal birth datetime, ISO 8601 (e.g. '1990-04-15T19:30:00Z'). Must include 'Z' or an offset, or be a local time given with timezone. HD is time-sensitive to the minute."New value: +"Natal birth: ISO 8601 with a required zone, or local time with `timezone`."

changedInput schema / properties / latitude / description

Previous value: -"Natal birth latitude in decimal degrees (positive = North). Optional if `location` is a place name — the resolver fills it in."New value: +"Natal latitude (optional with `location`)."

changedInput schema / properties / layout / description

Previous value: -"Overlay composition. 'graph' (default) is the classic bodygraph rectangle with the transit's activated channels highlighted; 'mandala' nests the same overlay inside the concentric ring set the natal chart uses. Supplied by the in-iframe layout toggle."New value: +"Set by the embedded app. Default graph."

changedInput schema / properties / location / description

Previous value: -"Natal birth location as a plain place name like 'New York, NY'; the server resolves it to coordinates and timezone (ambiguous names are rejected with a disambiguation hint). If neither location nor lat/lon is supplied the call is rejected."New value: +"Natal place name, e.g. 'New York, NY'; geocoded. Give this or lat/lon."

changedInput schema / properties / longitude / description

Previous value: -"Natal birth longitude in decimal degrees (positive = East). Optional if `location` is a place name."New value: +"Natal longitude (optional with `location`)."

changedInput schema / properties / render_token / description

Previous value: -"Supplied by the embedded app when it re-renders a chart it already paid for (e.g. to match the host's light/dark theme)."New value: +"Set by the embedded app."

changedInput schema / properties / theme / description

Previous value: -"Visual theme for the overlay bodygraph. Supplied by the embedded app to match the host; defaults to dark."New value: +"Set by the embedded app. Default dark."

changedInput schema / properties / timezone / description

Previous value: -"IANA timezone for the birth location (e.g. 'America/New_York')."New value: +"IANA zone for a local birth time."

changedInput schema / properties / transit_datetime / description

Previous value: -"Transit moment, ISO 8601; must include 'Z' or an offset. Defaults to now (UTC) when omitted."New value: +"ISO 8601; must include Z/offset. Default now."

Changed5 schema fields changedv4.24.2Oct 24, 2026

changedInput schema / properties / datetime / description

Previous value: -"Natal birth datetime, ISO 8601 (e.g. '1990-04-15T19:30:00Z'). Include 'Z' or an offset, or supply timezone for local time. HD is time-sensitive to the minute."New value: +"Natal birth datetime, ISO 8601 (e.g. '1990-04-15T19:30:00Z'). Must include 'Z' or an offset, or be a local time given with timezone. HD is time-sensitive to the minute."

changedInput schema / properties / layout / description

Previous value: -"Overlay composition. 'graph' (default) is the classic bodygraph rectangle with the transit's activated channels highlighted; 'mandala' nests the same overlay inside the concentric ring set the natal chart uses. Set by the in-iframe layout toggle, never by the model."New value: +"Overlay composition. 'graph' (default) is the classic bodygraph rectangle with the transit's activated channels highlighted; 'mandala' nests the same overlay inside the concentric ring set the natal chart uses. Supplied by the in-iframe layout toggle."

changedInput schema / properties / location / description

Previous value: -"Natal birth location. Prefer a plain place name like 'New York, NY' — the server resolves it via the same lookup `location_search` uses (unambiguous names → coords + timezone; ambiguous names throw with a disambiguation hint). If neither location nor lat/lon is supplied the call is rejected — no silent 0°N 0°E charts."New value: +"Natal birth location as a plain place name like 'New York, NY'; the server resolves it to coordinates and timezone (ambiguous names are rejected with a disambiguation hint). If neither location nor lat/lon is supplied the call is rejected."

addedInput schema / properties / render_token

Added value: +{
+  "description": "Supplied by the embedded app when it re-renders a chart it already paid for (e.g. to match the host's light/dark theme).",
+  "type": "string"
+}

changedInput schema / properties / theme / description

Previous value: -"Visual theme for the overlay bodygraph. Set automatically by the embedded app to match the host; defaults to dark. You normally never need to pass this."New value: +"Visual theme for the overlay bodygraph. Supplied by the embedded app to match the host; defaults to dark."

Addedv4.8.0Aug 3, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Adds real context beyond the annotations: exact credit cost per call with a breakdown and a per-place-name surcharge, the render form differing by host (inline in Claude/ChatGPT vs text summary), and a provenance/affiliation disclaimer. Annotations already cover safety (readOnly, non-destructive), so pricing and output-modality disclosure are the right additional layer.

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 trigger conditions and the return value in the first two sentences, then isolates cost and attribution in a separate block. Slightly dense but no sentence is wasted; the credit breakdown is arguably more detail than an agent needs at selection time.

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 9 parameters but only 1 required, and several set by the embedded app, the description correctly tells the agent what it gets back and what it costs, which is what's non-obvious. No output schema exists, so explaining the output modality (interactive overlay vs text summary) is necessary and is done.

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 coverage is 100%, so parameters are already documented, and the description only restates that birthplace may be given as a place name via `location`. It adds no guidance on the required `datetime` vs optional `transit_datetime` interaction or on the app-set params (render_token, theme, layout). Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Names an explicit resource (transit overlay bodygraph) and describes the output precisely: channels the transit completes and centers it defines, at now or a chosen datetime. The example user questions make the intent unmistakable. It does not name the sibling it differs from (human_design_transit_timeline / explore_human_design), which keeps it just short of a 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?

"Use this when the user asks..." gives three concrete trigger phrasings, which is strong positive guidance. However, there are no exclusions or explicit alternatives (e.g., use human_design_transit_timeline for a multi-day range, explore_human_design for the natal chart), so an agent still has to infer boundaries from sibling names.

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

Deploy Server

Human Design Transit Overlay

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools