Request cancellation of a pipeline run by saving a cooperative flag; double cancellation is idempotent. Raw data remains intact—confirm actual stop with pipeline_status.
取消要求を保存する。二重取消は冪等。
rawデータを削除しない。 ここで保存するのは協調的な取消フラグだけで、
上流Consoleの停止は監視経路が、下流の停止はstage境界が行う。受理
（このツール呼び出しが成功したこと）と、実際にworkerが停止を確認した
こと（cancelled への確定）は別状態——確定は pipeline_status で確認する。
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline_path | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only cover general safety hints, while the description adds substantive behavior: raw data is not deleted, only a cooperative cancel flag is stored, upstream Console stopping is handled by the monitoring path, downstream stopping is handled at stage boundaries, and acceptance of the request is explicitly separate from actual worker shutdown. This goes well beyond what the annotations provide and gives an accurate model of this asynchronous, non-destructive mutation.
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 core action and idempotency are stated first, followed by the important non-destructive guarantee in bold, and then the async semantics. Each sentence earns its place, though the upstream/downstream split is slightly more detail than an agent strictly needs to invoke the 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?
For a mutation tool with no output schema, the description covers the semantics an agent needs: what happens, what does not happen, how idempotency works, and how to verify the final state via `pipeline_status`. Only the parameter format is missing.
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 schema has one parameter, `pipeline_path`, with 0% description coverage, so the description must provide that meaning. It does not mention the parameter at all: neither what a valid pipeline path looks like nor how to obtain one. The gap is real despite the small parameter count.
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 states a specific verb and resource: it saves a cancel request for a pipeline, and nothing else. It also clearly distinguishes this from the sibling `pipeline_status`, which is the tool that confirms cancellation, so an agent can tell the two apart without opening either schema.
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 description states when to use this tool (to request cancellation) and sends the agent to `pipeline_status` to confirm the request has actually taken effect. Idempotency is also stated explicitly. It never states when not to use this tool, for example when the pipeline is already complete or rejected, so the score is 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.