Skip to main content
Glama
Ancient Echoes MCP

Ancient Echoes MCP

Lunar Date Conversion

almanac.convert_lunar_date
Read-only

Converts a specified lunar year, month, and day—including optional leap-month status—into its Gregorian date, validating year range, leap month existence, day count, and conversion consistency.

Instructions

将明确的农历年月日转换为公历日期;校验年份范围、闰月是否存在、当月天数与转换回显一致性。

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": {
      "year": "<year>",
      "month": "<month>",
      "day": "<day>"
    },
    "name": "almanac.convert_lunar_date"
  }
}

Input Schema

NameRequiredDescriptionDefault
dayYes
yearYes
monthYes农历月使用正数 1-12;是否闰月由 is_leap_month 单独声明。
is_leap_monthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, and the description adds genuinely new behavioral context: the tool validates year range, leap-month existence, days in the month, and round-trip consistency, so the agent knows invalid inputs will be rejected rather than silently converted. It still does not describe the response payload or error format, which keeps it from a 5.

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 single sentence is front-loaded with the core conversion action and uses a semicolon to attach the validation clause. No redundant restatement of the tool name, though the dense clause stacking is slightly harder to parse than a short two-sentence split would be.

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?

With no output schema, the description should hint at the return value, yet it only alludes to '转换回显一致性' without saying whether a Gregorian date, an echo of inputs, or both are returned. For a 4-parameter conversion tool this is adequate but leaves a real gap about what the agent receives.

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 only 25% (only month is documented), so the description must compensate. It partially does by tying leap-month existence and year range to the conversion constraints, implying the role of is_leap_month, but it never explains leap-month declaration syntax or day-boundary behavior beyond what the schema's min/max already show.

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 states a specific verb and resource: convert an explicit lunar year/month/day into a Gregorian date. This clearly distinguishes it from siblings such as almanac.get_day or almanac.get_solar_terms, but it does not explicitly name a sibling or state which tool to use instead when only a solar date is known.

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?

The phrase '将明确的农历年月日' implies the tool is used only when a lunar date is already known precisely, which is an implicit usage condition. No explicit when-to-use/when-not-to-use guidance or alternative tool routing is provided, so the agent must infer the context.

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