Skip to main content
Glama

Mesoamerican Astrology MCP Server by RoxyAPI

by com.roxyapi
OverviewDiscussionsAdmin

Mayan nawal compatibility - Tzolkin pair analysis API

post_mesoamerican_astrology_mayan_compatibility
Read-only

Mayan compatibility between two birth dates, published as its parts rather than as a verdict: both nawals with their coefficients and trecenas, the five structural ties the pair either has or does not, the weight each tie carries, and a composite score built from them. Built for matchmaking features, relationship reports and compatibility widgets that need to show their working. The scoring weights are stated on every response so a caller can re-derive the number or replace it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoResponse 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
compactNoSet 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.
personAYesThe first person, by birth date. Only a date is needed: the Tzolkin is a day count, so no time, timezone or place changes the answer.
personBYesThe second person, by birth date. The comparison is symmetric except for the cross tie, which is checked in both directions.
correlationNoWhich correlation constant ties the day count to a civil date. This is the single choice that shifts every value in the response, so it is a parameter rather than a hidden default, and the resolved value comes back under conventions. "gmt-584283" is the commonly accepted constant and the default, and it is the one the major institutional converter runs on. "martinez-hernandez-584281" sits two days earlier, "astronomical-584285" two days later, and "martin-skidmore-584286" three days later, each shifting the Long Count by exactly its difference in days. Four of the eight published constants are offered: the other four sit tens of thousands of days away and are of historical interest only. The 584281 constant is the Martínez Hernández correlation, after Juan Martínez Hernández.gmt-584283
directionSchemeNoWhich reading of the world direction and colour to serve for a day sign. The two published assignments differ by exactly one quarter turn on all twenty signs, so neither is a rounding of the other and a silent pick would be a school choice. "madrid-codex" is the codex reading and the default; "landa" is the sixteenth century assignment recorded beside it.madrid-codex

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
scoreYes
personAYes
personBYes
summaryYes
verdictYes
daysApartYes
componentsYes
conventionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "components": {
+      "items": {
+        "properties": {
+          "holds": {
+            "type": "boolean"
+          },
+          "id": {
+            "type": "string"
+          },
+          "reading": {
+            "type": "string"
+          },
+          "weight": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "id",
+          "holds",
+          "weight"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "conventions": {
+      "properties": {
+        "correlation": {
+          "type": "string"
+        },
+        "directionScheme": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "correlation",
+        "directionScheme"
+      ],
+      "type": "object"
+    },
+    "daysApart": {
+      "type": "number"
+    },
+    "personA": {
+      "properties": {
+        "date": {
+          "type": "string"
+        },
+        "daySign": {
+          "type": "string"
+        },
+        "daySignClassic": {
+          "type": "string"
+        },
+        "daySignKiche": {
+          "type": "string"
+        },
+        "daySignName": {
+          "type": "string"
+        },
+        "number": {
+          "type": "number"
+        },
+        "trecena": {
+          "properties": {
+            "dayOfTrecena": {
+              "type": "number"
+            },
+            "number": {
+              "type": "number"
+            },
+            "rulingSign": {
+              "type": "string"
+            },
+            "rulingSignName": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "number",
+            "dayOfTrecena",
+            "rulingSign",
+            "rulingSignName"
+          ],
+          "type": "object"
+        }
+      },
+      "required": [
+        "daySign",
+        "daySignName",
+        "daySignClassic",
+        "daySignKiche",
+        "number",
+        "trecena",
+        "date"
+      ],
+      "type": "object"
+    },
+    "personB": {
+      "properties": {
+        "date": {
+          "type": "string"
+        },
+        "daySign": {
+          "type": "string"
+        },
+        "daySignClassic": {
+          "type": "string"
+        },
+        "daySignKiche": {
+          "type": "string"
+        },
+        "daySignName": {
+          "type": "string"
+        },
+        "number": {
+          "type": "number"
+        },
+        "trecena": {
+          "properties": {
+            "dayOfTrecena": {
+              "type": "number"
+            },
+            "number": {
+              "type": "number"
+            },
+            "rulingSign": {
+              "type": "string"
+            },
+            "rulingSignName": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "number",
+            "dayOfTrecena",
+            "rulingSign",
+            "rulingSignName"
+          ],
+          "type": "object"
+        }
+      },
+      "required": [
+        "daySign",
+        "daySignName",
+        "daySignClassic",
+        "daySignKiche",
+        "number",
+        "trecena",
+        "date"
+      ],
+      "type": "object"
+    },
+    "score": {
+      "type": "number"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "verdict": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "personA",
+    "personB",
+    "daysApart",
+    "components",
+    "score",
+    "verdict",
+    "summary",
+    "conventions"
+  ],
+  "type": "object"
+}
  2. First observed

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 genuine behavioral context beyond that: it discloses that results are returned as parts rather than a verdict, and that 'scoring weights are stated on every response so a caller can re-derive the number or replace it' — an important contract for callers who want to audit or substitute the composite score. 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.

Conciseness5/5

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

Three sentences of zero waste. The purpose and parts-based output are front-loaded, use cases follow, and the weight re-derivability disclosure closes. Every sentence earns its place and nothing is repeated from the schema or annotations.

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 complex tool with 6 parameters, 3 enums, and nested objects, the description is strong: it states purpose, use cases, output shape, and the re-derivable scoring behavior. An output schema exists so return values need no explanation. The only minor gap is the absence of explicit routing guidance against the sibling post_mesoamerican_astrology_mayan_chart tool, which is adjacent in purpose.

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% with thorough parameter documentation (lang BCP 47 coverage, correlation constants and their day offsets, directionScheme quarter-turn difference, proleptic Gregorian calendar caveats). The description itself adds no parameter-level meaning — it does not need to, since the schema carries the full burden. The baseline of 3 applies.

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-resource pair ('Mayan compatibility between two birth dates') and details exactly what is returned: nawals with coefficients and trecenas, the five structural ties, their weights, and a composite score. The parts-based approach ('published as its parts rather than as a verdict') clearly separates it from sibling single-date tools like get_mesoamerican_astrology_mayan_daily, get_mesoamerican_astrology_mayan_tzolkin, and post_mesoamerican_astrology_mayan_chart.

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 names concrete use cases ('matchmaking features, relationship reports and compatibility widgets that need to show their working'), giving an agent clear context for when to reach for this tool. It does not explicitly state when NOT to use it or name alternative analysis tools, but its pairing focus is self-evident against the sibling set.

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

All Mesoamerican Astrology MCP Server by RoxyAPI toolsInspect
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.

Resources