Skip to main content
Glama
openephemeris

Open Ephemeris

by openephemeris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Human Design Chart

human_design_chart
Read-onlyIdempotent

Generate a Human Design chart as structured data from birth date, time, and coordinates, returning Type, Strategy, Authority, Profile, Centers, Gates, Channels, Cross, and planetary positions.

Instructions

Use this when the Human Design chart is wanted as data — 'give me my HD activations', 'what are my variables', 'my Human Design chart as JSON'. Returns Type, Strategy, Authority, Profile, Centers, Gates, Channels, Incarnation Cross, and Personality and Design planetary positions.

CREDIT COST: 2 credits per call.

Takes coordinates, not a place name.

Input Schema

NameRequiredDescriptionDefault
formatNo'llm' = compact; 'json' = full.
datetimeYesISO 8601; zone required (`Z`/offset, or local time plus `timezone`).
latitudeNoBirth latitude.
timezoneNoIANA zone for a local datetime.
longitudeNoBirth longitude.
chart_variantNo'dream': 15-gate chart, no type or profile. Default 'waking'; not with include_visual.
visual_configNoRendering options for include_visual.
include_visualNoEmbed a bodygraph SVG. +2 credits.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv4.29.0
    • changedInput schema / properties / chart_variant / description
      Previous value: -"'dream': 15-gate subset chart, Design when the Moon was 88° behind its birth longitude; no type or profile. Default 'waking'; not with include_visual."New value: +"'dream': 15-gate chart, no type or profile. Default 'waking'; not with include_visual."
    • changedInput schema / properties / datetime / description
      Previous value: -"ISO 8601 datetime. A datetime with no zone is rejected; give a `Z` or ±HH:MM suffix, or a local time with the `timezone` argument. Date-only resolves to 12:00 UTC."New value: +"ISO 8601; zone required (`Z`/offset, or local time plus `timezone`)."
    • changedInput schema / properties / format / description
      Previous value: -"Output format. 'llm' returns compact array projection for token efficiency (available on all tiers). 'json' returns verbose full output."New value: +"'llm' = compact; 'json' = full."
    • changedInput schema / properties / include_visual / description
      Previous value: -"When true, renders the Human Design bodygraph as an SVG and embeds it in the response. Costs 2 additional credits on top of the base call cost."New value: +"Embed a bodygraph SVG. +2 credits."
    • changedInput schema / properties / latitude / description
      Previous value: -"Latitude of birth location in decimal degrees (positive = North)."New value: +"Birth latitude."
    • changedInput schema / properties / longitude / description
      Previous value: -"Longitude of birth location in decimal degrees (positive = East)."New value: +"Birth longitude."
    • changedInput schema / properties / timezone / description
      Previous value: -"IANA timezone (e.g. `America/Chicago`); required when the datetime is naive, ignored otherwise."New value: +"IANA zone for a local datetime."
    • changedInput schema / properties / visual_config / description
      Previous value: -"Optional rendering preferences (only used when include_visual=true)."New value: +"Rendering options for include_visual."
    • changedInput schema / properties / visual_config / properties / size / description
      Previous value: -"Canvas size in pixels, 200–4000. Default: 800."New value: +"Pixels, 200–4000. Default 800."
  2. Changed1 schema field changedv4.27.0
    • addedInput schema / properties / chart_variant
      Added value: +{
+  "description": "'dream': 15-gate subset chart, Design when the Moon was 88° behind its birth longitude; no type or profile. Default 'waking'; not with include_visual.",
+  "enum": [
+    "waking",
+    "dream"
+  ],
+  "type": "string"
+}
  3. Changed3 schema fields changedv4.24.2
    • changedInput schema / properties / datetime / description
      Previous value: -"ISO 8601 datetime; zone required — a `Z`/±HH:MM suffix or the `timezone` argument. Date-only resolves to 12:00 UTC. Full rule: server `instructions`."New value: +"ISO 8601 datetime. A datetime with no zone is rejected; give a `Z` or ±HH:MM suffix, or a local time with the `timezone` argument. Date-only resolves to 12:00 UTC."
    • changedInput schema / properties / include_visual / description
      Previous value: -"When true, renders the Human Design bodygraph as an SVG and embeds it in the response. The bodygraph image will display in the conversation alongside the data. Costs 2 additional credits on top of the base call cost."New value: +"When true, renders the Human Design bodygraph as an SVG and embeds it in the response. Costs 2 additional credits on top of the base call cost."
    • changedInput schema / properties / latitude / description
      Previous value: -"Latitude of birth location in decimal degrees (positive = North). Resolve from a place name with location_search; never recall coordinates from memory."New value: +"Latitude of birth location in decimal degrees (positive = North)."
  4. Changed3 schema fields changedv4.8.0
    • changedInput schema / properties / datetime / description
      Previous value: -"ISO 8601 birth datetime in UTC, e.g. '1990-04-15T19:30:00Z'. Must include 'Z' or timezone offset."New value: +"ISO 8601 datetime; zone required — a `Z`/±HH:MM suffix or the `timezone` argument. Date-only resolves to 12:00 UTC. Full rule: server `instructions`."
    • changedInput schema / properties / latitude / description
      Previous value: -"Latitude of birth location in decimal degrees (positive = North)."New value: +"Latitude of birth location in decimal degrees (positive = North). Resolve from a place name with location_search; never recall coordinates from memory."
    • addedInput schema / properties / timezone
      Added value: +{
+  "description": "IANA timezone (e.g. `America/Chicago`); required when the datetime is naive, ignored otherwise.",
+  "type": "string"
+}
  5. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds behavior the annotations cannot: an explicit cost model (2 credits per call, +2 for include_visual) and the coordinate-versus-place-name input constraint. It does not mention that the call is deterministic across repeated identical inputs or how the visual embed affects payload size, but the cost disclosure is the meaningful addition.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the decision trigger, then the return payload, then the cost and input constraint. Every line carries information; the credit-cost line is on its own for scannability rather than being padding. Slightly fragmentary ('Takes coordinates, not a place name.' as a dangling sentence), which keeps it from a 5.

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 an 8-parameter, nested-object tool with no output schema, the description supplies what's genuinely missing: the shape of the response, the cost of the call including the surcharge, and the coordinate requirement. Remaining details (enum meanings, chart_variant's incompatibility with include_visual) are fully documented in the schema, so nothing an agent needs to invoke correctly is absent.

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 coverage is 100%, so the baseline is 3 and the schema already carries the per-parameter detail. The description still adds value by clarifying the input contract ('takes coordinates, not a place name') and by enumerating the returned fields, which is the only return-value documentation since no output schema exists. Marginally above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ('Human Design chart ... as data') and enumerates what the response contains (Type, Strategy, Authority, Profile, Centers, Gates, Channels, Cross, planetary positions). The 'as data / as JSON' framing implicitly separates it from the interpretive sibling explore_human_design, but that sibling is never named, so the differentiation is inferred rather than explicit.

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?

Gives literal user phrasings that should route here ('give me my HD activations', 'what are my variables', 'my chart as JSON'), which is stronger than a generic 'use when needed'. It also adds the precondition 'Takes coordinates, not a place name', steering callers to a geocoding step first. It stops short of naming alternatives or exclusion cases (e.g. when to prefer explore_human_design instead).

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

Deploy Server

Other Tools