get_koyomi_entity名前（例: 春分の日・土用の丑の日・十五夜・一粒万倍日・戌の日・不成就日・節分・彼岸）から、その年の日付・次はいつ・あと何日・定義・根拠を返す。二十四節気・雑節の名前（例: 秋分・春分・二百十日・春の彼岸入り）でも引ける。year を指定するとその年、from_date（省略時は今日）を指定すると次の日。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 名前・読み・別名・slug | |
| year | No | ||
| from_date | No | YYYY-MM-DD（1926-01-01〜2080-12-31） |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive and closed-world, so the safety bar is met; the description adds the output shape (year's date, next date, days remaining, definition, basis), which matters since no output schema exists. It does not state formatting or what happens for unknown names, keeping it at 4.
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, front-loaded with the resource and its output fields, then the alternate query mode. The example lists are long but each example teaches the accepted name vocabulary, so they earn their space.
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 3-parameter lookup with no output schema, the description covers what is returned and how year vs from_date behave, which is enough to call it correctly. Minor gaps remain around failure behavior for unknown or ambiguous names.
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 67%, and the description adds meaning beyond it: it clarifies that year selects a specific year while from_date (default today) yields the next occurrence, an interaction the schema does not express. The name parameter's accepted forms (読み/別名/slug) are left to the schema text.
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+resource: look up a calendar event by name (with concrete examples of the name vocabulary) and return its date, next occurrence, countdown, definition and 根拠. The 'by name' framing implicitly separates it from date-based siblings like find_dates or search_lucky_days, but no sibling is named explicitly.
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 final sentence tells the agent which parameter to reach for (year = that year, from_date defaults to today = next occurrence), which is real operational guidance. However, there is no statement of when to prefer this tool over find_dates / search_lucky_days / get_koyomi_day.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.