Skip to main content
Glama

remote_cancel

Idempotent

End the companion session to cancel an active operation. Returns outcome_unknown because effects already dispatched cannot be undone; the human must reconnect locally before more work. If the operation has already finished, returns its receipt without ending the session.

Input Schema

NameRequiredDescriptionDefault
connectionYesApproved connection ID from remote_connections. Use the original connection for an existing operation; refresh after reconnecting.
operationIdYesOperation UUID. Create a new UUID for new work; reuse the original UUID to poll, cancel, or recover a lost response without repeating effects.

Output Schema

NameRequiredDescriptionDefault
statusYesExecution state. completed means a native result exists, not that the native tool succeeded.
progressNo
operationIdYesOperation UUID. Create a new UUID for new work; reuse the original UUID to poll, cancel, or recover a lost response without repeating effects.
resultAvailableNoWhether the completed native result remains available through remote_status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=false, idempotent=true) by disclosing non-obvious traits: the outcome_unknown result when effects are already dispatched, the fact that those effects are irreversible, the requirement that the human reconnect locally before further work, and the no-op end condition when the operation already finished. None of this is derivable from the structured fields.

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 tight sentences with zero filler: the action leads, followed by the outcome caveat and then the finished-operation branch. Information is front-loaded and nothing is repeated.

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

Completeness4/5

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

For a mutation tool with annotations and an output schema present, the description covers the critical semantics: irreversibility, the unknown-outcome case, the reconnection prerequisite, and the already-finished shortcut. The only omission is routing guidance relative to the sibling status tool, which keeps it short of a 5.

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 both parameters already carry detailed guidance in the schema (connection reuse/refresh, operationId creation vs reuse). The description adds no parameter-level meaning of its own, so the baseline of 3 applies.

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 and resource combination ('End the companion session to cancel an active operation') that no sibling tool covers, distinguishing it cleanly from get_profile, remote_connections, and remote_status. An agent can tell immediately this is the termination/cancel path.

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

Usage Guidelines3/5

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

Usage context is implied ('cancel an active operation') but there is no explicit when-to-use vs when-not guidance, and no pointer to remote_status for polling or checking an operation before cancelling. The finished-operation case is described as behavior rather than as a selection rule, so guidance remains inferential.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources