Skip to main content
Glama

Update pipeline

update_pipeline

Save a new revision of a pipeline (the entry pipeline, or one a delegate hands requests to) and activate it (unless activate is false). Blocks run in order and the first to decide wins: outcome blocks decide every request that reaches them, webhook blocks ask a service of yours (and a kind this deployment adds may ask a model), branch blocks run their own blocks only for requests their condition matches (so "if this, then that" is a branch holding an outcome block), and delegate blocks hand matching requests to another pipeline by key; a request that enters a branch or a delegated pipeline is decided inside it or goes to a human, and nothing after the block runs for it. A request no block decides falls through to human review, so end with an outcome block whose outcome is approve when the rest should be automatic. Every escalation path a block or the default names, and every pipeline a delegate names, must exist; activation additionally requires each to be active and refuses a delegation cycle. Call read_reference (pipeline_blocks) first.

Input Schema

NameRequiredDescriptionDefault
nameNoA new display name for the pipeline. Omit to keep the current one.
blocksYesThe complete ordered block list for the new revision (it replaces the current blocks, so include the ones to keep). Each block: id (key-shaped, unique across the whole pipeline including blocks inside branches), name, type (outcome | branch | delegate | webhook, or a kind this deployment adds; see read_reference), enabled: true, timeout (for example 50ms), max_attempts (1 for outcome, branch and delegate), and config for its type; a branch holds its own ordered blocks in config.blocks, a delegate names the pipeline it hands matching requests to in config.pipeline_key. See read_reference topic pipeline_blocks. An empty list sends every request to human review.
activateNoActivate the new revision right away so new requests use it. Defaults to true. False saves a draft revision you can activate later with activate_pipeline_revision.
pipeline_keyYesThe pipeline to replace ('entry' for the entry pipeline).
default_ask_agent_ownerNoSend those requests to the person who owns the agent instance that made them instead, with default_escalation_path, if set, as the fallback for requests from agents without an owner (service agents); without it they go to any authorized reviewer.
default_escalation_pathNoEscalation path key that takes human exits which name no path of their own, and requests the pipeline hands to a person by running out of blocks. Omit to inherit the defaults of the pipelines that delegate into this one, or, for the entry pipeline, to leave them to any authorized reviewer.

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?

Discloses rich behavior beyond the annotations: blocks run in order, first-to-decide wins, branch/delegate requests are decided inside, undecided requests fall through to human review, referenced escalation paths and pipelines must exist, activation requires them to be active, and delegation cycles are refused. Nothing contradicts the non-destructive annotation.

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

Conciseness3/5

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

The main action is front-loaded, but the description then contains a long, run-on explanation of block types that overlaps with what read_reference and the blocks schema already cover. Much of it is useful context, but it is not tightly structured or economical.

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 complex, six-parameter mutation with no output schema, the description covers activation semantics, escalation defaults, validation constraints, and block behavior thoroughly. It could say more about the returned value or failure modes, but the schema coverage is high and the core operational picture is complete.

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 explains every parameter, including the detailed blocks structure and activate/default_escalation_path behavior. The description adds block-semantics context but little parameter-specific detail beyond what the schema provides, 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 ('Save a new revision') and resource ('a pipeline'), and scopes it to either the entry pipeline or a delegate target. An agent can tell this is an update/save operation rather than a create or read operation without opening the 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 clear operational guidance: call read_reference (pipeline_blocks) first, and use activate_pipeline_revision to activate a saved draft later. It does not explicitly distinguish itself from create_pipeline, but its context is otherwise well framed.

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.