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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`date`	Yes
`time`	Yes
`summary`	Yes
`timezone`	Yes
`activations`	Yes
`temporaryCenters`	Yes
`completedChannels`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "activations": {
+      "items": {
+        "properties": {
+          "body": {
+            "type": "string"
+          },
+          "bodyLocalized": {
+            "type": "string"
+          },
+          "gate": {
+            "type": "number"
+          },
+          "gateName": {
+            "type": "string"
+          },
+          "gateNameLocalized": {
+            "type": "string"
+          },
+          "ichingHexagram": {
+            "properties": {
+              "english": {
+                "type": "string"
+              },
+              "number": {
+                "type": "number"
+              }
+            },
+            "required": [
+              "number",
+              "english"
+            ],
+            "type": "object"
+          },
+          "line": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "body",
+          "gate",
+          "line",
+          "gateName",
+          "ichingHexagram"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "completedChannels": {
+      "items": {
+        "properties": {
+          "centers": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "circuit": {
+            "type": "string"
+          },
+          "circuitLocalized": {
+            "type": "string"
+          },
+          "gateA": {
+            "type": "number"
+          },
+          "gateB": {
+            "type": "number"
+          },
+          "kind": {
+            "type": "string"
+          },
+          "kindLocalized": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "nameLocalized": {
+            "type": "string"
+          },
+          "natalGates": {
+            "items": {
+              "type": "number"
+            },
+            "type": "array"
+          },
+          "transitGates": {
+            "items": {
+              "type": "number"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "gateA",
+          "gateB",
+          "name",
+          "circuit",
+          "centers",
+          "kind",
+          "natalGates",
+          "transitGates"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "date": {
+      "type": "string"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "temporaryCenters": {
+      "items": {
+        "properties": {
+          "id": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "nameLocalized": {
+            "type": "string"
+          },
+          "temporarilyDefined": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "temporarilyDefined"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "time": {
+      "type": "string"
+    },
+    "timezone": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "date",
+    "time",
+    "timezone",
+    "activations",
+    "completedChannels",
+    "temporaryCenters",
+    "summary"
+  ],
+  "type": "object"
+}

Changed1 schema field changedSep 16, 2026

changedInput schema / properties / birthData / properties / timezone / description

Previous value: -"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error."New value: +"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."

Changed2 schema fields changedAug 25, 2026

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"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."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changed1 schema field changedAug 23, 2026

changedInput schema / properties / birthData / properties / nodeType / description

Previous value: -"Lunar node convention. \"mean\" is the smoothed average node, which always moves retrograde; \"true\" is the osculating node, which tracks the real perturbed node, oscillates up to about 1.5 degrees either side of the mean on a 173-day cycle, and can briefly turn direct. Neither is more correct and they almost always fall in the same sign. Applies to the North and South Node activations. True is what professional Human Design software uses (HumanDesign.ai, Total Human Design) and is the value RoxyAPI verifies against, so leave it unset for a standard chart. It matters only when a node sits on a gate boundary, where the choice can move a node gate and, rarely, change the completed channels and therefore the type, authority or definition. If another calculator shows a different type, it is almost certainly using the mean node: pass \"mean\" to match it. Defaults to \"true\"."New value: +"Lunar node convention. \"mean\" is the smoothed average node, which always moves retrograde; \"true\" is the osculating node, which tracks the real perturbed node, oscillates up to about 1.5 degrees either side of the mean on a 173-day cycle, and can briefly turn direct. Neither is more correct and they almost always fall in the same sign. Applies to the North and South Node activations. True is what professional Human Design software uses (HumanDesign.ai, Total Human Design) and is the value RoxyAPI verifies against, so leave it unset for a standard chart. It matters only when a node sits on a gate boundary, where the choice moves a node gate. Because a gate can be half of a channel, that can change the completed channels and, with them, whether a center reads defined or open, plus the definition, authority, profile or type. A chart where only one center disagrees is the usual shape, since the type and profile often survive unchanged. If another calculator disagrees on any of those, it is almost certainly using the mean node: pass \"mean\" to match it. Defaults to \"true\"."

Changed2 schema fields changedAug 17, 2026

addedInput schema / examples

Added value: +[
+  {
+    "birthData": {
+      "date": "1990-07-15",
+      "time": "13:00:00",
+      "timezone": "America/New_York"
+    }
+  }
+]

changedInput schema / properties / compact / description

Previous value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"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."

Changed1 schema field changedAug 10, 2026

changedInput schema / properties / birthData / properties / nodeType / description

Previous value: -"Lunar node convention for the North and South Node activations. Leave unset (or \"true\") for the standard Human Design chart: \"true\" is the osculating node used by professional Human Design software (HumanDesign.ai, Total Human Design) and is the value RoxyAPI verifies against. Pass \"mean\" to match a calculator that uses the smoothed mean node (the traditional Western-astrology default, common in free chart tools). The two agree on almost every chart; they diverge by up to ~1.75 degrees only when a node sits on a gate boundary, where the choice can move a node gate and, rarely, change the completed channels and therefore the type, authority, or definition. If another calculator shows a different type, it is likely using the mean node: pass \"mean\" to match it."New value: +"Lunar node convention. \"mean\" is the smoothed average node, which always moves retrograde; \"true\" is the osculating node, which tracks the real perturbed node, oscillates up to about 1.5 degrees either side of the mean on a 173-day cycle, and can briefly turn direct. Neither is more correct and they almost always fall in the same sign. Applies to the North and South Node activations. True is what professional Human Design software uses (HumanDesign.ai, Total Human Design) and is the value RoxyAPI verifies against, so leave it unset for a standard chart. It matters only when a node sits on a gate boundary, where the choice can move a node gate and, rarely, change the completed channels and therefore the type, authority or definition. If another calculator shows a different type, it is almost certainly using the mean node: pass \"mean\" to match it. Defaults to \"true\"."

Changed1 schema field changedJul 22, 2026

changedInput schema / properties / compact / description

Previous value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."

Changed1 schema field changedJul 22, 2026

addedInput schema / properties / compact

Added value: +{
+  "default": false,
+  "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.",
+  "type": "boolean"
+}

Changed1 schema field changedJul 16, 2026

addedInput schema / properties / birthData / properties / nodeType

Added value: +{
+  "default": "true",
+  "description": "Lunar node convention for the North and South Node activations. Leave unset (or \"true\") for the standard Human Design chart: \"true\" is the osculating node used by professional Human Design software (HumanDesign.ai, Total Human Design) and is the value RoxyAPI verifies against. Pass \"mean\" to match a calculator that uses the smoothed mean node (the traditional Western-astrology default, common in free chart tools). The two agree on almost every chart; they diverge by up to ~1.75 degrees only when a node sits on a gate boundary, where the choice can move a node gate and, rarely, change the completed channels and therefore the type, authority, or definition. If another calculator shows a different type, it is likely using the mean node: pass \"mean\" to match it.",
+  "enum": [
+    "mean",
+    "true"
+  ],
+  "example": "true",
+  "type": "string"
+}

Changed3 schema fields changedJul 12, 2026

changedInput schema / properties / birthData / properties / timezone / anyOf

Previous value: -[
-  {
-    "maximum": 14,
-    "minimum": -14,
-    "type": "number"
-  },
-  {
-    "pattern": "^[A-Za-z_]+(?:\\/[A-Za-z0-9_+-]+){0,2}$",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "maximum": 14,
+    "minimum": -14,
+    "type": "number"
+  },
+  {
+    "type": "string"
+  }
+]

changedInput schema / properties / birthData / properties / timezone / description

Previous value: -"Decimal hours (e.g. 5.5 for IST, -5 for EST) OR IANA name (e.g. \"America/New_York\", \"UTC\"). IANA is resolved to the DST-correct offset for the request date. Invalid timezones return 400 with a validation error."New value: +"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error."

changedInput schema / properties / birthData / properties / timezone / example
```
Previous value: -5.5New value: +"America/New_York"
```

First observedJul 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already mark it read-only and non-destructive; the description adds meaningful behavioral context beyond this: the transit is a single moment with no Design side, omitted date/time default to now in UTC, the completed channels are classified into personal vs educational, and opened centers are reported. This gives the agent a solid model of what the operation does and does not compute.

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?

The description is front-loaded with action and purpose, and every sentence carries information. However, the returns sentence is a long, dense list that could be more scannable. It is efficient overall, but not as crisp as a two-sentence high-value description.

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?

For a tool with nested parameters, an output schema, and 100% schema coverage, the description supplies the remaining context an agent needs: what the transit overlay returns, the absence of a Design side, the UTC default behavior, and typical use cases. No important usage detail 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 description coverage is 100% and every parameter, including nested birthData fields, already has detailed descriptions and examples. The description adds meaningful value beyond the schema by clarifying that a transit has no Design side and therefore requires only one birth moment, plus reinforcing that date/time default to the current UTC moment.

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-resource pair ('Overlay ... planetary positions on a natal Human Design bodygraph') and then enumerates exactly what is returned: 13 transiting activations, personal vs educational completed channels, defined open centers, and a factual summary. This clearly distinguishes it from sibling bodygraph, connection, and channel 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?

It states its intended contexts ('Built for daily Human Design apps, transit widgets, and notification tools') and frames the operation as a current-or-arbitrary-date transit overlay. However, it never explicitly says when to prefer another sibling tool such as post_human_design_connection or post_human_design_bodygraph, so exclusions and alternatives are left to inference.

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

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.

Resources

Need Help?