Skip to main content
Glama

AstroWay Human Design

Incarnation Cross

astroway_hd_incarnation_cross
Read-onlyIdempotent

Return the Incarnation Cross from birth data (or directly from gate numbers). Includes cross name, type, and theme description. With gate numbers, personalitySunLine and designSunLine decide the angle: lines 1-3 and profile 4/6 are right angle, 4/1 juxtaposition, 5 and 6 left angle.

[Group: Human Design] [Endpoint: POST /v1/hd/incarnation-cross] [Required: date, time, latitude, longitude] [Cost: 50 credits (Tier 3)]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date": "<date>",
      "time": "<time>",
      "latitude": "<latitude>",
      "longitude": "<longitude>"
    },
    "name": "astroway_hd_incarnation_cross"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityNo
dateYes
nameNo
timeYes
fieldsNoCompact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response.
ayanamsaNoSidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either.
latitudeYes
timezoneNoIANA zone name such as Europe/Kyiv, or auto to look the zone up from latitude and longitude. The server takes the offset that zone kept at this local date and time, summer time included, and uses it in place of timezoneOffset. A clock time that happened twice takes the first occurrence; one skipped when clocks went forward takes the offset from before the change. Abbreviations such as EST are refused. Before 1970 the tz database is not reliable for every place, so send timezoneOffset when the local clock is known.
cosmogramNo
longitudeYes
precisionNoCompact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn.
ayanamsaIdNo
zodiacTypeNo
houseSystemNoP
timezoneOffsetNoHours from UTC at the given moment, not minutes. Fractional zones are hours too: 5.5 for India, 5.75 for Nepal, -3.5 for Newfoundland. Defaults to 0, meaning UTC. Ignored when timezone is sent.

Output Schema

NameRequiredDescriptionDefault
nameNo
typeNo
gatesNo
linesNo
themeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • removedInput schema / properties / ayanamsaId / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / ayanamsaId / type
      Added value: +[
      +  "number",
      +  "null"
      +]
    • changedOutput schema / properties / gates / anyOf
      Previous value: -[
      -  {
      -    "items": {
      -      "anyOf": [
      -        {
      -          "type": "number"
      -        },
      -        {
      -          "type": "null"
      -        }
      -      ]
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "items": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "type": "array"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedOutput schema / properties / lines / anyOf
      Previous value: -[
      -  {
      -    "items": {
      -      "anyOf": [
      -        {
      -          "type": "number"
      -        },
      -        {
      -          "type": "null"
      -        }
      -      ]
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "items": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "type": "array"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / theme / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / theme / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / type / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / type / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real operational context absent from them: the endpoint path, the cost of 50 credits at Tier 3, and the deterministic rule mapping sun lines/profile to right-angle, juxtaposition or left-angle crosses. It does not discuss error behavior or how gate-number mode is actually supplied, but for a read-only computation this is solid added value.

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 core capability is front-loaded in the first sentence, with the angle rule, group, endpoint, required fields and cost packed into short bracketed lines. The second sentence is dense but earns its place by explaining a real derivation rule; nothing is redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is rightly omitted, and cost/endpoint/required fields are supplied. But for a 15-parameter, high-cost tool, the description omits how design date is derived, how the gate-number path is parameterized (it isn't in the schema), and what the non-HD astrology parameters mean for an HD result. Adequate but with a notable gap around the advertised alternate mode.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 15 parameters and only 33% schema description coverage, the description would need to compensate heavily, but it mentions only personalitySunLine and designSunLine — neither of which exists in the schema, since no gate-number parameters are defined at all. The many chart-shaping parameters (zodiacType, houseSystem, ayanamsa, fields, precision) are never addressed, and the advertised alternate input mode is unsupported by the documented schema.

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?

The description gives a specific verb and resource ("Return the Incarnation Cross") and even enumerates the returned components (cross name, type, theme description), plus two input paths. It does not distinguish this from nearby HD siblings such as astroway_hd_human_design or astroway_hd_hologenetic, which likely also surface an incarnation cross, so the agent must infer the boundary.

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?

It names two modes (birth data vs. direct gate numbers) and explains the angle-derivation rule, which is genuine in-tool guidance. However, there is no statement of when to choose this tool over the many other Human Design endpoints, nor any prerequisite or exclusion guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources