Applies one pending ipTIME router change plan using its plan ID, with no confirmation token or repeated plan ID needed.
Apply exactly one pending plan. No confirmation token or repeated plan id is required.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes |
Changes observed during successful MCP inspections.
v0.2.2Input schema / properties / confirmationRemoved value: -{
- "minLength": 1,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "plan_id",
- "confirmation"
-]New value: +[
+ "plan_id"
+]v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds real value by clarifying that no confirmation token or repeated plan id is needed, but it omits what the destructive apply actually changes and whether a partially applied state is possible.
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 tight sentences, front-loaded with the action and followed by the one non-obvious constraint. Nothing wasted.
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 destructive, non-idempotent mutation with no output schema, the description covers the confirmation-token surprise but not failure modes (stale/unknown plan), post-apply state, or where to check results. Annotations carry the safety burden, leaving this only minimally adequate.
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 coverage is 0% and the single parameter is only referenced obliquely ('exactly one pending plan', 'no repeated plan id is required'). It does not state that plan_id must identify a currently pending plan or that it is a UUID, so it only partially compensates for the undocumented schema.
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+resource ('apply exactly one pending plan') and adds a scope quantifier ('exactly one') that separates it from planning tools like iptime_plan_change. It does not explicitly name a sibling to contrast with, but the verb itself distinguishes apply from plan/cancel/list.
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?
'Pending plan' implies this follows a planning step, and the note about no confirmation token gives a usage hint. However, it never states when to use this versus iptime_plan_change or iptime_cancel_change, nor any prerequisites such as the plan still being valid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.