Generates a 3–5 step siege plan (position, breach walls, finish, capture) when a city is viable to attack, and explains missing conditions if the assault would fail.
攻城计划:3-5 步战术模板(站位→削墙→收尾→占领)。仅当战前评估为 可打/需准备时给计划;不推荐/会全灭时会拒绝并说明先补什么条件。
| Name | Required | Description | Default |
|---|---|---|---|
| city_x | Yes | ||
| city_y | Yes | ||
| wall_hp | No | ||
| wall_max_hp | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true is consistent with a pure advisory/planning tool, and the description adds real behavior beyond that: the output shape (3-5 steps), the refusal branch, and the fact that a refusal still returns actionable advice on what conditions to fix first. It does not state what happens if the required wall data is absent, which keeps it from a 5.
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 tightly packed sentences with no filler; the capability and the phase list come first, then the gating and refusal logic. Sizing is well matched to a low-complexity advisory tool.
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?
Since an output schema exists, the return payload needn't be spelled out, and the description covers purpose, gating, and refusal behavior adequately. The gap is parameter context: for a four-parameter tool with 0% schema coverage, an agent gets no guidance on what wall_hp/wall_max_hp mean or how -1 is interpreted.
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 the description carries the full burden for all four parameters, and it says nothing about any of them. In particular, the sentinel default of -1 for wall_hp/wall_max_hp (presumably 'unknown, fetch it yourself') is never explained, and nothing indicates whether the coordinates must be an already-scouted city.
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 output (a 3-5 step siege tactical template with an explicit phase breakdown: positioning → wall breaking → finishing → capture), so the agent knows exactly what it gets back. It does not explicitly name assess_attack as the prerequisite tool, but the mention of '战前评估' (pre-battle assessment) makes the relationship inferable.
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 clearly sets both the positive and negative gating conditions: produce a plan only when the assessment is 'attackable/needs preparation', and refuse with remediation advice when the odds are bad or a wipe is certain. What's missing is a pointer to which sibling tool performs that assessment, so the agent must infer the call ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.