Skip to main content
Glama
This connector has been deprecated

This is a duplicate of the actual entry deprecating this in favor of the original.

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

TableJSON 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.3/5.0
Behavior5/5

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

Annotations only say this is a non-read-only, non-destructive, non-idempotent write. The description adds substantial behavior beyond that: activation preconditions (every named path/pipeline must exist and be active, delegation cycles refused), fall-through-to-human-review semantics, that an empty block list sends everything to human review, and that the block list wholly replaces the current one. That is exactly the extra context the annotations cannot carry.

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 purpose is front-loaded in the first sentence, but the remainder is a single dense run-on paragraph that repeats block structure already covered by the schema. Much of it earns its place for a complex tool, yet it is longer than necessary and would benefit from separators given the schema and read_reference already carry detail.

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 complex revision-based mutation with no output schema, the description covers prerequisites, activation failure conditions, default-escalation inheritance, and the human-review fallback, and it routes the agent to read_reference for block specifics. Nothing an agent needs to call this correctly 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%, so the schema already documents all six parameters in detail, and the description largely restates block/config/activate/name semantics that the schema also provides. It contributes marginal added meaning (block ordering and decision semantics), so the baseline 3 is appropriate rather than higher.

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 first sentence names a specific verb+resource ('Save a new revision of a pipeline ... and activate it'), including the revision-based mutation model and the activate toggle. This cleanly separates it from create_pipeline (new pipeline) and activate_pipeline_revision (activate an existing draft), which it also cites by name.

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 operating context and a required prerequisite ('Call read_reference (pipeline_blocks) first'), plus a when-not path via activate=false pointing to activate_pipeline_revision. It does not explicitly contrast against create_pipeline or preview_pipeline, so it stops short of full alternative routing.

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