Human Design MCP Server by RoxyAPI

Generate Human Design transit overlay - Current planetary activations on a natal bodygraph

post_human_design_transit

Read-only

Overlay the current or any given planetary positions on a natal Human Design bodygraph to see which channels the transit temporarily completes. Returns the 13 transiting body activations with gate and line, the channels the transit completes beyond the natal definition split into personal channels where the transit supplies the partner gate of a natal gate and educational channels where the transit supplies both gates, the natally open centers those channels temporarily define, and a short factual summary. A transit is a single moment, so there is no Design side. When date and time are omitted the overlay is computed for now in UTC. Built for daily Human Design apps, transit widgets, and notification tools.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`date`	No	Transit date in YYYY-MM-DD UTC. Optional. Defaults to today in UTC when omitted, giving the just-now transit.
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`time`	No	Transit time in HH:MM:SS UTC. Optional. Defaults to the current UTC time when omitted. Precision matters: the Moon moves through a gate in roughly half a day.
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
`birthData`	Yes	Birth moment whose natal bodygraph the transit is overlaid on.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already mark the tool as read-only and non-destructive. The description adds non-obvious behavioral facts: a transit has no Design side, date/time omission computes for now in UTC, and the finished bodygraph reports personal versus educational channels. This goes beyond the annotation safety profile.

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?

The description front-loads the core verb and resource, then delivers return categories and key constraints in dense, purposeful sentences. There is no filler or tautology. The length is justified by the absence of an 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?

Given the absence of an output schema, the description reasonably summarizes the main output categories: 13 transiting activations, completed channels, personal/educational split, natally open centers, and summary. It covers default behavior and the no-design-side nuance. It does not spell out every output field, but it is complete enough for an model to invoke correctly.

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 the input schema already explains every parameter including defaults, formats, timezone semantics, and the compact shape. The description adds only minor reinforcement about UTC defaults and no-Design-side behavior, but does not need to add much because the schema is rich.

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: 'Overlay the current or any given planetary positions on a natal Human Design bodygraph'. It further distinguishes this from siblings by emphasizing the transit moment semantics and explicitly noting there is no Design side. This makes the tool's role clear relative to composite or natal chart tools.

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?

The description explains the intended use ('Built for daily Human Design apps, transit widgets, and notification tools') and states the core choice criteria: overlay a transit on a natal chart. It does not explicitly list alternatives to avoid, but the sibling differentiation is strong enough that an agent can infer when to use this over the connection tool.

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

All Human Design MCP Server by RoxyAPI tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation3/5

The static reference tools are clearly distinct, and connection, transit, and penta handle unique types of analysis. However, the full bodygraph endpoint already returns type, profile, centers, gates, and channels, so the component-specific calculation endpoints create moderate selection ambiguity.

Naming Consistency4/5

The tools follow a clear post_human_design_ / get_human_design_ pattern, with get_ reserved for reference lookups and post_ used for calculations. The pattern is slightly inconsistent because the two reference tools add _id and _number suffixes, while the calculation tools use plain plural resource names.

Tool Count4/5

Twelve tools is within a reasonable scope and covers the broad Human Design domain, including basic charts, transit, compatibility, and group analysis. The count is slightly higher than strictly necessary because several partial-looking endpoints duplicate the data already returned by the full bodygraph endpoint.

Completeness5/5

The server covers the full core chart generation flow, reference data for centers and gates, profile, type, variables, transit overlays, connection charts, and group connections. There are no obvious dead ends for Human Design apps and a reading or coaching workload seems well supported.

Resources

Need Help?