Human Design MCP Server by RoxyAPI
Server Details
Human Design bodygraph, type, authority, profile, gates and channels for AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 12 of 12 tools scored.
Each tool targets a specific aspect of Human Design, either static reference (centers, gates) or dynamic calculation (bodygraph, centers, channels, connection, gates, penta, profile, transit, type, variables). Even though some endpoints return overlapping data, they are explicitly scoped for different use cases, so there is no ambiguity.
All tools follow a consistent verb_noun pattern with 'human_design' as the domain: 'get_' for static references and 'post_' for computations. Names are lowercase with underscores, making them predictable and easy to navigate.
With 12 tools, the set is well-scoped for a Human Design server. It covers both reference data and calculations without being excessive. Each tool earns its place by addressing a distinct need.
The tool surface covers all major Human Design components: static reference (centers, gates) and dynamic calculations (full chart, centers, channels, gates, profile, type, variables, transit, connection, penta). There are no obvious gaps for building Human Design applications.
Available Tools
12 toolsget_human_design_centers_idLook up a Human Design center by idAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Center id. One of head, ajna, throat, g, heart, sacral, solar-plexus, spleen, root. | |
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It discloses that the tool is read-only, returns static reference data, and gives specifics on output fields. It does not mention rate limits or error handling, but for a simple lookup this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, output, and usage context without unnecessary words. The key information is front-loaded. Minor improvement: could be even more concise, but it is well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with full parameter schema and no output schema, the description is complete. It explains what data is returned, the static nature, and the absence of birth data requirement. All needed context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 add new meaning beyond what the schema already provides for 'id' and 'lang'. It only reinforces that the id is required and that lang has a default, which is already in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'look up' and specifies resource 'Human Design center by id'. It lists the data returned: display name, motor/awareness, meaning defined/undefined. It also distinguishes from siblings by noting it requires no birth data, setting it apart from post endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is a 'pure reference endpoint with no birth data required', which implies use when only static reference data is needed, as opposed to the post endpoints that require birth data. Although alternatives are not explicitly named, the context signals (sibling tools) make the distinction clear.
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 numberAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| number | Yes | Gate number from 1 to 64. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states it's a 'pure reference endpoint,' implying read-only idempotent behavior. It does not mention authentication or rate limits, but for a simple lookup, the description provides sufficient transparency about its non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It is front-loaded with the verb and resource, lists key output fields, and adds a clarifying note. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the specific data returned: gate keynote name, center, I-Ching hexagram, and channel gates. It also clarifies that no birth data is needed. This is complete for a tool with low complexity and good context from sibling names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add meaning beyond the schema. The schema already includes details about language fallback and gate number range. Description repeats no param info, which is fine, but does not enhance understanding of the parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Look up the static reference data for a Human Design gate by its number from 1 to 64.' It specifies the use case (reference lookup) and distinguishes from siblings by noting 'no birth data required,' which sets it apart from POST tools that likely require birth data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('pure reference endpoint with no birth data required') and contrasts with siblings that likely need birth data. However, it does not explicitly state when NOT to use it or mention alternatives, though the context is clear.
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, gatesAInspect
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.
| 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 (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It lists what is returned but does not mention side effects, auth requirements, rate limits, or error handling. For a read-only chart generator, the transparency is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence nails purpose, second lists outputs and differentiates. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by enumerating the returned fields. It also provides domain context ('built for Human Design apps'). Lacks error scenario details but is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds meaningful context beyond schema definitions, e.g., explaining the 88-degree solar arc for date, precision of time, and DST handling for timezone. This elevates it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and resource 'complete Human Design bodygraph' and lists all returned elements. It distinguishes from sibling tools by positioning itself as 'the single endpoint for a full chart', making it clear what this tool does vs. more granular tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this for a full chart, while siblings are for partial data. It explicitly says 'single endpoint for a full chart in one call' but does not provide explicit when-not-to-use or 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_centersCalculate the nine Human Design centersAInspect
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.
| 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 (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the computational output but does not clarify if the tool has side effects, requires authentication, or has rate limits. The 'post' prefix suggests a creation endpoint, but the description says 'calculate,' leaving idempotency unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero fluff. The first sentence delivers the core action and return details; the second sentence provides useful context (data layer for rendered bodygraph). Every sentence is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool computes and returns (center states) but does not specify the output structure or format. With no output schema, additional detail on the response shape would improve completeness. However, the given level is adequate for an agent familiar with Human Design.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already well-documented (date, time, timezone, etc.). The tool description does not add extra meaning beyond summarizing that the input is a 'birth moment.' It thus meets the baseline expectation but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'calculate' and the resource 'the state of all nine Human Design centers.' It specifies what information is provided (defined/open, motor/awareness, theme, active gates) and distinguishes this tool from siblings that deal with gates, bodygraph, channels, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly instruct when to use this tool versus alternatives like post_human_design_gates or get_human_design_centers_id. It implies use for center-level data but lacks when-not-to-use guidance or prerequisites.
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 channelsAInspect
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.
| 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 (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It explains the calculation logic (channel defined when both gates activated, wiring centers) and the return structure. It does not detail side effects or permissions, but for a pure computation tool, this is adequate. There is no contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no redundant information. Every sentence serves a purpose: one defines the core function, the other details the output and use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema), the description explains the output and logic sufficiently. It could mention the required parameters (date, time, timezone) or error conditions, but the provided information is adequate for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with detailed descriptions, so the description does not need to add per-parameter meaning. It adds high-level context (why channels are calculated) but does not enhance individual parameter understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates defined channels for a birth moment, explains the condition for a channel to be defined, and lists the output details. It distinguishes from siblings by focusing on channels and their role in bodygraph rendering, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is 'built for bodygraph rendering and definition analysis,' which implies usage context, but it does not explicitly state when to use this tool versus alternatives like post_human_design_gates or post_human_design_centers. No when-not-to-use guidance is provided.
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 compatibilityAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| personA | Yes | Birth moment of the first person in the connection. | |
| personB | Yes | Birth moment of the second person in the connection. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior. It explains the computation of dynamics, centers, definition, and counts. It does not mention side effects or mutations, but the verb 'Calculate' implies a read-only operation. Adequate for a calculation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the primary function, and the second elaborates on outputs. No redundant or filler content; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description provides a comprehensive overview of what the tool returns: dynamics, centers, definition, and counts. It sufficiently prepares the agent for the tool's output structure and complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about the two-person overlay but does not enhance parameter meaning beyond the already detailed schema descriptions (e.g., date, time, timezone).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates a two-person Human Design connection chart, listing the four dynamics (electromagnetic, dominance, compromise, companionship) and additional outputs like centers and counts. It distinctly separates from sibling tools that focus on single bodygraphs, transits, or penta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the tool is built for relationship, dating, and coaching tools, providing clear context for appropriate use. However, it does not explicitly mention when not to use or compare with sibling alternatives like get_human_design_centers_id.
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 activationsAInspect
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.
| 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 (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains what it computes and reports but omits whether the operation is stateless or has side effects. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with primary action, followed by output details and use case. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and output fields, but lacks specification of response format or pagination. With no output schema, slightly more detail on return structure would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions already present. Description does not add extra parameter-level meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it calculates 26 gate activations, split into personality and design, with specific output fields. Differentiates from sibling tools like get_human_design_gates_number by focusing on full activation calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates intended use for 'activation columns and detailed chart views.' However, no explicit alternatives or when-not-to-use guidance provided.
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 peopleAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| members | Yes | Birth moments of the three to five people in the group. Below three no Penta forms; above five a second Penta emerges. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses what the tool calculates and reports, but does not address data handling, authentication, or error states. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient, front-loading purpose and key details. It is a single paragraph with essential information, though could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description enumerates what the tool reports (filled gates, strengths, etc.), which is sufficient for usage. Missing format details but still quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context about group size and Penta formation conditions for members array, but does not significantly enhance parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates the Human Design Penta for a group of 3-5 people, using specific verbs and resources. It is distinct from siblings which focus on individual charts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use (team/family/group analysis) and includes constraints on group size (3-5). It does not explicitly mention alternatives, but siblings are all different tools, so no confusion.
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 keynotesAInspect
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.
| 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 (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions verification against NASA JPL Horizons, indicating reliability, but does not disclose any behavioral traits such as being read-only, permission needs, or rate limits. The tool likely is non-destructive, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action and providing an example. Every sentence adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description adequately explains the input purpose but does not describe the output format or structure (e.g., what fields are returned). This is a gap for a complete understanding of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already fully describes all parameters. The description adds no additional meaning beyond what the schema provides, such as example or motivation for the parameters. Thus, it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates the Human Design profile, explains it as the conscious Personality Sun line over the unconscious Design Sun line with keynotes, and provides an example. It distinguishes from sibling tools by specifying the unique output (profile vs. bodygraph, centers, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what the tool does, implying it is for calculating a Human Design profile. However, it does not explicitly state when to use it versus alternatives or when not to use it, but the sibling tool names make the differentiation straightforward.
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 bodygraphAInspect
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.
| 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 (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return 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. | |
| birthData | Yes | Birth moment whose natal bodygraph the transit is overlaid on. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It details the exact return structure, explains that a transit is a single moment with no Design side, and clarifies default UTC behavior. However, it does not explicitly state that the tool is read-only (non-destructive) or mention any authorization requirements, but for a computation tool, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise paragraph of five sentences. It front-loads the primary action, then lists return values, adds behavioral nuance, and closes with use cases. Every sentence contributes essential information without redundancy. It is well-organized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 parameters, nested object, no output schema), the description adequately explains the tool's purpose, inputs, and outputs. It lists all returns and default behaviors. However, it lacks example usage or mention of error handling (e.g., invalid birth data). The absence of an output schema is compensated by the detailed return description, making the tool mostly complete but with minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter descriptions, so the description adds value beyond schema by explaining the concept of a transit being a single moment (no Design side), which clarifies why there is no separate design date. It also reiterates that omitting date/time defaults to current UTC, reinforcing the schema's optionality. This contextual summary enhances understanding beyond individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: overlaying planetary positions on a natal bodygraph to see completed channels. It distinguishes from sibling tools like post_human_design_bodygraph (full bodygraph without transit) and post_human_design_connection (relationship synastry). The verb 'overlay' and resource 'natal bodygraph' are specific, and the return types are explicitly listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Built for daily Human Design apps, transit widgets, and notification tools.' It also explains that omitting date/time gives current transit. However, it does not explicitly state when NOT to use it or what alternatives exist (e.g., use post_human_design_bodygraph for a static chart). The guidance is clear but lacks exclusion criteria.
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 profileAInspect
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.
| 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 (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions verification against NASA JPL Horizons (transparent for accuracy) but fails to describe side effects, idempotency, error handling, or whether the operation is a pure calculation with no side effects. The description carries the full burden but provides minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences that front-load the main purpose and key distinction. Every sentence adds value: purpose, fast-lookup differentiation, and verification claim. No unnecessary words or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations. The description covers the main output (type, authority, profile, etc.) but does not specify the format or structure of the response, error handling, or edge cases. Given the complexity, the description is adequate but leaves gaps in return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 6 parameters with descriptions and examples. The tool description adds no additional meaning to the parameters beyond what the schema provides. Baseline score of 3 is appropriate as the description doesn't detract but also doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool calculates core Human Design identity (type, authority, profile) and distinguishes itself from the full bodygraph sibling with 'fast lookup ... without the full bodygraph payload'. The verb 'Calculate' and resource 'Human Design type' are specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use when you need type/authority/profile quickly without full bodygraph. It references 'fast lookup' and 'without the full bodygraph payload', giving clear context. However, it does not explicitly state when NOT to use or name alternative tools, leaving slight ambiguity.
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 substructureAInspect
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.
| 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 (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return 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. | |
| latitude | No | Birth latitude in decimal degrees. Optional and does not affect the bodygraph, which depends only on ecliptic longitudes. Defaults to 0. | |
| timezone | Yes | 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. | |
| longitude | No | Birth longitude in decimal degrees. Optional and does not affect the bodygraph. Defaults to 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully compensates for missing annotations by disclosing key behaviors: arrows carry confidence flags that turn false near Color/Tone boundaries, Color/Tone/Base shift with tiny birth time differences, and the tool is built for specific applications. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the main action ('Calculate the four Human Design Variable arrows') and includes every sentence purposefully without redundancy. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains the output structure (four arrows, Color/Tone/Base numbers, direction, labels, confidence flag) and use cases. Given the complexity of the topic, this provides sufficient context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so baseline is 3. The tool description adds contextual meaning about precision ('Precision matters,' 'Optional and does not affect bodygraph') and overall purpose, elevating it above mere schema repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates Human Design Variable arrows, listing all four (Determination, Environment, Perspective, Motivation) and the substructure (Color, Tone, Base). It distinguishes itself from sibling tools like post_human_design_type and post_human_design_profile by noting it's the 'advanced Rave Variables and Primary Health System layer beneath Type, Strategy, Authority, and Profile.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for advanced Human Design apps offering PHS, diet, environment, and Rave Psychology readings, and contrasts with simpler tools like Type or Profile. However, it does not explicitly state when not to use this tool or name alternative tools for basic readings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!