Skip to main content
Glama
Sign In
openephemeris

Open Ephemeris

by openephemeris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Human Design Connection (Synastry)

explore_human_design_connection
Read-onlyIdempotent

Overlay two people's Human Design charts to reveal a composite bodygraph, showing which channels form and classifying each connection as electromagnetic attraction, companionship, dominance, or compromise.

Instructions

Use this when the user asks 'are we compatible in Human Design', 'what's our connection chart', 'what channels do we make together' or 'show our composite bodygraph' — two people's HD charts overlaid. Returns an interactive two-person overlay bodygraph (inline in Claude and ChatGPT; text summary elsewhere) with every connected channel classified by HD connection theory: electromagnetic (attraction), companionship (sameness), dominance (one defines), compromise (friction).

CREDIT COST: 5 credits per call (composite 3 + render 2). Human Design was originated by Ra Uru Hu; Open Ephemeris is an independent calculation service, not affiliated with Jovian Archive.

Input Schema

NameRequiredDescriptionDefault
themeNoSet by the embedded app. Default dark.
layoutNoSet by the embedded app. Default graph.
person_aYesFirst person's birth data.
person_bYesSecond person's birth data.
render_tokenNoSet by the embedded app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv4.29.0
    • changedInput schema / properties / layout / description
      Previous value: -"Overlay composition. 'graph' (default) is the classic bodygraph rectangle with connected channels classified by connection type; 'mandala' nests the same overlay inside the concentric ring set the natal chart uses. Supplied by the in-iframe layout toggle."New value: +"Set by the embedded app. Default graph."
    • changedInput schema / properties / person_a / properties / latitude / description
      Previous value: -"Birth latitude, decimal degrees (+N). Optional if `location` is set."New value: +"Birth latitude (+N). Optional with `location`."
    • changedInput schema / properties / person_a / properties / location / description
      Previous value: -"Birth location, e.g. 'New York, NY' — resolved to coordinates and timezone (ambiguous names are rejected). Omitting both this and lat/lon rejects the call."New value: +"Birth place name, e.g. 'New York, NY'; geocoded. Give this or lat/lon."
    • changedInput schema / properties / person_a / properties / longitude / description
      Previous value: -"Birth longitude, decimal degrees (+E). Optional if `location` is set."New value: +"Birth longitude (+E). Optional with `location`."
    • changedInput schema / properties / person_b / properties / latitude / description
      Previous value: -"Birth latitude, decimal degrees (+N). Optional if `location` is set."New value: +"Birth latitude (+N). Optional with `location`."
    • changedInput schema / properties / person_b / properties / location / description
      Previous value: -"Birth location, e.g. 'New York, NY' — resolved to coordinates and timezone (ambiguous names are rejected). Omitting both this and lat/lon rejects the call."New value: +"Birth place name, e.g. 'New York, NY'; geocoded. Give this or lat/lon."
    • changedInput schema / properties / person_b / properties / longitude / description
      Previous value: -"Birth longitude, decimal degrees (+E). Optional if `location` is set."New value: +"Birth longitude (+E). Optional with `location`."
    • changedInput schema / properties / render_token / description
      Previous value: -"Supplied by the embedded app when it re-renders a chart it already paid for (e.g. to match the host's light/dark theme)."New value: +"Set by the embedded app."
    • changedInput schema / properties / theme / description
      Previous value: -"Visual theme for the overlay bodygraph. Supplied by the embedded app to match the host; defaults to dark."New value: +"Set by the embedded app. Default dark."
  2. Changed5 schema fields changedv4.24.2
    • changedInput schema / properties / layout / description
      Previous value: -"Overlay composition. 'graph' (default) is the classic bodygraph rectangle with connected channels classified by connection type; 'mandala' nests the same overlay inside the concentric ring set the natal chart uses. Set by the in-iframe layout toggle, never by the model."New value: +"Overlay composition. 'graph' (default) is the classic bodygraph rectangle with connected channels classified by connection type; 'mandala' nests the same overlay inside the concentric ring set the natal chart uses. Supplied by the in-iframe layout toggle."
    • changedInput schema / properties / person_a / properties / location / description
      Previous value: -"Birth location, e.g. 'New York, NY' — resolved like location_search (ambiguous names throw). Omitting both this and lat/lon rejects the call rather than defaulting to 0°N 0°E."New value: +"Birth location, e.g. 'New York, NY' — resolved to coordinates and timezone (ambiguous names are rejected). Omitting both this and lat/lon rejects the call."
    • changedInput schema / properties / person_b / properties / location / description
      Previous value: -"Birth location, e.g. 'New York, NY' — resolved like location_search (ambiguous names throw). Omitting both this and lat/lon rejects the call rather than defaulting to 0°N 0°E."New value: +"Birth location, e.g. 'New York, NY' — resolved to coordinates and timezone (ambiguous names are rejected). Omitting both this and lat/lon rejects the call."
    • addedInput schema / properties / render_token
      Added value: +{
+  "description": "Supplied by the embedded app when it re-renders a chart it already paid for (e.g. to match the host's light/dark theme).",
+  "type": "string"
+}
    • changedInput schema / properties / theme / description
      Previous value: -"Visual theme for the overlay bodygraph. Set automatically by the embedded app to match the host; defaults to dark. You normally never need to pass this."New value: +"Visual theme for the overlay bodygraph. Supplied by the embedded app to match the host; defaults to dark."
  3. Addedv4.8.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description goes well beyond them: it discloses the exact cost (5 credits = composite 3 + render 2) and that output modality varies by client (inline interactive bodygraph in Claude/ChatGPT, text summary elsewhere). That credit and rendering-fallback detail is information an agent cannot obtain from any structured field.

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 trigger phrasings, then the return shape, then cost — a sensible ordering with little wasted wording. The closing attribution sentence (Ra Uru Hu / Jovian Archive disclaimer) is legally useful but does not help an agent select or invoke the tool, so it slightly dilutes an otherwise tight definition.

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?

There is no output schema, so the description carries the return-value burden and does so: it names the artifact (overlay bodygraph) and enumerates the four channel classifications (electromagnetic, companionship, dominance, compromise) with their meanings. For a nested two-person input tool, nothing an agent needs in order to call it 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 coverage is 100% and each nested birth field is already documented in the schema, so the description needs to add little. It only clarifies that person_a and person_b are two distinct people; theme, layout, and render_token are marked 'set by the embedded app' in the schema and receive no further explanation here. 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 and resource (two people's HD charts overlaid into an interactive composite bodygraph) and distinguishes it from the single-person HD siblings by naming the output as a 'two-person overlay bodygraph'. An agent can tell this apart from explore_human_design or human_design_chart without opening the schema.

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?

Opens with concrete user phrasings ('are we compatible in Human Design', 'what's our connection chart', 'what channels do we make together', 'show our composite bodygraph') that make the selection condition explicit. However, it never names the adjacent alternatives an agent might wrongly pick — ephemeris_synastry, explore_bi_wheel, or explore_human_design — so there are no stated exclusions.

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