Claude Code MCP Server

Cancel a create job or local run

claude_cancel_session

DestructiveIdempotent

Stop a running cloud-session creation or local job by ID, session ID, or URL, terminating its processes and reporting whether it stopped. Already-created cloud sessions keep running.

Instructions

Stop a claude_create_cloud_session job or claude_run_local job that is still running: every process it started on this machine (git, the pty helper, claude --cloud or claude -p) gets SIGTERM, then SIGKILL 5 s later. Pass the job_id, or for a create job the session id or URL it already printed. Waits up to about 6 s for the processes to exit and reports stopped. This does not stop a cloud session: one the CLI already created keeps running at its session_url. A job that already finished is left as it is (cancelled false), and one that failed returns its error.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session": "<session>"
    },
    "name": "claude_cancel_session"
  }
}

Input Schema

Name	Required	Description	Default
`session`	Yes	Job to stop: a job id (job_...) from claude_create_cloud_session or claude_run_local, or the session id (session_... / cse_...) or https://claude.ai/code/... URL an unfinished create job printed.

Output Schema

Name	Required	Description
`job`	Yes	The create job after this call, or null for a local run.
`stopped`	Yes	True when every process the job started has exited.
`cancelled`	Yes	True when this call cancelled the job. False when it had already finished or been cancelled.
`local_job`	Yes	The claude_run_local job after this call, or null for a create job.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.3Nov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: SIGTERM followed by SIGKILL after 5 s, a ~6 s wait for exit, a reported `stopped` status, `cancelled` false for already-finished jobs, and error passthrough for failed jobs. These are exactly the consequences an agent needs before invoking a destructiveHint=true tool, and nothing here conflicts with the annotations.

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

Conciseness4/5

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

Front-loaded with the core action and escalation behavior, then the argument forms, then the exclusions — a logical order with no filler. It is slightly dense in the parenthetical process enumeration, but every clause carries operational meaning.

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?

For a single-parameter destructive tool with full annotations and an output schema, this covers the signal escalation, timeout, status values, and the critical caveat that an already-created cloud session survives. Nothing an agent needs to invoke it safely 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% and the schema's own description already spells out the job_/session_/cse_/URL forms and the regex enforces them. The description largely restates that same mapping ("Pass the job_id, or for a create job the session id or URL it already printed") without adding format or edge-case detail the schema lacks, so this sits at the baseline.

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 ("Stop") and names the exact resources it acts on ("claude_create_cloud_session job or claude_run_local job that is still running"), and immediately clarifies the scope boundary versus cloud sessions. The agent can distinguish it from claude_create_cloud_session and claude_run_local 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 Guidelines5/5

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

Gives explicit when-to-use (a job still running), when-not (a job that already finished is left as is; this does not stop a cloud session already created), and tells the caller what identifier forms are acceptable. The only minor gap is that it doesn't point to a sibling that *would* stop a remote session, but the exclusion itself is stated unambiguously.

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

Deploy Server