A
licenseNot graded
qualityC
maintenanceCompute Human Design charts, cycle returns, transits, synthesis, and chart comparison natively inside AI assistants.
7 npm
2
MIT
Human Design MCP Server by RoxyAPI
by com.roxyapi
Server Details
Human Design bodygraph, type, authority, profile, gates and channels for AI agents.
Ownership verified
- Status
- Healthy
- Uptime
- 99.9% over 41 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.1/5.0
Scored across 12 tools
Disambiguation4/5
The set separates static reference lookups from birth-time calculations, and the full bodygraph endpoint is clearly marked as the complete one-call option. The focused endpoints (type, profile, centers, channels, gates) overlap with bodygraph payloads but are differentiated by their narrower purpose, so an agent should choose correctly in most cases.
Naming Consistency5/5
Every tool follows a strict snake_case pattern of {get|post}_human_design_<resource>, with get reserving static reference data and post reserving calculation endpoints. The only variation is domain-specific resource nouns like centers_id and gates_number, which remains predictable.
Tool Count5/5
Twelve tools is well within the ideal range for a domain API and each endpoint covers a distinct need: reference, full chart, component calculations, specialized charts, and transit. No tool feels redundant padding.
Completeness4/5
The surface covers full bodygraph generation, all major component calculations, connection, penta, transit, variables, and static reference for centers and gates. A minor gap is the lack of a standalone static channel reference, though post_human_design_channels and gate lookups partially compensate.
Available Tools
12 toolsget_human_design_centers_idLook up a Human Design center by idARead-onlyInspect
Look up the static reference data for one of the nine Human Design centers by its id: the display name, whether it is a motor or awareness center, and what it means both defined and undefined. A pure reference endpoint with no birth data required.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Center id. One of head, ajna, throat, g, heart, sacral, solar-plexus, spleen, root. | |
| 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 |
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| motor | Yes | |
| awareness | Yes | |
| nameLocalized | No | |
| definedMeaning | Yes | |
| undefinedMeaning | Yes |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'static reference data' and 'no birth data required' as useful context, but it does not go beyond that into rate limits, auth, or other behavioral details. This is similar to the calibration example where annotations carry most of the burden.
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 is two sentences with no filler. It front-loads the verb, resource, and scope, then adds only the differentiating 'no birth data required' context. Every sentence earns its place.
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 simple read-only reference lookup, the combination of the description, fully documented input schema, read-only annotations, and output schema is complete. Nothing an agent needs to select and call this tool correctly is missing.
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 the schema already thoroughly documents id, lang, and compact. The description mentions 'by its id' but adds no parameter-specific semantics beyond what the input schema provides.
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 starts with a specific verb and object: 'Look up the static reference data for one of the nine Human Design centers by its id' and then lists the exact returned fields. This clearly distinguishes the tool from gate lookups and POST bodygraph calculators.
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 phrase 'pure reference endpoint with no birth data required' gives clear context for when to use this tool versus the POST calculation endpoints. It stops short of explicitly naming a sibling alternative or stating exclusions, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_human_design_gates_numberLook up a Human Design gate by numberARead-onlyInspect
Look up the static reference data for a Human Design gate by its number from 1 to 64: the gate keynote name, the center it sits in, the matching I-Ching hexagram, and the gates that form a channel with it. A pure reference endpoint with no birth data required.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| number | Yes | Gate number from 1 to 64. | |
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| center | Yes | |
| number | Yes | |
| centerName | Yes | |
| nameLocalized | No | |
| ichingHexagram | Yes | |
| channelPartners | Yes | |
| centerNameLocalized | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false already set, the description adds useful behavioral context: the data is static reference, no birth data is required, and the endpoint is pure rather than computed. There is no contradiction and it supplements the annotations meaningfully, though it does not discuss things like localization fallback which the schema already covers.
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 sentences, zero filler: the first packs the resource, scope, and return contents; the second gives the key usage signal. 'Static reference... no birth data required' earns its place by differentiating from chart-computation siblings.
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?
For a simple read-only lookup tool with an output schema and fully documented parameters, the description covers what matters: what the gate lookup returns and that it is static/no-birth-data. It is slightly less explicit about when to choose it over get_human_design_centers_id, but the returned-domain enumeration makes the boundary clear enough.
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% (number, lang, compact are all documented), so the baseline applies. The description repeats the 1–64 range but does not add new parameter semantics beyond listing what the lookup returns, which is more relevant to the output than to the input parameters.
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 — 'Look up the static reference data for a Human Design gate by its number' — and enumerates the returned fields (keynote name, center, I-Ching hexagram, channel-forming gates). It also distinguishes itself from the post_* siblings by explicitly framing itself as a pure reference endpoint with no birth data required.
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 clearly signals the use case: static gate reference lookup independent of any birth chart data. This gives an agent enough context to prefer it over post_human_design_gates or bodygraph computations, though it does not name an alternative explicitly or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_human_design_bodygraphGenerate full Human Design bodygraph - Type, authority, profile, centers, channels, gatesARead-onlyInspect
Generate a complete Human Design bodygraph from a birth date, time, and timezone. Returns the energy type, strategy, inner authority, signature, not-self theme, profile, definition, incarnation cross, all nine centers with defined state and active gates, the defined channels, and all 26 planetary activations across the Personality and Design sides. The single endpoint for a full chart in one call, built for Human Design apps, readings, and coaching tools.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date in YYYY-MM-DD format. The anchor for both the Personality activations at birth and the Design activations 88 degrees of solar arc earlier. | |
| 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 | Yes | Birth time in 24-hour HH:MM:SS format. Precision matters: the profile lines and gate boundaries shift with the exact minute of birth. | |
| 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| nodeType | No | 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". | true |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| aura | Yes | |
| type | Yes | |
| gates | Yes | |
| sides | Yes | |
| centers | Yes | |
| notSelf | Yes | |
| profile | Yes | |
| channels | Yes | |
| strategy | Yes | |
| authority | Yes | |
| signature | Yes | |
| definition | Yes | |
| typeLocalized | No | |
| profileKeynotes | Yes | |
| typeDescription | Yes | |
| designInstantUtc | Yes | |
| incarnationCross | Yes | |
| notSelfLocalized | No | |
| strategyLocalized | No | |
| authorityLocalized | No | |
| profileDescription | Yes | |
| signatureLocalized | No | |
| definitionLocalized | No | |
| strategyDescription | Yes | |
| authorityDescription | Yes | |
| definitionDescription | Yes |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Generate' / 'Returns' language is consistent with a non-mutating computation. It does not add extra operational traits such as rate limits or authentication, but the annotation coverage lowers the burden here.
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?
Three sentences: the first states the core function, the second summarizes the returned data, and the third gives the use case. It is front-loaded and contains no filler or repetition.
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?
The output schema exists, so return values do not need to be described, and the input schema fully documents every parameter. The description adds the essential selection context — full chart, single call, intended audience — leaving the agent with everything needed to invoke the tool 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?
All eight parameters have detailed schema descriptions at 100% coverage, including defaults, enums, and timezone edge cases. The description only names birth date, time, and timezone at a high level and adds no parameter semantics beyond what the schema already provides.
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 'Generate a complete Human Design bodygraph' — a specific verb plus resource — and enumerates the returned components (type, strategy, authority, profile, centers, channels, gates). 'The single endpoint for a full chart in one call' clearly separates it from the sibling component-specific endpoints.
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 gives a clear intended context: use this when a full chart is needed in one call, 'built for Human Design apps, readings, and coaching tools.' It implies a contrast with component-specific sibling tools but does not name alternatives or state explicit when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_human_design_centersCalculate the nine Human Design centersARead-onlyInspect
Calculate the state of all nine Human Design centers for a birth moment: whether each is defined or open, whether it is a motor or an awareness center, its theme, and the active gates it holds. The data layer behind a rendered bodygraph where defined centers are colored and open centers are white.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date in YYYY-MM-DD format. The anchor for both the Personality activations at birth and the Design activations 88 degrees of solar arc earlier. | |
| 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 | Yes | Birth time in 24-hour HH:MM:SS format. Precision matters: the profile lines and gate boundaries shift with the exact minute of birth. | |
| 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| nodeType | No | 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". | true |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| centers | Yes | |
| definedCount | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the baseline safety profile is covered. The description adds behavioral context beyond that by specifying what the tool returns and positioning it as a pure computation layer behind visualization, with no side effects implied.
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 is two sentences with no filler. The first sentence front-loads the core calculation and output details; the second provides useful rendering context. Every clause earns its place.
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?
Given the output schema, thorough 100% parameter coverage, and read-only annotations, the description fully covers what an agent needs to select and invoke the tool. No critical usage or behavioral information is missing.
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 the schema already documents all eight parameters thoroughly. The description's 'birth moment' phrase loosely maps to the required date/time/timezone parameters but does not add meaning beyond what the schema provides, matching the baseline of 3.
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 uses a specific verb and resource: 'Calculate the state of all nine Human Design centers for a birth moment' and enumerates exact outputs (defined/open, motor/awareness, theme, active gates). It also distinguishes itself from siblings by framing itself as the data layer behind a rendered bodygraph, making its scope clear.
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 gives clear context for when to use the tool: it is the underlying data source for a rendered bodygraph, so an agent can infer it is for center-level data rather than for rendering or channel-level analysis. It does not explicitly name alternatives or exclusions, but the usage context is concrete enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_human_design_channelsCalculate the defined Human Design channelsARead-onlyInspect
Calculate the defined channels for a birth moment. A channel is defined when both of its gates are activated, and it wires together the two centers it connects. Returns each defined channel with its gates, name, circuit family, and connected centers, plus the full set of centers those channels define. Built for bodygraph rendering and definition analysis.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date in YYYY-MM-DD format. The anchor for both the Personality activations at birth and the Design activations 88 degrees of solar arc earlier. | |
| 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 | Yes | Birth time in 24-hour HH:MM:SS format. Precision matters: the profile lines and gate boundaries shift with the exact minute of birth. | |
| 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| nodeType | No | 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". | true |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| channels | Yes | |
| definedCenters | Yes |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond the annotations: it explains the channel definition rule, how channels wire centers, and what the response contains.
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 is tight and front-loaded: purpose first, then the definitional rule, then the return shape, then the intended use. Every sentence earns its place and nothing is redundant with the schema.
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?
Given the detailed input schema, the presence of an output schema, and the read-only annotations, the description is complete. It tells an agent what the tool computes, why it matters, and what it returns, with no critical operational gaps.
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 the parameters are already thoroughly documented, including timezone edge cases and nodeType behavior. The description adds no additional parameter semantics, which is acceptable at the baseline since the schema does the heavy lifting.
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: 'Calculate the defined channels for a birth moment.' It then defines the channel concept and the exact return payload, which clearly distinguishes it from sibling tools like post_human_design_gates or post_human_design_bodygraph.
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?
The closing note 'Built for bodygraph rendering and definition analysis' implies the intended context, but the description never explicitly says when to prefer this over post_human_design_bodygraph or when not to use it. Usage guidance is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_human_design_connectionCalculate Human Design connection chart - Two-person composite bodygraph compatibilityARead-onlyInspect
Calculate a Human Design connection chart by overlaying two bodygraphs. For each of the 36 channels the dynamic between the two people is classified as electromagnetic, dominance, compromise, or companionship, the four mechanics of how two designs meet. Also returns the nine centers as defined or open in the combined bodygraph with which person defines each, the combined definition, and a count of each dynamic. Built for relationship, dating, and coaching tools.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| 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. | |
| personA | Yes | Birth moment of the first person in the connection. | |
| personB | Yes | Birth moment of the second person in the connection. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| centers | Yes | |
| summary | Yes | |
| channels | Yes | |
| totalChannels | Yes | |
| combinedDefinition | Yes | |
| combinedDefinitionLocalized | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail: it specifies exactly what is computed (channel dynamics, center states, combined definition, counts) and notes the output is designed for relationship/dating/coaching, giving the agent context on how results might be used. No contradictions with annotations.
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 is three sentences with zero filler. The main action is front-loaded, followed by a compact enumeration of outputs and a brief use-case note. Every sentence earns its place, and the structure is easy to scan.
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 complexity of a two-person composite chart and the existence of a rich output schema, the description covers the essential outputs (channels, dynamics, centers, definition, counts) and the intended domain. It does not explain the meaning of each dynamic or the combined definition, but the output schema likely carries that detail. Nothing critical is missing for an agent to decide when to call this tool.
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 every parameter (personA, personB, lang, compact) has a detailed description, including the nested birth data fields. The tool description itself adds little beyond confirming the two-person overlay, which is already evident from the personA/personB parameters. This matches the baseline for full schema coverage.
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 ('Calculate a Human Design connection chart by overlaying two bodygraphs'), immediately distinguishing it from single-bodygraph tools like post_human_design_bodygraph and group tools like post_human_design_penta. It then enumerates the exact outputs (36 channels with four dynamics, nine centers, definition, counts), leaving no ambiguity about what the tool produces.
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 states it is 'Built for relationship, dating, and coaching tools,' which signals its intended use case. It does not explicitly contrast with siblings like penta (group) or bodygraph (single), but the phrase 'two-person composite' and 'overlaying two bodygraphs' makes the two-person scope clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_human_design_gatesCalculate the 26 Human Design gate activationsARead-onlyInspect
Calculate the 26 gate activations for a birth moment, split into the 13 conscious Personality activations at birth and the 13 unconscious Design activations 88 degrees of solar arc earlier. Each activation reports the planet, gate, line, gate keynote, and the matching I-Ching hexagram. Built for activation columns and detailed chart views.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date in YYYY-MM-DD format. The anchor for both the Personality activations at birth and the Design activations 88 degrees of solar arc earlier. | |
| 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 | Yes | Birth time in 24-hour HH:MM:SS format. Precision matters: the profile lines and gate boundaries shift with the exact minute of birth. | |
| 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| nodeType | No | 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". | true |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| design | Yes | |
| personality | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the split into 13 conscious and 13 unconscious activations, the 88-degree solar arc offset, and the per-activation fields (planet, gate, line, keynote, hexagram). This goes beyond the annotations and enriches the agent's mental model.
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 sentences with zero filler. The core purpose is front-loaded, the split is explained, and the output fields are listed. Every sentence earns its place.
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?
The description explains what the tool returns (per-activation fields) and its intended use. With an output schema present, the return format is already documented. Nothing critical for invoking the tool correctly is missing; the only minor gap is that it doesn't mention the absence of coordinate influence, but that's covered in the latitude/longitude schema descriptions.
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%, and each parameter has a detailed description in the schema itself. The tool description adds no parameter-specific information, so the baseline of 3 applies – the schema does the heavy lifting.
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?
States a specific verb (calculate) and resource (26 gate activations), and clearly distinguishes itself from siblings like get_human_design_gates_number by describing the full set and the conscious/unconscious split. An agent can immediately tell what this tool does and how it differs from similar tools.
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?
The description says 'Built for activation columns and detailed chart views,' implying a use case, but it never explicitly mentions when to use this tool versus alternatives like get_human_design_gates_number or post_human_design_bodygraph. No exclusions are given, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_human_design_pentaCalculate Human Design Penta - Small-group BG5 operating system for three to five peopleARead-onlyInspect
Calculate the Human Design Penta (BG5, Base Group 5) for a small group of three to five people. The Penta is a trans-auric form built from a fixed set of six channels running only between the Sacral, the G Center, and the Throat. It reports which of the twelve Penta gates are filled and by whom, which of the six channels are defined Strengths, the upper leadership channels versus the lower generative channels, the 2/14 material core, and the functional gaps where no member supplies a role. Built for team, family, and group analysis tools. Below three people no Penta forms and above five a second Penta emerges, so the group size must be three to five.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| 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. | |
| members | Yes | Birth moments of the three to five people in the group. Below three no Penta forms; above five a second Penta emerges. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| gates | Yes | |
| summary | Yes | |
| channels | Yes | |
| memberCount | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations: it explains the fixed set of six channels, the involvement of specific centers, the nature of the output (which gates are filled and by whom, defined Strengths, leadership vs generative channels, material core, gaps), and the group-size boundary. It does not contradict the annotations. This enriches the agent's understanding of what the computation returns and its constraints, though it does not discuss error handling or edge cases beyond group size.
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 is compact and front-loaded with the primary purpose. It then explains the tool's internal logic and outputs in a structured way, and ends with the explicit usage constraint. Every sentence contributes either to purpose, behavior, or usage. There is no redundant filler; the only repetition (group size) is a meaningful reinforcement rather than noise. The structure is clear and efficient.
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?
Given that the tool has an output schema (context signals confirm this), the description need not explain return values. It covers all essential aspects for correct invocation: the group size constraint, the scope of what the Penta computes, and the use case. The lang and compact parameters are self-explanatory in the schema, and the member fields are fully described there. The description is complete for an agent to decide when to call this tool and what to expect.
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?
The schema description coverage is 100% for all three parameters (members, lang, compact), including detailed descriptions for the member sub-fields. The tool description does not add new semantic information about the parameters; it reiterates the group-size constraint already present in the schema's members description. Per the rubric, with high schema coverage the baseline is 3, and the description does not compensate by providing additional parameter usage guidance. It adds no new meaning beyond the schema, so a 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 states a specific verb ('Calculate') and a specific resource ('Human Design Penta for a small group of three to five people'), then enumerates the exact outputs: filled gates, defined channels, strengths, upper/lower channels, material core, and gaps. This clearly distinguishes it from sibling tools that target individual charts (bodygraph, gates, centers) and from the connection tool which presumably handles two-person configurations. No ambiguity remains about what this tool does.
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 gives an explicit usage constraint: the group size must be three to five people, with the reason (below three no Penta forms, above five a second Penta emerges). It also states the intended use case ('Built for team, family, and group analysis tools'). However, it does not explicitly name alternative tools for individual or two-person analyses, leaving the 'when not to use' to inference from the sibling set. This is clear context but lacks an explicit exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_human_design_profileCalculate the Human Design profile and line keynotesARead-onlyInspect
Calculate the Human Design profile for a birth moment: the conscious Personality Sun line over the unconscious Design Sun line, with the keynote for each. The profile is the geometry of the life role, for example 5/1 the Heretic Investigator. Verified against NASA JPL Horizons positions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date in YYYY-MM-DD format. The anchor for both the Personality activations at birth and the Design activations 88 degrees of solar arc earlier. | |
| 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 | Yes | Birth time in 24-hour HH:MM:SS format. Precision matters: the profile lines and gate boundaries shift with the exact minute of birth. | |
| 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| nodeType | No | 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". | true |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| profile | Yes | |
| designLine | Yes | |
| designKeynote | Yes | |
| personalityLine | Yes | |
| personalityKeynote | Yes |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and non-destructive, and the description adds the 'Verified against NASA JPL Horizons positions' accuracy cue plus the calculation formula. It does not disclose any additional behavioral traits such as auth requirements or error conditions, but for a read-only calculation this is an acceptable level.
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 first sentence front-loads the purpose, the second gives a concrete example, and the final verification sentence adds credibility. The structure is efficient, though the NASA JPL verification clause is a nice-to-have rather than essential usage guidance.
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 8-parameter schema with 100% documentation, the read-only annotations, and the presence of an output schema, the description sufficiently anchors the concept and required inputs. It does not need to describe return values, but it could be slightly more complete by referencing when a full chart endpoint would be the better choice.
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 detail (formats, defaults, effects on the bodygraph, timezone handling). The description adds conceptual context about what a profile is, but no parameter-specific detail beyond the schema, so the 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?
States a specific verb ('Calculate'), resource ('Human Design profile'), and the exact composition ('conscious Personality Sun line over the unconscious Design Sun line'), reinforced by the 5/1 Heretic Investigator example. This is enough to distinguish it from sibling charting tools such as type or bodygraph without opening their schemas.
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?
The description gives a clear context ('for a birth moment') but never explicitly tells an agent when to prefer this over a sibling endpoint (e.g., bodygraph, type, connection). Usage is implied by the purpose statement rather than stated with alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_human_design_transitGenerate Human Design transit overlay - Current planetary activations on a natal bodygraphARead-onlyInspect
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.
ParametersJSON 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| time | Yes | |
| summary | Yes | |
| timezone | Yes | |
| activations | Yes | |
| temporaryCenters | Yes | |
| completedChannels | Yes |
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.
post_human_design_typeCalculate Human Design type, authority and profileARead-onlyInspect
Calculate the core Human Design identity from a birth moment: the energy type, the aura strategy, the inner authority, the signature and not-self themes, and the profile. The fast lookup for type-and-authority features without the full bodygraph payload. Verified against NASA JPL Horizons positions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date in YYYY-MM-DD format. The anchor for both the Personality activations at birth and the Design activations 88 degrees of solar arc earlier. | |
| 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 | Yes | Birth time in 24-hour HH:MM:SS format. Precision matters: the profile lines and gate boundaries shift with the exact minute of birth. | |
| 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| nodeType | No | 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". | true |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| aura | Yes | |
| type | Yes | |
| notSelf | Yes | |
| profile | Yes | |
| strategy | Yes | |
| authority | Yes | |
| signature | Yes | |
| typeLocalized | No | |
| typeDescription | Yes | |
| notSelfLocalized | No | |
| strategyLocalized | No | |
| authorityLocalized | No | |
| signatureLocalized | No | |
| strategyDescription | Yes | |
| authorityDescription | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds complementary behavioral context: it is a fast/lighter lookup, omits the full payload, and is 'Verified against NASA JPL Horizons positions,' which signals accuracy. No contradiction with the annotations.
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 tight sentences: the first front-loads the core purpose and outputs, the second adds the fast-lookup positioning and validation claim. No filler or redundancy.
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?
For a tool with rich schema coverage, an output schema, safety annotations, and many siblings, the description is sufficiently complete: it names the computed identity features, the lightweight positioning relative to bodygraph, and a validation guarantee. It could marginally improve by naming the specific sibling tool for full bodygraph requests, but the payload reference is enough to route the agent 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 description coverage is 100%, so the schema fully documents all 8 parameters. The description adds only the general notion of a 'birth moment' and output domains, which is helpful framing but does not add parameter-level meaning beyond the schema.
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?
Uses a specific verb ('Calculate') with a clear resource ('core Human Design identity') and lists the concrete outputs: energy type, aura strategy, inner authority, signature/not-self themes, and profile. It distinguishes itself from the full bodygraph sibling by describing itself as 'the fast lookup ... without the full bodygraph payload.'
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 establishes a clear use case: a fast lookup for type-and-authority features when the full bodygraph payload is not needed. It references the key alternative via 'without the full bodygraph payload,' but it does not explicitly name sibling tools or state when-not-to-use conditions beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_human_design_variablesCalculate Human Design Variables - The four arrows and Color, Tone, Base substructureARead-onlyInspect
Calculate the four Human Design Variable arrows for a birth moment: Determination and Environment on the design side, Perspective and Motivation on the personality side. Each arrow returns its Color, Tone, and Base numbers from the hexagram-line substructure, the left or right direction set by the Tone, and the sourced Color and direction labels. This is the advanced Rave Variables and Primary Health System layer beneath Type, Strategy, Authority, and Profile. Color, Tone, and Base shift with tiny differences in birth time, so each arrow carries a confidence flag that turns false near a Color or Tone boundary, and a precise birth time is essential. Built for Human Design apps offering PHS, diet, environment, and Rave Psychology readings.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date in YYYY-MM-DD format. The anchor for both the Personality activations at birth and the Design activations 88 degrees of solar arc earlier. | |
| 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 | Yes | Birth time in 24-hour HH:MM:SS format. Precision matters: the profile lines and gate boundaries shift with the exact minute of birth. | |
| 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| nodeType | No | 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". | true |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| arrows | Yes | |
| confident | Yes | |
| baseDescription | Yes | |
| confidenceMarginDeg | Yes |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=falseentials. The description adds substantive behavioral detail: each arrow carries a confidence flag that turns false near a Color/Tone boundary, and Color/Tone/Base shift with tiny birth-time differences. This is meaningful context beyond the annotations.
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 is four sentences long, with the core function in the first sentence and the most important caveat (birth-time sensitivity) in the third. No redundant sentences; the final usage-oriented sentence earns its place by clarifying intended applications.
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?
With an output schema present, the description does not need to explain return values. It covers what is computed, where it fits in Human Design, the critical time-sensitivity behavior, and intended use cases. For a read-only tool with 8 documented parameters DB, this is complete.
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 baseline is 3. The description does not discuss any parameters directly; it focuses on outputs and usage. The schema's own descriptions already cover all parameters thoroughly, so no compensation is needed.
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 states a specific verb ('Calculate'), a specific resource ('the four Human Design Variable arrows'), and breaks down exactly which arrows (Determination/Environment and Perspective/Motivation). It also names the outputs (Color, Tone, Base, direction, labels). This clearly distinguishes the tool from sibling bodygraph/center/gate/type 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 gives clear usage context ('advanced Rave Variables and Primary Health System layer beneath Type, Strategy, Authority, and Profile') and target applications ('PHS, diet, environment, and Rave Psychology readings'). It does not explicitly name alternative tools or when not to use them, but the niche is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
12 tool updates
- Changed
get_human_design_centers_id1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "awareness": { + "type": "boolean" + }, + "definedMeaning": { + "type": "string" + }, + "id": { + "type": "string" + }, + "motor": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "nameLocalized": { + "type": "string" + }, + "undefinedMeaning": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "motor", + "awareness", + "definedMeaning", + "undefinedMeaning" + ], + "type": "object" +}
- Changed
get_human_design_gates_number1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "center": { + "type": "string" + }, + "centerName": { + "type": "string" + }, + "centerNameLocalized": { + "type": "string" + }, + "channelPartners": { + "items": { + "properties": { + "channel": { + "type": "string" + }, + "channelLocalized": { + "type": "string" + }, + "gate": { + "type": "number" + } + }, + "required": [ + "gate", + "channel" + ], + "type": "object" + }, + "type": "array" + }, + "ichingHexagram": { + "properties": { + "english": { + "type": "string" + }, + "number": { + "type": "number" + } + }, + "required": [ + "number", + "english" + ], + "type": "object" + }, + "name": { + "type": "string" + }, + "nameLocalized": { + "type": "string" + }, + "number": { + "type": "number" + } + }, + "required": [ + "number", + "name", + "center", + "centerName", + "ichingHexagram", + "channelPartners" + ], + "type": "object" +}
- Changed
post_human_design_bodygraph1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "aura": { + "type": "string" + }, + "authority": { + "type": "string" + }, + "authorityDescription": { + "type": "string" + }, + "authorityLocalized": { + "type": "string" + }, + "centers": { + "items": { + "properties": { + "awareness": { + "type": "boolean" + }, + "biology": { + "type": "string" + }, + "defined": { + "type": "boolean" + }, + "gates": { + "items": { + "type": "number" + }, + "type": "array" + }, + "id": { + "type": "string" + }, + "motor": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "nameLocalized": { + "type": "string" + }, + "notSelfQuestion": { + "type": "string" + }, + "theme": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "defined", + "motor", + "awareness", + "theme", + "notSelfQuestion", + "biology", + "gates" + ], + "type": "object" + }, + "type": "array" + }, + "channels": { + "items": { + "properties": { + "centers": { + "items": { + "type": "string" + }, + "type": "array" + }, + "circuit": { + "type": "string" + }, + "circuitDescription": { + "type": "string" + }, + "circuitLocalized": { + "type": "string" + }, + "description": { + "type": "string" + }, + "gateA": { + "type": "number" + }, + "gateB": { + "type": "number" + }, + "name": { + "type": "string" + }, + "nameLocalized": { + "type": "string" + } + }, + "required": [ + "gateA", + "gateB", + "name", + "circuit", + "centers", + "description", + "circuitDescription" + ], + "type": "object" + }, + "type": "array" + }, + "definition": { + "type": "string" + }, + "definitionDescription": { + "type": "string" + }, + "definitionLocalized": { + "type": "string" + }, + "designInstantUtc": { + "type": "string" + }, + "gates": { + "items": { + "properties": { + "gate": { + "type": "number" + }, + "gateDescription": { + "type": "string" + }, + "gateName": { + "type": "string" + }, + "gateNameLocalized": { + "type": "string" + }, + "ichingHexagram": { + "properties": { + "english": { + "type": "string" + }, + "number": { + "type": "number" + } + }, + "required": [ + "number", + "english" + ], + "type": "object" + }, + "line": { + "type": "number" + }, + "lineMeaning": { + "type": "string" + }, + "planet": { + "type": "string" + }, + "planetDescription": { + "type": "string" + }, + "planetLocalized": { + "type": "string" + }, + "side": { + "type": "string" + } + }, + "required": [ + "planet", + "side", + "gate", + "line", + "gateName", + "gateDescription", + "lineMeaning", + "planetDescription", + "ichingHexagram" + ], + "type": "object" + }, + "type": "array" + }, + "incarnationCross": { + "properties": { + "angle": { + "type": "string" + }, + "angleCode": { + "type": "string" + }, + "angleLocalized": { + "type": "string" + }, + "description": { + "type": "string" + }, + "gates": { + "items": { + "type": "number" + }, + "type": "array" + }, + "name": { + "type": "string" + } + }, + "required": [ + "gates", + "angle", + "angleCode", + "name" + ], + "type": "object" + }, + "notSelf": { + "type": "string" + }, + "notSelfLocalized": { + "type": "string" + }, + "profile": { + "type": "string" + }, + "profileDescription": { + "type": "string" + }, + "profileKeynotes": { + "properties": { + "design": { + "type": "string" + }, + "designLine": { + "type": "number" + }, + "personality": { + "type": "string" + }, + "personalityLine": { + "type": "number" + } + }, + "required": [ + "personalityLine", + "designLine", + "personality", + "design" + ], + "type": "object" + }, + "sides": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "signature": { + "type": "string" + }, + "signatureLocalized": { + "type": "string" + }, + "strategy": { + "type": "string" + }, + "strategyDescription": { + "type": "string" + }, + "strategyLocalized": { + "type": "string" + }, + "type": { + "type": "string" + }, + "typeDescription": { + "type": "string" + }, + "typeLocalized": { + "type": "string" + } + }, + "required": [ + "type", + "typeDescription", + "aura", + "strategy", + "strategyDescription", + "authority", + "authorityDescription", + "signature", + "notSelf", + "profile", + "profileKeynotes", + "profileDescription", + "definition", + "definitionDescription", + "sides", + "designInstantUtc", + "incarnationCross", + "centers", + "channels", + "gates" + ], + "type": "object" +}
- Changed
post_human_design_centers1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "centers": { + "items": { + "properties": { + "awareness": { + "type": "boolean" + }, + "biology": { + "type": "string" + }, + "defined": { + "type": "boolean" + }, + "gates": { + "items": { + "type": "number" + }, + "type": "array" + }, + "id": { + "type": "string" + }, + "motor": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "nameLocalized": { + "type": "string" + }, + "notSelfQuestion": { + "type": "string" + }, + "theme": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "defined", + "motor", + "awareness", + "theme", + "notSelfQuestion", + "biology", + "gates" + ], + "type": "object" + }, + "type": "array" + }, + "definedCount": { + "type": "number" + } + }, + "required": [ + "centers", + "definedCount" + ], + "type": "object" +}
- Changed
post_human_design_channels1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "channels": { + "items": { + "properties": { + "centers": { + "items": { + "type": "string" + }, + "type": "array" + }, + "circuit": { + "type": "string" + }, + "circuitDescription": { + "type": "string" + }, + "circuitLocalized": { + "type": "string" + }, + "description": { + "type": "string" + }, + "gateA": { + "type": "number" + }, + "gateB": { + "type": "number" + }, + "name": { + "type": "string" + }, + "nameLocalized": { + "type": "string" + } + }, + "required": [ + "gateA", + "gateB", + "name", + "circuit", + "centers", + "description", + "circuitDescription" + ], + "type": "object" + }, + "type": "array" + }, + "definedCenters": { + "items": { + "type": "string" + }, + "type": "array" + }, + "total": { + "type": "number" + } + }, + "required": [ + "channels", + "total", + "definedCenters" + ], + "type": "object" +}
- Changed
post_human_design_connection1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "centers": { + "items": { + "properties": { + "defined": { + "type": "boolean" + }, + "definedBy": { + "items": { + "type": "string" + }, + "type": "array" + }, + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "nameLocalized": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "defined", + "definedBy" + ], + "type": "object" + }, + "type": "array" + }, + "channels": { + "items": { + "properties": { + "centers": { + "items": { + "type": "string" + }, + "type": "array" + }, + "circuit": { + "type": "string" + }, + "circuitLocalized": { + "type": "string" + }, + "dynamic": { + "type": "string" + }, + "dynamicLocalized": { + "type": "string" + }, + "gateA": { + "type": "number" + }, + "gateB": { + "type": "number" + }, + "name": { + "type": "string" + }, + "nameLocalized": { + "type": "string" + }, + "personAGates": { + "items": { + "type": "number" + }, + "type": "array" + }, + "personBGates": { + "items": { + "type": "number" + }, + "type": "array" + } + }, + "required": [ + "gateA", + "gateB", + "name", + "circuit", + "centers", + "dynamic", + "personAGates", + "personBGates" + ], + "type": "object" + }, + "type": "array" + }, + "combinedDefinition": { + "type": "string" + }, + "combinedDefinitionLocalized": { + "type": "string" + }, + "summary": { + "properties": { + "companionship": { + "type": "number" + }, + "compromise": { + "type": "number" + }, + "dominance": { + "type": "number" + }, + "electromagnetic": { + "type": "number" + } + }, + "required": [ + "electromagnetic", + "dominance", + "compromise", + "companionship" + ], + "type": "object" + }, + "totalChannels": { + "type": "number" + } + }, + "required": [ + "totalChannels", + "channels", + "centers", + "combinedDefinition", + "summary" + ], + "type": "object" +}
- Changed
post_human_design_gates1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "design": { + "items": { + "properties": { + "gate": { + "type": "number" + }, + "gateDescription": { + "type": "string" + }, + "gateName": { + "type": "string" + }, + "gateNameLocalized": { + "type": "string" + }, + "ichingHexagram": { + "properties": { + "english": { + "type": "string" + }, + "number": { + "type": "number" + } + }, + "required": [ + "number", + "english" + ], + "type": "object" + }, + "line": { + "type": "number" + }, + "lineMeaning": { + "type": "string" + }, + "planet": { + "type": "string" + }, + "planetDescription": { + "type": "string" + }, + "planetLocalized": { + "type": "string" + }, + "side": { + "type": "string" + } + }, + "required": [ + "planet", + "side", + "gate", + "line", + "gateName", + "gateDescription", + "lineMeaning", + "planetDescription", + "ichingHexagram" + ], + "type": "object" + }, + "type": "array" + }, + "personality": { + "items": { + "properties": { + "gate": { + "type": "number" + }, + "gateDescription": { + "type": "string" + }, + "gateName": { + "type": "string" + }, + "gateNameLocalized": { + "type": "string" + }, + "ichingHexagram": { + "properties": { + "english": { + "type": "string" + }, + "number": { + "type": "number" + } + }, + "required": [ + "number", + "english" + ], + "type": "object" + }, + "line": { + "type": "number" + }, + "lineMeaning": { + "type": "string" + }, + "planet": { + "type": "string" + }, + "planetDescription": { + "type": "string" + }, + "planetLocalized": { + "type": "string" + }, + "side": { + "type": "string" + } + }, + "required": [ + "planet", + "side", + "gate", + "line", + "gateName", + "gateDescription", + "lineMeaning", + "planetDescription", + "ichingHexagram" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "personality", + "design" + ], + "type": "object" +}
- Changed
post_human_design_penta1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "channels": { + "items": { + "properties": { + "circuit": { + "type": "string" + }, + "circuitLocalized": { + "type": "string" + }, + "defined": { + "type": "boolean" + }, + "gateA": { + "type": "number" + }, + "gateAHeldBy": { + "items": { + "type": "number" + }, + "type": "array" + }, + "gateB": { + "type": "number" + }, + "gateBHeldBy": { + "items": { + "type": "number" + }, + "type": "array" + }, + "isCore": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "nameLocalized": { + "type": "string" + }, + "position": { + "type": "string" + } + }, + "required": [ + "gateA", + "gateB", + "name", + "circuit", + "position", + "isCore", + "defined", + "gateAHeldBy", + "gateBHeldBy" + ], + "type": "object" + }, + "type": "array" + }, + "gates": { + "items": { + "properties": { + "filled": { + "type": "boolean" + }, + "gate": { + "type": "number" + }, + "gateName": { + "type": "string" + }, + "gateNameLocalized": { + "type": "string" + }, + "heldBy": { + "items": { + "type": "number" + }, + "type": "array" + } + }, + "required": [ + "gate", + "gateName", + "filled", + "heldBy" + ], + "type": "object" + }, + "type": "array" + }, + "memberCount": { + "type": "number" + }, + "summary": { + "properties": { + "coreDefined": { + "type": "boolean" + }, + "definedChannels": { + "type": "number" + }, + "filledGates": { + "type": "number" + }, + "gapGates": { + "items": { + "type": "number" + }, + "type": "array" + } + }, + "required": [ + "definedChannels", + "filledGates", + "gapGates", + "coreDefined" + ], + "type": "object" + } + }, + "required": [ + "memberCount", + "channels", + "gates", + "summary" + ], + "type": "object" +}
- Changed
post_human_design_profile1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "designKeynote": { + "type": "string" + }, + "designLine": { + "type": "number" + }, + "personalityKeynote": { + "type": "string" + }, + "personalityLine": { + "type": "number" + }, + "profile": { + "type": "string" + } + }, + "required": [ + "profile", + "personalityLine", + "designLine", + "personalityKeynote", + "designKeynote" + ], + "type": "object" +}
- Changed
post_human_design_transit1 field changed- changed
Output 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" +}
- Changed
post_human_design_type1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "aura": { + "type": "string" + }, + "authority": { + "type": "string" + }, + "authorityDescription": { + "type": "string" + }, + "authorityLocalized": { + "type": "string" + }, + "notSelf": { + "type": "string" + }, + "notSelfLocalized": { + "type": "string" + }, + "profile": { + "type": "string" + }, + "signature": { + "type": "string" + }, + "signatureLocalized": { + "type": "string" + }, + "strategy": { + "type": "string" + }, + "strategyDescription": { + "type": "string" + }, + "strategyLocalized": { + "type": "string" + }, + "type": { + "type": "string" + }, + "typeDescription": { + "type": "string" + }, + "typeLocalized": { + "type": "string" + } + }, + "required": [ + "type", + "typeDescription", + "aura", + "strategy", + "strategyDescription", + "authority", + "authorityDescription", + "signature", + "notSelf", + "profile" + ], + "type": "object" +}
- Changed
post_human_design_variables1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "arrows": { + "items": { + "properties": { + "activation": { + "properties": { + "planet": { + "type": "string" + }, + "planetLocalized": { + "type": "string" + }, + "side": { + "type": "string" + } + }, + "required": [ + "planet", + "side" + ], + "type": "object" + }, + "base": { + "type": "number" + }, + "baseName": { + "type": "string" + }, + "baseNameLocalized": { + "type": "string" + }, + "cognition": { + "properties": { + "description": { + "type": "string" + }, + "label": { + "type": "string" + }, + "labelLocalized": { + "type": "string" + } + }, + "required": [ + "label", + "description" + ], + "type": "object" + }, + "color": { + "type": "number" + }, + "colorLabel": { + "type": "string" + }, + "colorLabelLocalized": { + "type": "string" + }, + "colorMeaning": { + "type": "string" + }, + "confident": { + "type": "boolean" + }, + "description": { + "type": "string" + }, + "direction": { + "type": "string" + }, + "directionLabel": { + "type": "string" + }, + "directionLabelLocalized": { + "type": "string" + }, + "directionMeaning": { + "type": "string" + }, + "key": { + "type": "string" + }, + "layer": { + "type": "string" + }, + "layerDescription": { + "type": "string" + }, + "layerLocalized": { + "type": "string" + }, + "name": { + "type": "string" + }, + "nameLocalized": { + "type": "string" + }, + "position": { + "type": "string" + }, + "positionLocalized": { + "type": "string" + }, + "tone": { + "type": "number" + }, + "toneMeaning": { + "type": "string" + } + }, + "required": [ + "key", + "name", + "layer", + "position", + "activation", + "color", + "tone", + "base", + "direction", + "colorLabel", + "directionLabel", + "description", + "layerDescription", + "colorMeaning", + "toneMeaning", + "directionMeaning", + "baseName", + "confident" + ], + "type": "object" + }, + "type": "array" + }, + "baseDescription": { + "type": "string" + }, + "confidenceMarginDeg": { + "type": "number" + }, + "confident": { + "type": "boolean" + } + }, + "required": [ + "arrows", + "confident", + "confidenceMarginDeg", + "baseDescription" + ], + "type": "object" +}
1 tool update
- Changed
get_human_design_gates_number3 fields changed- added
Input schema / properties / number / maximumAdded value: +64 - added
Input schema / properties / number / minimumAdded value: +1 - changed
Input schema / properties / number / typePrevious value: -[ - "integer", - "null" -]New value: +"integer"
10 tool updates
- Changed
post_human_design_bodygraph1 field changed- changed
Input schema / properties / timezone / descriptionPrevious 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."
- Changed
post_human_design_centers1 field changed- changed
Input schema / properties / timezone / descriptionPrevious 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."
- Changed
post_human_design_channels1 field changed- changed
Input schema / properties / timezone / descriptionPrevious 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."
- Changed
post_human_design_connection2 fields changed- changed
Input schema / properties / personA / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / personB / properties / timezone / descriptionPrevious 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."
- Changed
post_human_design_gates1 field changed- changed
Input schema / properties / timezone / descriptionPrevious 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."
- Changed
post_human_design_penta1 field changed- changed
Input schema / properties / members / items / properties / timezone / descriptionPrevious 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."
- Changed
post_human_design_profile1 field changed- changed
Input schema / properties / timezone / descriptionPrevious 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."
- Changed
post_human_design_transit1 field changed- changed
Input schema / properties / birthData / properties / timezone / descriptionPrevious 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."
- Changed
post_human_design_type1 field changed- changed
Input schema / properties / timezone / descriptionPrevious 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."
- Changed
post_human_design_variables1 field changed- changed
Input schema / properties / timezone / descriptionPrevious 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."
12 tool updates
- Changed
get_human_design_centers_id2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
get_human_design_gates_number2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_human_design_bodygraph2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_human_design_centers2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_human_design_channels2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_human_design_connection2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_human_design_gates2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_human_design_penta2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_human_design_profile2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_human_design_transit2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_human_design_type2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_human_design_variables2 fields changed- changed
Input schema / properties / lang / descriptionPrevious 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." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
10 tool updates
- Changed
post_human_design_bodygraph1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_centers1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_channels1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_connection2 fields changed- changed
Input schema / properties / personA / properties / nodeType / descriptionPrevious 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\"." - changed
Input schema / properties / personB / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_gates1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_penta1 field changed- changed
Input schema / properties / members / items / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_profile1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_transit1 field changed- changed
Input schema / properties / birthData / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_type1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_variables1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
12 tool updates
- Changed
get_human_design_centers_id2 fields changed- added
Input schema / examplesAdded value: +[ + { + "id": "sacral" + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
get_human_design_gates_number2 fields changed- added
Input schema / examplesAdded value: +[ + { + "number": 34 + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_bodygraph2 fields changed- added
Input schema / examplesAdded value: +[ + { + "date": "1990-07-15", + "time": "13:00:00", + "timezone": "America/New_York" + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_centers2 fields changed- added
Input schema / examplesAdded value: +[ + { + "date": "1990-07-15", + "time": "13:00:00", + "timezone": "America/New_York" + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_channels2 fields changed- added
Input schema / examplesAdded value: +[ + { + "date": "1990-07-15", + "time": "13:00:00", + "timezone": "America/New_York" + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_connection2 fields changed- added
Input schema / examplesAdded value: +[ + { + "personA": { + "date": "1990-07-15", + "time": "13:00:00", + "timezone": "America/New_York" + }, + "personB": { + "date": "1990-07-15", + "time": "13:00:00", + "timezone": "America/New_York" + } + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_gates2 fields changed- added
Input schema / examplesAdded value: +[ + { + "date": "1990-07-15", + "time": "13:00:00", + "timezone": "America/New_York" + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_penta1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_profile2 fields changed- added
Input schema / examplesAdded value: +[ + { + "date": "1990-07-15", + "time": "13:00:00", + "timezone": "America/New_York" + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_transit2 fields changed- added
Input schema / examplesAdded value: +[ + { + "birthData": { + "date": "1990-07-15", + "time": "13:00:00", + "timezone": "America/New_York" + } + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_type2 fields changed- added
Input schema / examplesAdded value: +[ + { + "date": "1990-07-15", + "time": "13:00:00", + "timezone": "America/New_York" + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_variables2 fields changed- added
Input schema / examplesAdded value: +[ + { + "date": "1990-07-15", + "time": "13:00:00", + "timezone": "America/New_York" + } +] - changed
Input schema / properties / compact / descriptionPrevious 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."
10 tool updates
- Changed
post_human_design_bodygraph1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_centers1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_channels1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_connection2 fields changed- changed
Input schema / properties / personA / properties / nodeType / descriptionPrevious 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\"." - changed
Input schema / properties / personB / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_gates1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_penta1 field changed- changed
Input schema / properties / members / items / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_profile1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_transit1 field changed- changed
Input schema / properties / birthData / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_type1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
- Changed
post_human_design_variables1 field changed- changed
Input schema / properties / nodeType / descriptionPrevious 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\"."
1 tool update
- Changed
get_human_design_gates_number1 field changed- changed
Input schema / properties / number / typePrevious value: -"integer"New value: +[ + "integer", + "null" +]
12 tool updates
- Changed
get_human_design_centers_id1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
get_human_design_gates_number1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_bodygraph1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_centers1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_channels1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_connection1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_gates1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_penta1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_profile1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_transit1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_type1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
- Changed
post_human_design_variables1 field changed- changed
Input schema / properties / compact / descriptionPrevious 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."
12 tool updates
- Changed
get_human_design_centers_id1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
get_human_design_gates_number1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
post_human_design_bodygraph1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
post_human_design_centers1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
post_human_design_channels1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
post_human_design_connection1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
post_human_design_gates1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
post_human_design_penta1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
post_human_design_profile1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
post_human_design_transit1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
post_human_design_type1 field changed- added
Input schema / properties / compactAdded 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" +}
- Changed
post_human_design_variables1 field changed- added
Input schema / properties / compactAdded 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" +}
10 tool updates
- Changed
post_human_design_bodygraph1 field changed- added
Input schema / properties / nodeTypeAdded 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" +}
- Changed
post_human_design_centers1 field changed- added
Input schema / properties / nodeTypeAdded 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" +}
- Changed
post_human_design_channels1 field changed- added
Input schema / properties / nodeTypeAdded 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" +}
- Changed
post_human_design_connection2 fields changed- added
Input schema / properties / personA / properties / nodeTypeAdded 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" +} - added
Input schema / properties / personB / properties / nodeTypeAdded 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" +}
- Changed
post_human_design_gates1 field changed- added
Input schema / properties / nodeTypeAdded 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" +}
- Changed
post_human_design_penta1 field changed- added
Input schema / properties / members / items / properties / nodeTypeAdded 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" +}
- Changed
post_human_design_profile1 field changed- added
Input schema / properties / nodeTypeAdded 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" +}
- Changed
post_human_design_transit1 field changed- added
Input schema / properties / birthData / properties / nodeTypeAdded 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" +}
- Changed
post_human_design_type1 field changed- added
Input schema / properties / nodeTypeAdded 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" +}
- Changed
post_human_design_variables1 field changed- added
Input schema / properties / nodeTypeAdded 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" +}
10 tool updates
- Changed
post_human_design_bodygraph3 fields changed- changed
Input schema / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_human_design_centers3 fields changed- changed
Input schema / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_human_design_channels3 fields changed- changed
Input schema / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_human_design_connection6 fields changed- changed
Input schema / properties / personA / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / personA / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / personA / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York" - changed
Input schema / properties / personB / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / personB / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / personB / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_human_design_gates3 fields changed- changed
Input schema / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_human_design_penta3 fields changed- changed
Input schema / properties / members / items / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / members / items / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / members / items / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_human_design_profile3 fields changed- changed
Input schema / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_human_design_transit3 fields changed- changed
Input schema / properties / birthData / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / birthData / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / birthData / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_human_design_type3 fields changed- changed
Input schema / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_human_design_variables3 fields changed- changed
Input schema / properties / timezone / anyOfPrevious 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" + } +] - changed
Input schema / properties / timezone / descriptionPrevious 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." - changed
Input schema / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
12 tool updates
- First observed
get_human_design_centers_id - First observed
get_human_design_gates_number - First observed
post_human_design_bodygraph - First observed
post_human_design_centers - First observed
post_human_design_channels - First observed
post_human_design_connection - First observed
post_human_design_gates - First observed
post_human_design_penta - First observed
post_human_design_profile - First observed
post_human_design_transit - First observed
post_human_design_type - First observed
post_human_design_variables
Related MCP Connectors
JPL-referenced Human Design charts for AI agents: bodygraph, transit, composite, Penta, DreamRave.
Calculate Human Design bodygraph charts, save people, compare charts, and analyse group dynamics.
Human Design & astrology engine: bodygraph, personal-sky SVG, today's sky. JPL ephemeris.
Real astrology for AI agents: cosmic weather, synastry, timing, astrocartography, and divination.
Related MCP Servers
- FlicenseBqualityDmaintenanceCalculates Human Design charts based on birth date, time, and location, providing type, strategy, authority, profile, gates, defined centers, and incarnation cross information.21-
HumanDesign.ai MCPofficial
AlicenseNot gradedqualityBmaintenanceEnables AI assistants to generate and render individual and composite Human Design charts, explore authorized chart and library data, and manage account usage and Website Builder projects with secure OAuth and entitlement filtering.1MIT- FlicenseNot gradedqualityCmaintenanceMulti-tradition astrology engine that computes real birth charts, transits, and synastry for AI agents via MCP tools.8-
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.