Skip to main content
Glama
Sign In
Plori

Plori

Official
by plori-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Cancel run

cancel_run
Destructive

Request cancellation of a run that has not ended by run_id; it returns cancelling and later cancelled, while finished runs are refused.

Instructions

Request cancellation of a run that has not ended. Returns status "cancelling" at once; the run then ends with status "cancelled", which get_run_result reports. A run that has already ended is refused with 409 run already finished.

Input Schema

NameRequiredDescriptionDefault
run_idYesThe run to cancel.
agent_idNoThe agent that runs the run (agent_id in the run result). Give this or workspace_id.
workspace_idNoThe Workspace the run belongs to. Give this or agent_id; with both, agent_id is used.

Output Schema

NameRequiredDescriptionDefault
runIdYesThe run whose cancellation was requested.
statusYesCancellation request status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.17.1
    • changedInput schema / properties / agent_id / description
      Previous value: -"The agent's UUID."New value: +"The agent that runs the run (agent_id in the run result). Give this or workspace_id."
    • changedInput schema / properties / run_id / description
      Previous value: -"The run id returned by invoke_agent."New value: +"The run to cancel."
    • addedInput schema / properties / workspace_id
      Added value: +{
+  "description": "The Workspace the run belongs to. Give this or agent_id; with both, agent_id is used.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "agent_id",
-  "run_id"
-]New value: +[
+  "run_id"
+]
  2. Changed1 schema field changedv0.16.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "runId": {
+      "description": "The run whose cancellation was requested.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Cancellation request status.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "runId",
+    "status"
+  ],
+  "type": "object"
+}
  3. Addedv0.9.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the two-phase async lifecycle (immediate 'cancelling', eventual 'cancelled' reported by get_run_result) and the exact failure mode (409 run already finished). This is exactly the state-transition and error context an agent needs before issuing a destructive, non-idempotent call, and it is consistent with destructiveHint=true / idempotentHint=false.

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?

Three short sentences, front-loaded with the action and its precondition, then the async result and the error case. No filler or repetition of the schema.

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?

With an output schema present, the description need not spell out return values, yet it usefully explains the status timeline and the 409 refusal. Nothing material for correct invocation, including parameter precedence, is left unaddressed across description plus schema.

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 coverage is 100% and each parameter carries a description, including the agent_id/workspace_id precedence rule, so the schema does the heavy lifting. The description adds only the 'not ended' constraint on run_id and no format or boundary detail beyond the schema.

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?

States a specific verb (cancel) and resource (run) with the qualifying condition 'that has not ended'. It also names get_run_result as the observer of the eventual terminal status, so an agent can place it relative to siblings without opening any schema.

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

Usage Guidelines4/5

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

Gives a clear precondition (run has not ended) and a when-not case (an already-ended run is refused with 409). It routes the agent to get_run_result for the outcome but never states alternatives for stopping other entities (e.g. stop_workspace_task_group), so it stops short of explicit when-to-use-vs-what guidance.

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

Deploy Server

Other Tools