Does 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.

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered by structured data. The description adds that computation is driven strictly by request-supplied coordinates with no default city, which tells the agent omission of location will not silently succeed with a fallback. It says nothing about precision, ephemeris source, or performance.

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?

A single tightly written sentence with the core action front-loaded and the scope caveat attached. Nothing is redundant, though it is terse enough that the omitted details (units, return shape) feel like truncation rather than deliberate brevity.

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?

With no output schema and no description of the returned values (azimuth/altitude units, horizon-state vocabulary), the agent cannot predict the response shape. Annotations cover the safety profile and the input constraint is stated, but for a coordinate-driven astronomy computation with an underspecified nested observer object, more behavioral detail would be warranted.

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 33%: only 'datetime' is documented, while the nested observer fields (latitude, longitude, label, elevation_m) and input_timezone carry no descriptions. The description partly compensates by stating coordinates must be provided per request (no default city), but it never clarifies label/elevation_m meaning or timezone handling, leaving most parameters unexplained in both places.

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 names a specific verb/resource: computing real Big Dipper geometric azimuth/altitude and horizon status. It also states a scope constraint ('per-request lat/long, no default city') that distinguishes it from chart tools like get_qimen_chart that likely accept defaults. It never names a sibling explicitly, so differentiation is by domain inference rather than direct routing.

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 when-to-use/when-not guidance and no alternative tool is named. The phrase '没有默认城市' hints that coordinates must always be supplied, but that is a constraint on inputs, not guidance about which tool to pick for a given task.

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

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

Annotations already declare this a non-destructive, closed-world read. The description adds one genuinely useful behavioral fact: it returns evidence and candidates only, never scores, which sets expectations for how to consume the output. It stops there, saying nothing about cost, size, or determinism of the fused result.

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?

It is a single dense sentence with no padding, and the most useful fact (evidence/candidates but no scores) is placed last rather than front-loaded. The list of fused techniques dominates the sentence, which buries the output contract.

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 9-parameter tool with nested observer and participants objects, four enums, no output schema, and very low schema coverage, the description is far too thin. It does not explain how inputs like mountain, rollover, or per-participant branches shape the divination result, leaving the agent unable to reason about the tool's output.

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 22% across 9 parameters, so the description carries most of the burden, yet it never names or explains any parameter such as mountain, rollover, participants, noble_profile, or observer. The only enum that is documented (qimen_method) is explained in the schema, not here.

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 names the specific techniques it fuses (六壬完整式盘, 奇门, 贵人方, 斗柄, 可选七星, 本命), so the resource is identifiable, but it reads as a component checklist rather than a statement of what the tool delivers. It never distinguishes itself from the sibling get_qimen_chart or get_beidou_sky, which overlap heavily with two of the listed components.

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 when-to-use guidance, no prerequisites, and no named alternative. A reader cannot tell from the description when this combined tool should be preferred over the single-technique siblings get_qimen_chart or get_beidou_sky.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that it does not automatically judge auspiciousness and that output includes warnings/alternative formations, which is useful context for a divination chart with no output schema. It still does not describe return format or timezone behavior in depth.

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?

Single front-loaded sentence with no filler, ordered as purpose → contents → caveat. Every clause carries information.

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 read-only chart tool with no output schema, the description should explain return contents and key parameter choices. It lists output components but omits the return format and leaves rollover/timezone meaning to the schema, which only supplies defaults. Adequate but incomplete.

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 already documents datetime and qimen_method (50% coverage). The description repeats '拆补/置闰' but adds no syntax or behavior beyond the schema. It is silent on rollover and input_timezone, leaving two parameters undocumented, so it does not compensate for the coverage 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?

Description names the exact resource (奇门时家转盘) and two method variants (拆补/置闰), and lists the produced components (星门神、天地干、主式和另说格局与警示). It distinguishes itself from siblings like get_beidou_sky or read_election_windows by domain, though it does not explicitly name an alternative.

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?

No when-to-use, no when-not-to-use, no alternatives, and no prerequisites are provided. The only guidance is the caveat that it does not automatically judge auspiciousness, which is a behavioral note rather than usage routing. An agent must infer from the tool name that this is the Qimen chart provider.

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

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

Beyond the annotations, it discloses that this is a local HTTP preview, that only the calendar and its supporting data scripts are exposed, and that the address can be retrieved again after restart while files remain offline-openable. This adds meaningful operational and security context, though lifecycle details such as stopping the server are absent.

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?

The description is compact and front-loads the main action. Both sentences add useful information, though the phrasing is dense.

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 that starts/restores a server, the description covers persistence and exposure scope but does not explain what the call returns, such as the preview URL, nor how to stop or manage the preview. With no output schema, these gaps matter.

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?

The single required parameter artifact_id has 0% schema description coverage, and the description does not explain its format, source, or how it identifies the calendar. The phrase '该日历' only weakly implies the parameter's role.

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 uses a specific verb-resource pair: restore a local HTTP preview of a generated calendar. It also states the exposure scope, but does not explicitly distinguish this tool from the sibling render_election_calendar.

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?

It implies use after a calendar has already been generated and for re-obtaining the address after an MCP restart. It gives no explicit when-not conditions or alternative routing relative to render_election_calendar.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral value by stating that each returned window bundles chart, direction candidates, and judgment rules, but it omits pagination behavior (that only up to 14 windows come back at a time) and any cost or size characteristics.

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?

A single compact sentence that front-loads the verb and resource and appends the payload contents. Nothing is wasted, though the description is short enough that its omitted pagination detail is a sizing trade-off rather than pure conciseness.

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?

With no output schema and 0% parameter coverage, the description must carry the load, yet it omits pagination semantics, the 14-item cap, and what artifact_id refers to. Given the sibling set of build/render/preview calendar tools, an agent lacks the detail needed to invoke this 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 0%, so all three parameters (artifact_id, limit, offset) are undocumented in both schema and description. The description never explains that artifact_id selects the generated material or that limit is capped at 14 and offset drives paging, leaving the agent to infer parameter meaning entirely.

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 pairs a concrete verb ('读取' / read) with a specific resource ('小批次窗口' / small-batch windows) and then enumerates what each window contains: complete chart, direction candidates, and judgment rules. That content list goes beyond the name and helps an agent recognize the payload, though it never distinguishes this tool from the render/preview calendar siblings.

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?

'已生成材料中的' (within already-generated materials) implicitly tells the agent this only reads from an artifact that must already exist, which lightly contrasts with the build_* siblings. However, it gives no explicit when-to-use, no exclusions, and no routing versus render_election_calendar or preview_election_calendar.

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

Does 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.