Accumulates timing judgments, validates them against participants, observation points, and fact versions, then backfills a month-switchable HTML calendar with recommended directions for open segments.
合并本批与已保存判断，逐批累积；校验模型判断与全部参与者、观测点和事实版本一致后回填HTML；未指定用方的可用段必须附建议方位。
| Name | Required | Description | Default |
|---|---|---|---|
| review | Yes | ||
| artifact_id | Yes |
Changes observed during successful MCP inspections.
v0.3.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, openWorldHint=false, and destructiveHint=false, so the description adds substantial context above that bar: it discloses stateful accumulation (merging current batch with saved judgments batch-by-batch), a validation precondition against all participants/observation points/fact versions, and a constraint that unspecified-usage segments require a suggested direction. It stops short of saying what happens when validation fails.
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 semicolon-separated clauses are reasonably compact with no filler, but the structure is not front-loaded: the description opens with a merge/accumulation detail rather than stating what the tool produces, making it hard to scan.
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 an opaque nested-object parameter, zero schema coverage, and no output schema despite producing HTML, the description leaves essential gaps. It does not define artifact_id, the review payload shape, or the artifact returned, so an agent cannot reliably construct the 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?
Schema description coverage is 0% and the 'review' parameter is a bare nested object with no inner schema, so the description carries full burden. It alludes to 'this batch's judgments' and 'saved judgments' but never explains what artifact_id is or what fields review must contain.
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 conveys a process (merge batch judgments with saved ones, validate, write back HTML), which implies rendering the election calendar, but never states the purpose in a single clear verb+resource form. It also fails to differentiate from the sibling preview_election_calendar, leaving the render-vs-preview distinction to inference.
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?
There is no explicit when-to-use guidance, no mention of the preview_election_calendar alternative, and no stated prerequisites beyond an embedded validation condition. The agent must guess when to call this rather than preview_election_calendar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.