Skip to main content
Glama

Mesoamerican Astrology MCP Server by RoxyAPI

by com.roxyapi
OverviewDiscussionsAdmin

Convert a Maya Long Count - Long Count calendar converter API

post_mesoamerican_astrology_mayan_long_count_convert
Destructive

Maya Long Count converter that runs both ways: give it a Gregorian date and it returns the Long Count, give it a dotted Long Count and it returns the date. Every answer carries the Julian Day Number, the elapsed day count and the Calendar Round, and the correlation constant is a typed parameter so a value can be matched against any published inscription reading. Built for epigraphy tools, museum and education apps, and anything that has to place a Maya date on a civil calendar.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoProleptic Gregorian date to convert INTO a Long Count. Supply this or longCount, never both and never neither.
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.
longCountNoDotted Long Count to convert INTO a date, written baktun.katun.tun.winal.kin. Each position is bounded by its own base, and the winal counts to 17 rather than to 19 because eighteen winal make a tun, so 9.12.11.18.0 is rejected as a date that does not exist. Supply this or date, never both and never neither.
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

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYes
noteNo
longCountYes
conventionsYes
lordOfNightYes
calendarRoundYes
daysSinceEpochYes
julianDayNumberYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "calendarRound": {
+      "type": "string"
+    },
+    "conventions": {
+      "properties": {
+        "correlation": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "correlation"
+      ],
+      "type": "object"
+    },
+    "date": {
+      "type": "string"
+    },
+    "daysSinceEpoch": {
+      "type": "number"
+    },
+    "julianDayNumber": {
+      "type": "number"
+    },
+    "longCount": {
+      "type": "string"
+    },
+    "lordOfNight": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "date",
+    "longCount",
+    "daysSinceEpoch",
+    "julianDayNumber",
+    "calendarRound",
+    "lordOfNight",
+    "conventions"
+  ],
+  "type": "object"
+}
  2. First observed

TDQS

B3.3/5.0
Behavior1/5

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

Annotations declare destructiveHint=true, yet the description presents a pure, read-only converter with no mention of side effects, data modification, or destructive behavior. This is a direct contradiction, and the description makes no attempt to reconcile or explain the destructive hint. This is a serious inconsistency that misleads agents.

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?

Three sentences with no fluff: the bidirectional purpose is front-loaded, followed by output fields and use cases. It is concise and well-structured, though it could be slightly tighter by removing the final sentence about use cases.

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

Completeness2/5

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

Despite rich schema and output schema, the description fails to address the destructiveHint=true annotation, which is critical for an agent deciding whether to invoke the tool. It also never clarifies whether the tool has any side effects, permissions, or state changes. The contradiction leaves a major gap in completeness.

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 detailed parameter docs (e.g., longCount's winal counting rule, correlation enum offsets). The description adds only a minor rationale that correlation is a typed parameter to match inscriptions, which does not significantly exceed the schema. 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?

The description states a specific verb and resource: 'Maya Long Count converter that runs both ways: give it a Gregorian date and it returns the Long Count, give it a dotted Long Count and it returns the date.' This clearly distinguishes it from sibling astrology tools, which focus on day signs, trecenas, and horoscopes rather than calendar conversion.

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 phrase 'Built for epigraphy tools, museum and education apps, and anything that has to place a Maya date on a civil calendar' gives clear context for when to use the tool. It does not explicitly name alternatives or exclusions, but no sibling tool performs this exact conversion, so the usage context is adequately implied.

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