Skip to main content
Glama
wiroai

Wiro MCP Server

Official
by wiroai

Cancel an agent message

cancel_agent_message
DestructiveIdempotent

Stop a queued or running turn for Studio, the Workflow Agent, or a deployed agent and return its final status. Cancel work still in progress; usage up to cancellation remains billed.

Instructions

Stop a turn that Studio, the Workflow Agent or one of your deployed agents is still working on. Only queued or running turns can be cancelled; a finished turn is reported as it ended. The turn can still finish normally if it was already completing, so the final status is read back and returned. Usage up to the cancel stays billed. For Studio, model runs the turn already started keep running and cannot be stopped from here; list_studio_results shows them.

Input Schema

NameRequiredDescriptionDefault
agentYesWhich agent: "studio" (Wiro Studio, the media agent that runs models for you), "workflow-agent" (the Workflow Agent, which designs Wiro workflows) or the guid of one of your deployed agents (from list_my_agents).
sessionNoThe session the message was sent in. Required for Studio and the Workflow Agent unless it was "default".
message_idYesThe message id from send_agent_message.

Output Schema

NameRequiredDescriptionDefault
agentYes
notesYes
messageNo
sessionNo
agentKindYes
messageIdYes
finalStateNo
finalStatusNo
cancelAcceptedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.1

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses important behavioral nuances: cancellation may not prevent an already-completing turn from finishing, final status is read back, usage up to cancellation remains billed, and Studio model runs cannot be stopped here. These details materially help an agent use the tool correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and then adds only operationally relevant constraints. Every sentence carries useful information about limits, billing, or final-status behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the annotations and output schema, the description fills the remaining gaps an agent needs: cancellation eligibility, behavior for completing turns, billing implications, and the Studio model-run limitation. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains the agent, session, and message_id parameters in detail. The description reinforces the supported agent types but does not add syntax or format information beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: stop/cancel a turn that a named agent is still working on. It scopes the action to queued or running turns and clearly separates this from cancelling model runs already started by Studio.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when the tool applies (queued or running turns) and when it does not (finished turns are simply reported as they ended). It also names an alternative path for related Studio model runs, pointing to list_studio_results.

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