Generate a full Gregorian year's daily date-selection facts and a month-switchable HTML calendar that accumulates model-filled verdicts for complete coverage.
生成完整公历年度365/366日择时事实及按月加载的HTML；模型逐批判断，回填累积全年覆盖。没有默认观测城市。
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| purpose | No | ||
| mountain | No | ||
| observer | No | ||
| rollover | No | ||
| participants | No | ||
| qimen_method | No | 拆补法 / 置闰法（九日含符首、接气借下元） | chaibu |
| noble_profile | No |
Changes observed during successful MCP inspections.
v0.3.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the agent knows this is a non-destructive but non-read-only operation. The description adds useful behavioral notes (full-year coverage, month-by-month HTML loading, batch judging, and that no default observation city exists), but does not explain what happens if the optional observer is omitted despite that warning, nor the return artifact details.
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 compact, front-loaded sentences with no filler; the core deliverable (full-year facts + month-loaded HTML) leads. The workflow clause is slightly dense but earns its place by implying the batching model.
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 an 8-parameter, nested-object tool with no output schema and only 13% schema coverage, the description omits output shape, parameter behavior, and prerequisites for most inputs. It communicates the deliverable but leaves the agent under-equipped to call 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?
Schema description coverage is only 13% across 8 parameters with 4 enums and a nested observer/participants structure. The description only touches the observer concept via '没有默认观测城市' and says nothing about purpose, mountain, rollover, participants, qimen_method, or noble_profile, so it fails to compensate for the large schema gap.
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: generating a full Gregorian year (365/366 days) of electional-timing facts plus month-loaded HTML, with a clear 'full-year batch' scope. It partially distinguishes itself from siblings like preview/render_election_calendar by emphasizing year-wide coverage, but does not explicitly name why an agent would pick this over build_election_request.
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 clause '模型逐批判断，回填累积全年覆盖' implies a usage pattern (process in batches and back-fill cumulative coverage), and '没有默认观测城市' hints the observer must be supplied. However, there is no explicit when-to-use vs. the many sibling tools (preview_election_calendar, render_election_calendar, read_election_windows), leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.