Skip to main content
Glama
Sign In

Ankra

by ai.ankra
OverviewDiscussionsAdmin

Cancel pipeline run

cancel_pipeline_run
Destructive

Cancel an Ankra Pipelines run that has not concluded. A started run that declares finally stages runs them before it concludes cancelled, so the answer can still be running; cancel again with force to stop those too. A run that already concluded is refused. Address the repository with exactly one of repository_id, application_id, or owner and repo. Needs pipelines.operate.

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": {
      "pipeline_run_id": "<pipeline_run_id>"
    },
    "name": "cancel_pipeline_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
repoNoRepository name, with owner.
forceNoAlso stop its finally stages and conclude it at once (default false).
ownerNoRepository owner (organisation or user), with repo, instead of repository_id.
providerNoNarrows owner and repo when the same repository is connected on two providers.
repository_idNoThe connected repository's id, from list_pipeline_repositories.
application_idNoAn application whose linked repository to address, instead of repository_id.
pipeline_run_idYesThe run to cancel (its UUID).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare destructive=true/idempotentHint=false, but the description goes well beyond them: it explains that finally stages run first so the returned answer may still be running, that concluded runs are refused, and that pipelines.operate permission is required. These are non-obvious behavioral traits an agent cannot infer from the schema or hints.

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?

The precondition and the permission requirement are front-loaded and every sentence carries information. The phrasing "so the answer can still be running" is slightly awkward and could be tightened, but there is no filler.

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 destructive mutation with no output schema, the description covers the state semantics, the refusal case, force escalation, addressing, and the required permission. What it leaves out is what the returned run object looks like and whether the caller should follow up with watch_pipeline_run, which would round it out.

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 documents all seven parameters, establishing a baseline of 3. The description does add the exactly-one-of repository addressing rule (repository_id vs application_id vs owner+repo) and the 'cancel again with force' usage pattern, which sits somewhere between the baseline and a 4 depending on how much weight is given to restating schema-level constraints that are implied but not enforced by the schema itself.

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 ("Cancel an Ankra Pipelines run") plus a precondition ("that has not concluded"), which cleanly separates it from rerun_pipeline_run, watch_pipeline_run, and the unrelated cancel_agent_run/cancel_data_run siblings.

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 clear when-to-use context: only for runs that haven't concluded, a refusal path for concluded runs, and the explicit escalation path of cancelling again with force to stop finally stages. It does not name the alternative tools (watch_pipeline_run, rerun_pipeline_run) an agent might pick instead, so it stops short of full routing guidance.

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

All Ankra toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources