Skip to main content
Glama
Sign In
Ancient Echoes MCP

Ancient Echoes MCP

by FlamesCN
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Solar Terms

almanac.get_solar_terms
Read-only

Returns exact Beijing-time timestamps for the 24 solar terms in a specified Gregorian year, and reports missing data as an error rather than fabricating times.

Instructions

查询明确年份的二十四节气北京时间精确到秒时刻；时刻来自 lunar-go 寿星天文历核心表，缺失时返回错误而不是伪造正午。

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>"
    },
    "name": "almanac.get_solar_terms"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYes明确公历年份；服务端不会用当前年份补齐。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.8/5.0
Behavior4/5

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

With readOnlyHint already covering the safety profile, the description adds real behavioral context: the data source (lunar-go 寿星天文历 core table), the timezone basis (Beijing time), the precision (to the second), and the failure mode (returns an error rather than fabricating a noon value). That failure-mode disclosure is especially useful for an agent deciding how to handle gaps.

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?

One front-loaded sentence with a semicolon-separated qualifier; every clause carries information (scope, precision, provenance, failure behavior) and there is no filler.

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 read-only, single-parameter tool with no output schema, the description covers provenance, precision, timezone, and error behavior. The only modest gap is the exact return shape (e.g., a list of 24 labeled timestamps), which is implied but not stated.

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 coverage is 100% and the single parameter already documents that the year must be explicit and will not be auto-filled. The description's '明确年份' restates that constraint rather than adding new meaning, so the baseline 3 applies.

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 names a specific verb (查询/query) and resource (二十四节气, the 24 solar terms), scoped to an explicit year with Beijing-time second-level precision. That is enough to distinguish it from day-level siblings like almanac.get_day, though it never names a sibling explicitly.

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?

Usage is only implied: it signals that an explicit year must be supplied (reinforced by the schema note that the server will not default to the current year). There is no statement of when to prefer this over almanac.get_day or almanac.convert_lunar_date, and no exclusions.

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

Deploy Server

Other Tools