Mesoamerican Astrology MCP Server by RoxyAPI

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond this: content is fixed per date, rolls over at midnight UTC, and is cacheable/plannable. This tells the agent the tool is deterministic and timezone-anchored, which is useful for caching and scheduling. It could have mentioned response shape, but annotations lower the bar for safety disclosure.

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

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

Three sentences with no filler. The first sentence front-loads the core purpose and result content; the second adds the caching-relevant behavioral detail; the third names target use cases. Every sentence earns its place.

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

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

For a read-only tool with zero required parameters and no output schema, the description covers the essential return fields (day sign, coefficient, trecena, composed reading), the date flexibility, and the UTC rollover behavior. Combined with the fully descriptive schema, an agent has everything needed to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the input schema already fully documents date, lang, and compact including defaults, formats, and semantics. The description adds no parameter-specific meaning, but under the high-coverage baseline of 3, that is appropriate.

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

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

The description states a specific resource and action: it returns the tonalpohualli day sign, its coefficient, its trecena, and a composed reading for a given date. It clearly differentiates from sibling tools by emphasizing the 'daily' / date-specific nature versus listing endpoints like day_signs or trecenas, and by specifying Aztec rather than Mayan.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete use cases: 'daily energy widgets, Mexica day sign feeds and chatbot answers about what today carries.' It also implies the tool is for date-specific queries rather than static reference lists, but it does not explicitly name alternatives or state when not to use this tool.

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

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 that results are ordered from Cipactli to Xochitl and complete in one call, but does not disclose pagination, language fallback, or compact-response behavior; those live in the schema, so a 3 is appropriate.

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

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

Two efficient sentences with no filler: the first states what is retrieved and returned, the second states intended use cases. Key scope information is front-loaded.

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

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

For a simple read-only list endpoint with 100% schema coverage and no required parameters, the description covers the domain, output fields, ordering, and use cases. It does not describe the exact JSON envelope, but with no output schema that is a minor gap; the schema and annotations cover the rest.

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

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

Schema description coverage is 100% and each parameter (lang, limit, offset, compact) already carries a detailed description with defaults and ranges. The tool description adds no parameter-specific meaning, so the baseline 3 applies.

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

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

The description opens with a specific action and resource: 'Retrieve all twenty tonalpohualli day signs in sequence order from Cipactli to Xochitl.' It also states the output fields and explicitly frames this as 'the whole set in one call,' which distinguishes it from the singular get_..._day_signs_id and Mayan siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear use cases: 'Built for Aztec sign pickers, Mexica calendar reference pages and any app that needs the whole set in one call.' However, it does not explicitly say when not to use it or name the single-sign alternative, so it falls short of a full 5.

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

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 known. The description adds useful context about what the response contains (keynote, guidance, direction), but does not describe behavior such as language fallback or how invalid IDs are handled. The description does not contradict the annotations.

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

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

Two tight sentences with no filler. The main action and scope are front-loaded, then the content is listed, and the intended use cases close it out. Every sentence earns its place.

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

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

For a read-only single-resource lookup with fully documented parameters and safe annotations, the description covers the essential behavior and output contents. There is no output schema, but the listed fields give a reasonable preview. It does not mention error cases or language fallback, but the schema covers lang defaults well enough.

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

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

Schema description coverage is 100%, so the input schema already thoroughly documents id, lang, and compact with enums, defaults, and examples. The description does not need to repeat parameter details. It adds no additional meaning beyond the schema, matching the baseline for full schema coverage.

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

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

The description uses a specific verb and resource: 'Retrieve the full profile of one tonalpohualli day sign' and enumerates the delivered content (Nahuatl name, meaning, direction, keynote, guidance). It also clearly distinguishes this singular-resource tool from the plural sibling by emphasizing 'one' and 'single Mexica sign,' plus the stated use case of detail pages and single-sign chatbot answers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: it is 'Built for Aztec sign detail pages, day sign cards and chatbot answers about a single Mexica sign.' This implies it should be used for single-sign lookups rather than list-level endpoints. It does not explicitly name alternatives like get_mesoamerican_astrology_aztec_day_signs for multi-sign queries, so it stops short of a full when-not-to-use statement.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context by disclosing what each returned entry contains: the period number, the opening day sign, and a composed reading. This is valuable because no output schema exists to document the response shape.

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

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

The description is three tight sentences: it introduces the resource, explains the response contents, and states the target use cases. There is no filler, and the core purpose is front-loaded in the first sentence.

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

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

For a simple read-only list endpoint with no output schema, the description adequately explains what the tool returns and who it is for. It could go further by mentioning pagination behavior or pointing to the single-trecena sibling, but the essential information needed to invoke it correctly is present.

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

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

The input schema has 100% description coverage for all four parameters (lang, limit, offset, compact), so the schema fully carries parameter documentation. The description does not restate or deepen parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description names a specific verb and resource: 'Retrieve all twenty trecenas, the thirteen day periods the 260 day tonalpohualli divides into.' It also states exactly what each entry contains, and the 'all twenty' wording distinguishes it from the sibling get_mesoamerican_astrology_aztec_trecenas_number endpoint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly frames intended use: 'Built for Aztec calendar apps, energy period trackers and content planners that work in thirteen day blocks.' It gives strong context but does not explicitly name the alternative for retrieving a single trecena by number, so it lacks explicit when-not-to-use guidance.

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

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

Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false) and the description is consistent with them ('Retrieve'). The description adds modest context about response contents (opening day sign and composed reading) but does not disclose behavior on invalid input, response limits, or any other operational traits. With annotations present, this is adequate but not rich.

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

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

Two sentences with zero filler. The first sentence front-loads the action and return contents; the second adds use cases. Every word earns its place.

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

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

For a simple tool with one required parameter, exhaustive schema documentation, and safety annotations, the description covers purpose, return contents, and use cases. It could additionally note that the plural trecenas endpoint covers the full set of twenty, but nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents number (1-20 with opening-sign examples like 'Trecena 1 opens on 1 Cipactli'), lang (enum with English fallback behavior), and compact (columnar shape and token savings). The description's 'by number' adds no meaning beyond the schema, so it lands at the baseline 3.

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

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

States a specific verb and resource: 'Retrieve one of the twenty tonalpohualli trecenas by number,' and names the return contents ('the day sign it opens on and a composed reading of the period'). The singular 'one of the twenty... by number' distinguishes it from the plural sibling get_mesoamerican_astrology_aztec_trecenas and from the Mayan counterpart get_mesoamerican_astrology_mayan_trecenas_number.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use cases: 'Built for period detail pages and for apps that show which thirteen day block a date falls in.' This is clear context for when to invoke the tool, but it stops short of naming alternatives or stating when not to use it, such as redirecting to the list sibling when all twenty trecenas are needed.

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

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 useful behavior beyond annotations by stating the response is 'fixed for any month that has already begun' and by enumerating exactly what each day entry contains. This gives an agent a clear expectation of determinism and payload scope.

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

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

The description is three sentences with no filler: the first states the core deliverable, the second explains efficiency and determinism, and the third cites concrete use cases. Each sentence earns its place and the most important information is front-loaded.

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

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

For a tool with no output schema, the description adequately summarizes the response contents and the primary use case. It could go further by noting the response structure or grouping, but the input schema covers all optional parameters and defaults, so nothing critical is missing.

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

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

Schema description coverage is 100%, and each parameter already has a detailed description including defaults, ranges, enums, and behavior. The tool description adds no additional parameter semantics, so it does not exceed the baseline of 3.

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

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

The description states a specific verb-like resource: 'Mayan calendar grid for a whole civil month' with explicit contents: Tzolkin day sign, coefficient, trecena, Haab date, and Long Count. It clearly differentiates from the daily sibling routes by noting a single call would otherwise take 'a request per day.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for use: 'Built for calendar widgets, editorial planners and any app that shows a month of Maya dates at once.' It also implies the alternative daily route by noting one call replaces a request per day, though it does not name the sibling tool explicitly.

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

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

Beyond the readOnlyHint annotation, the description discloses that content is fixed for a given date, rolls over at midnight UTC, and is safe to cache and pre-fill weeks ahead. These are useful behavioral guarantees that materially affect how an agent can schedule and cache calls.

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

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

Three sentences, each earning its place: the first defines the deliverable, the second gives deterministic caching behavior, and the third states target use cases. The core value is front-loaded and there is no redundant filler.

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

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

With no output schema, the description still names the key returned components: day sign, coefficient, trecena, and composed reading. Combined with the rich parameter schema and strong behavioral context, this is nearly complete, though an explicit response-shape hint would make it fully self-sufficient.

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

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

Schema description coverage is 100%, and the schema already provides detailed semantics for date, lang, compact, and correlation. The description adds only a minor supporting note that any date can be named, so it meets the baseline but does not meaningfully go beyond the schema.

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

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

The description states a specific verb-resource combination: it returns the Tzolkin day sign, its coefficient, and its trecena for today or a named date, with a composed reading. This clearly distinguishes it from sibling reference tools like mayan_day_signs, mayan_trecenas, and calendar_monthly, while the Mayan-vs-Aztec framing separates it from the aztec_daily sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases: daily energy widgets, nawal of the day feeds, and chatbot answers about what today carries. It does not explicitly name sibling tools or state when not to use this tool, but the intended context is clear enough for an agent to route appropriately.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is already conveyed. The description adds useful behavioral specifics: deterministic ordering, the inclusion of historical orthography, Kʼicheʼ names, glosses, and scheme-dependent direction/colour values. It does not go into pagination behavior, but the annotations plus schema cover the key operational expectations.

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

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

A single dense sentence that front-loads the core action and resource, then efficiently lists return contents and intended use cases. Every clause adds information — no filler, no repetition of schema details, and the use-case closing sentence earns its place.

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

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

Given no output schema, the description reasonably compensates by enumerating what each returned entry contains and the ordering guarantee. Pagination and language fallback behavior are left to the schema, which documents them fully. The only mild gap is not explicitly routing the agent away from the single-sign sibling, but the 'whole set' wording largely covers that.

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

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

Schema description coverage is 100%, so the schema fully documents all five parameters, including enum meanings, defaults, compact-shape behavior, and ranges. The description references the 'requested scheme' for direction/colour, but adds no semantic detail beyond the schema's own thorough parameter descriptions. Baseline 3 applies.

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

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

States a specific verb ('Retrieve'), a precise resource ('all twenty Tzolkin day signs'), and an ordering guarantee ('in sequence order from Imix to Ajaw'). This clearly differentiates it from sibling tools like the single-sign ID endpoint or the daily/monthly tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Offers explicit use cases ('nawal pickers, sign reference pages') and frames the tool as serving 'the whole set in one call.' It does not name sibling alternatives explicitly or state when not to use it, but the intended usage context is clear.

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

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

Annotations already mark the operation as read-only, and the description adds rich behavioral content: both naming traditions, glosses, direction/colour under the requested scheme, a keynote, strengths, costs, and guidance. It does not describe the exact response shape, but no output schema exists and the listed contents give a strong expectation of what the tool returns.

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

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

Two dense sentences with the action and resource front-loaded. The long content list is not padding; each item helps shape expected output. No wasted words.

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

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

For a read-only single-item lookup, the description covers the resource, use case, and returned content domains. The schema already handles language fallback, compact shape, and directionScheme details, while annotations cover the safety profile, so the description is sufficiently complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds mild meaning by tying 'under the requested scheme' to directionScheme and 'one... sign' to id, but lang and compact are only explained in the schema.

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

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

The description uses a specific verb ('Retrieve the full profile') and names the resource ('one Tzolkin day sign') with an explicit content list. It clearly distinguishes this per-id tool from the sibling list endpoint by emphasizing a single sign.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states it is built for nawal detail pages, sign cards, and chatbot answers about a single Mayan sign, giving clear context for when to use it. It does not explicitly tell the agent to use the plural day-signs sibling when a list of all signs is needed, so there is no explicit exclusion.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds valuable behavioral context by listing exactly what each entry returns: machine id, both spellings, length, meaning, and composed reading. It also explains the structure of the 19 periods (18 months of 20 days plus Wayebʼ).

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

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

Three sentences with no filler. The main purpose is front-loaded in the first sentence, the return content is in the second, and the intended use case is in the third. Every sentence earns its place.

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

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

The description is complete enough for a list tool with no required parameters, a fully documented schema, and read-only annotations. It covers the domain logic, return fields, and use case. A minor improvement would be noting that there is a companion endpoint for fetching a single Haab month by id, but this is not essential for correct invocation.

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

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

Schema coverage is 100%, so all four parameters are already well documented. The description adds contextual meaning by explaining why there are nineteen periods, which corresponds to the limit parameter's maximum, but it does not add new parameter-level guidance beyond the schema.

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

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

The description opens with a specific verb and resource: 'Retrieve all nineteen periods of the Haab', clearly identifying the exact scope of the tool. It differentiates itself from the sibling get_mesoamerican_astrology_mayan_haab_months_id by emphasizing the full list of all periods rather than a single period.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear intended use case: 'Built for calendar reference pages and for any app that has to label a Haab date rather than only compute it.' This tells an agent when the list is appropriate, though it does not explicitly mention alternatives like the individual month endpoint or when to prefer those.

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

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 and there is no contradiction. The description adds useful output-content context (name spellings, position, length, composed reading) but does not disclose operational behavior such as not-found handling or any response edge cases.

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

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

Two sentences, with the action and core output in the first and concrete use cases in the second. There is no filler, repeated title text, or schema duplication.

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

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

For a simple read-only lookup with no output schema, the description gives enough orientation: it names the exact resource, the id input, and the main fields returned. It remains slightly ambiguous what a 'composed reading' contains and does not hint at error/not-found behavior, so some agent-facing uncertainty is left open.

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

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

The schema already documents all three parameters, including enums, defaults, and the compact format, so the description does not need to add parameter-level detail and earns the baseline 3. The description's phrase 'by id' confirms the sole required parameter but adds no new semantics beyond the schema.

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

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

The opening verb 'Retrieve' plus the object 'one of the nineteen Haab periods by id' states exactly what the tool does, and 'by id' distinguishes it from the plural Haab-months sibling without restating the tool name. It also names the returned data, so an agent knows the resource and result before 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives concrete contexts ('calendar detail pages' and 'labeling a Haab date a chart route has already returned'), which makes the intended call sites clear. It does not explicitly name the alternative plural list route or state when not to use this tool, so it falls just short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context by explaining what each entry contains: the period number, the opening day sign in both naming traditions, and a composed reading. This goes beyond the schema and gives the agent a clear picture of the response shape despite there being no output schema.

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

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

Three sentences, each earning its place: the first states the core purpose, the second describes the return content, and the third names the intended audience. It is front-loaded and free of filler.

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

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

For a read-only list tool with four optional, fully documented parameters and no output schema, the description provides the essential missing context: it states the full scope (twenty trecenas), the shape of each entry, and the intended use case. An agent can invoke it correctly without additional clarification.

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

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

Schema description coverage is 100%, so the parameters (lang, limit, offset, compact) are already fully documented. The description does not add parameter-level meaning, which is acceptable because the schema carries the load. Baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'Retrieve all twenty trecenas, the thirteen day periods the 260 day Tzolkin divides into.' It clearly signals this is a list-all operation and differentiates from the singular sibling mayan_trecenas_number by emphasizing 'all twenty.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear intended use case: 'Built for calendar apps, energy period trackers and content planners that work in thirteen day blocks rather than in weeks.' It does not explicitly name alternatives or say when not to use this tool, but the context is strong enough to guide selection.

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

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 useful context about the response content, but does not disclose behavior for invalid numbers, missing translations, or the exact response structure. This is acceptable given the annotations but not exceptional.

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

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

Two sentences with no filler: the first states the action and output, the second provides use-case context. Every phrase earns its place and the core information is front-loaded.

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

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

Given there is no output schema, the description does indicate what the response contains: the opening day sign in both naming traditions and a composed reading. The parameter documentation is thorough. Minor gaps like exact field names or out-of-range behavior do not prevent a correct call.

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

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

Input schema coverage is 100% and each parameter has a detailed description, including the number range, language fallback behavior, and compact output shape. The tool description adds little beyond 'by number,' so the schema carries the semantic weight—baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Retrieve one of the twenty trecenas by number.' It also names the key returned content—opening day sign in both naming traditions and a composed reading—so the tool's purpose is unambiguous and distinguishable from the sibling list endpoint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete intended contexts: 'Built for period detail pages and for apps that show which thirteen day block a date falls in.' It does not explicitly name alternatives or state when not to use it, but the use cases are clear enough for an agent to route appropriately.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds useful behavioral context beyond annotations, including the anchor on the fall of Tenochtitlan, verification on the anchor and two modern dates, and alignment with the Maya count under the default constant. No contradictions with the annotations are present.

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

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

The description is three sentences with each earning its place: the first sentence states the core output, the second provides calibration and verification context, and the third names target use cases. Information is front-loaded, and there is no redundant wording.

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

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

With no output schema, the description usefully enumerates the returned items: day sign, coefficient, trecena, and composed reading. It also provides anchoring and verification context that helps an agent trust results. It could be slightly more explicit about the shape of the composed reading or error handling, but for a calculator-style read-only tool it is adequately complete.

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

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

Schema description coverage is 100%, and the input schema already provides rich detail on date format, proleptic Gregorian behavior, language defaults, and compact output shape. The description does not add meaningful parameter-level meaning beyond what the schema supplies, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: it 'returns the tonalpohualli day sign, its coefficient 1 to 13 and its trecena for any Gregorian date, with a composed reading.' This clearly distinguishes it from sibling list/table tools and other Mesoamerican calendar endpoints, making the tool's purpose immediately identifiable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies the use case: 'Built for Aztec calendar apps, Mexica day sign features and AI agents answering what is my Aztec sign.' It gives clear context for when to call this tool, though it does not explicitly name alternatives or say when not to use it, so it stops short of full exclusionary guidance.

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

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

The readOnlyHint=true and destructiveHint=false annotations already establish that the call is safe and non-destructive. The description adds useful behavioral context: every school split is a typed parameter and is echoed back in the response so the chart can be reproduced exactly. No contradiction with the annotations is present.

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

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

The description is three sentences, each with a distinct job: enumerating outputs, stating target use cases, and explaining reproducibility. The first sentence is dense and front-loaded, and there is little waste, though the second sentence is slightly wordy.

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

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

For a tool with no output schema, the description lists all major output components and the parameter behavior needed to reproduce a chart. The input schema covers date restrictions, language, compact shape, and correlation constants, so the combined information is sufficient for an agent to invoke it correctly.

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

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

The input schema covers all 5 parameters at 100% with detailed descriptions, defaults, enums, and examples, so the description does not need to repeat parameter mechanics. The description adds only a high-level note that school splits are typed parameters and echoed, which is helpful but not necessary given the schema depth.

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

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

The description clearly specifies the resource: a Mayan astrology birth chart generated from a single date, and enumerates all major computed components: Tzolkin day sign and coefficient, Haab date, Long Count with day count, Calendar Round, Lord of the Night, Year Bearer, and Cruz Maya. This distinguishes it from sibling tools like daily Mayan readings, compatibility, or long-count conversion tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states concrete use cases: nawal readings, birth chart features, and spiritual apps showing a Mayan card beside a natal chart. It does not explicitly name alternatives or give when-not-to-use conditions, but the one-date birth chart framing and sibling tool names make the intended selection clear.

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

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

Beyond the readOnly/destructive annotations, the description reveals meaningful behavior: it returns components rather than a verdict, the ties are either present or absent, and the scoring weights are always included so a caller can re-derive or replace the composite score. This materially shapes caller expectations and adds value beyond what annotations alone provide.

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

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

The description is three sentences with no redundancy. The first sentence front-loads the operation, output philosophy, and response components; the second gives use cases; the third adds a valuable reproducibility guarantee. Every sentence earns its place.

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

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

With no output schema, the description compensates well by describing the response's major parts: nawals, coefficients, trecenas, five ties, weights, and composite score. The parameter schema is rich, so invocation is well covered. It stops short of naming the five ties or exact field shapes, which prevents a perfect score.

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

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

Schema description coverage is 100%, so all six parameters — including correlation and directionScheme — are already documented in the input schema. The description adds no parameter-level detail, which is acceptable because the schema carries the full semantic burden. Baseline 3 applies.

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

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

The description opens with a specific verb and resource: Mayan compatibility between two birth dates. It differentiates this from sibling endpoints by emphasizing that results are 'published as its parts rather than as a verdict' and enumerates the exact response components (nawals, coefficients, trecenas, five structural ties, weights, composite score), making the tool's identity unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear intended contexts: 'matchmaking features, relationship reports and compatibility widgets that need to show their working.' This tells an agent when the tool is appropriate, though it does not explicitly name alternative sibling tools or state when not to use this endpoint.

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

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

The description adds useful behavioral detail beyond the annotations: every response includes the Julian Day Number, elapsed day count, and Calendar Round, and the correlation constant is parameterized rather than hidden. The destructiveHint annotation is not directly contradicted because the description never explicitly promises a side-effect-free operation, though the description reads as a pure converter and would benefit from clarifying what that flag refers to.

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

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

The description is economical: the first sentence establishes the core bidirectional behavior, the second gives response contents and the correlation design, and the third names target use cases. No filler or redundant restatement of the title.

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

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

For a tool with five parameters, no output schema, and two enums, the description is nearly complete: it covers the conversion directions, key response contents, and intended audiences. The residual gap is the unaddressed destructiveHint annotation and the lack of any error-condition guidance, which the schema only partially covers.

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

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

Schema coverage is 100%, so the parameter burden is already carried by the schema. The tool description adds conceptual value by explaining the role of the correlation constant and the output fields, which helps an agent reason about correctness without needing to re-derive semantics from the schema alone.

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

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

The description states a specific operation — bidirectional conversion between Gregorian dates and Maya Long Counts — and names the exact resource. It clearly distinguishes itself from the sibling astrology/divination tools by emphasizing pure date conversion rather than daily readings or charts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear intended contexts: epigraphy tools, museum and education apps, and civil-date placement. It also explains both invocation directions, but it does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of a 5.

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

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

Annotations already establish read-only and non-destructive behavior. The description adds useful behavioral context beyond that: it states that the correlation is 'echoed on every response so a saved reading stays reproducible,' and constrains the scope to 'Classical Maya count only.' These are meaningful behavioral guarantees not present in the annotations.

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

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

The description is compact and front-loaded, with the core purpose stated in the first clause. Every sentence earns its place: the first defines the output, the second names use cases, and the third adds a reproducibility guarantee. There is no filler or repetition.

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

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

With no output schema, the description appropriately names the key return values: day sign, coefficient, trecena, nawal reading, and echoed correlation. Parameter responsibilities are fully covered by the schema, and the read-only behavior is already annotated, so an agent has enough context to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces that the date drives the calculation and that the default correlation is the one 'living daykeepers use,' but it does not add substantial parameter-level meaning beyond the already thorough schema descriptions for date, lang, compact, and correlation.

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

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

The description opens with a specific verb and resource: 'returns the Tzolkin day sign, the coefficient 1 to 13 and the trecena for any Gregorian date.' It also names concrete outputs (nawal reading, correlation echo) and clearly exists for a distinct task — computing a Mayan day sign for a date — which separates it from sibling sign-listing and daily-feed tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear application contexts: 'Built for Mayan zodiac apps, daily energy feeds and AI agents answering what is my Mayan sign.' This tells an agent when the tool is useful, though it does not explicitly name sibling alternatives or state when not to use this tool in favor of another.

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