Treza

Delete pipelines

delete_pipelines

Destructive

Delete pipelines from the account for good, up to 50 per call, in two steps. First call it with pipelineIds alone: nothing is deleted, and it returns willDelete (names, and which are published or on a schedule), cannotDelete with the reason (locked, or a run still in flight), notFound, and a confirmToken. Show the person what would go and wait for their yes; it cannot be undone. Then call again with the confirmToken and the willDelete ids (or fewer): only ids that preview showed are deleted, each checked again, and the token expires after 15 minutes. Use it when the person asks to delete or clean up pipelines, or when a create is refused at the 500-pipeline limit and they agree to clear space. Never pick pipelines to delete on your own: match them by name in list_pipelines and let the person choose. A deleted pipeline's schedule stops and its published API endpoint goes away; the images and videos its runs made stay in the library. Needs the pipelines:write scope.

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": {
      "pipelineIds": "<pipelineIds>"
    },
    "name": "delete_pipelines"
  }
}

Input Schema

Name	Required	Description	Default
`pipelineIds`	Yes	Pipeline ids from list_pipelines.
`confirmToken`	No	From the preview call, only after the person has said yes to its willDelete list. Omit to preview.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, but the description adds the entire behavioral contract: preview-then-confirm, nothing deleted on the first call, per-id re-checking on the second, a 15-minute token expiry, irreversibility, and the pipelines:write scope requirement. It also discloses side effects annotations cannot express: the schedule stops, the published API endpoint disappears, and run media stays in the library.

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 critical information (two-step flow, irreversibility) is front-loaded before the usage guidance and side effects. It is somewhat long and the first sentences are comma-heavy, but nearly every clause carries operational detail an agent needs; little could be cut without losing the safety contract.

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?

There is no output schema, and the description compensates by naming the preview return fields (willDelete with published/scheduled flags, cannotDelete with reasons, notFound, confirmToken). For a destructive two-phase tool with only two parameters, nothing an agent needs in order to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics the schema cannot: omitting confirmToken means preview, a second call may name the willDelete ids "or fewer," and only ids surfaced by the preview can actually be deleted. The 'from the preview call, only after the person has said yes' constraint is meaning, not restatement.

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 opens with a specific verb and resource ("Delete pipelines from the account for good") and immediately bounds it ("up to 50 per call, in two steps"). It is unmistakably distinct from create_pipeline, list_pipelines, and cancel_run.

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 gives explicit when-to-use triggers (user asks to delete/clean up, or a create is refused at the 500-pipeline limit) and an explicit anti-pattern ("Never pick pipelines to delete on your own") with the alternative workflow: match by name in list_pipelines and let the person choose.

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

All Treza tools Inspect

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.