finalize_plan
Consolidates an idea, design details, and decisions into a high-level plan for human review and sign-off.
Instructions
汇总成一份高层计划,供人审阅和拍板。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | ||
| design | No | ||
| decisions | No |
Consolidates an idea, design details, and decisions into a high-level plan for human review and sign-off.
汇总成一份高层计划,供人审阅和拍板。
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | ||
| design | No | ||
| decisions | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and no output schema are provided, so the description carries the full behavioral burden, yet it only says a plan is produced. It never states whether this is a write/side-effecting operation, whether it persists or overwrites a plan, what happens to the design and decisions inputs, or what the caller receives back.
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 short sentence that is front-loaded on the outcome and free of filler. Its brevity is efficient, though it shades into under-specification given the undocumented parameters.
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 three-parameter tool with no annotations, no output schema, and no sibling differentiation, one sentence about producing a plan is not enough. An agent cannot determine required inputs, side effects, or when this tool supersedes the other design/analysis siblings.
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% for three parameters (idea, design, decisions), and the description mentions none of them. The only hint is that inputs are '汇总' (aggregated) into the plan, which does not clarify the role, format, or required/optional distinction of design and decisions. With three undocumented parameters, the description fails to 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?
The description names a concrete action and artifact ('汇总成一份高层计划') plus its audience ('供人审阅和拍板'), so an agent can tell it produces a consolidated plan rather than raw analysis. However, it says nothing to distinguish it from design-oriented siblings such as analyze_upper_design or create_harness_workflow, so it lands at 'clear but undifferentiated'.
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?
'供人审阅和拍板' implies this is a terminal step used when a human must review and approve, which gives weak, inferred guidance about when to call it. There is no explicit when-not clause and no alternative tool is named, so the routing decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.