Capable

Update pipeline

update_pipeline

DestructiveIdempotent

Update a pipeline by pipeline_key (or pipeline_id; id wins if both are given) — rename it (label), re-point it (applies_to), replace its stages (including each stage's ENTRY requirements — the field keys a deal must have filled to move into it), or set which opportunity types default to it (default_for_types). Existing stage keys stay stable; a stage that still has open deals can't be removed (reassign those deals first). Omit BOTH pipeline_key and pipeline_id to reshape the WORKSPACE DEFAULT pipeline — only stages apply there (the default has no label, applies_to, or type mapping). An unknown key/id returns the known pipelines instead of an error. Admin-only. Returns the updated pipeline.

When to use: When an admin wants to rename a pipeline, change its stages or what each stage requires on entry, re-point it, or set which deal types default onto it — or reshape the workspace default pipeline's stages (omit the pipeline key to target the default).

Example: Don't let a deal reach Proposal until Metrics and an economic buyer are filled in.

Input Schema

TableJSON Schema

Name	Required	Description
`label`	No	Rename the pipeline.
`stages`	No	Replace the stage list ([{key,label,role,is_closed?,is_won?,requires?,requires_mode?}], role one of unqualified/qualifying/active/commit/won/lost). Keep existing stage keys stable; a stage that still has open deals can't be removed. REPLACE-ALL: a stage you send without `requires` loses any requirements it had, so echo them back when you only mean to reorder or rename.
`applies_to`	No	The object key this pipeline runs on (e.g. opportunity). Named pipelines only.
`pipeline_id`	No	The pipeline to edit by id (uuid). Prefer pipeline_key; id wins if both are given.
`pipeline_key`	No	The named pipeline to edit, by its stable key (from describe_schema's pipelines section). Omit BOTH pipeline_key and pipeline_id to edit the workspace default pipeline (only `stages` applies there).
`default_for_types`	No	The opportunity `type` VALUE KEYS this pipeline is the default for — new deals of a mapped type start on it. A type maps to only one pipeline. Pass [] to clear the mapping. Named pipelines only; registry data, not fixed type names.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`pipeline`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: stage keys stay stable, a stage with open deals can't be removed, unknown key/id returns known pipelines instead of erroring, admin-only authorization, and REPLACE-ALL stage semantics that silently drop requirements. The annotations only flag destructive/idempotent; the description explains the actual mutation hazards.

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?

Dense but front-loaded, with the primary action, the default-pipeline special case, and the failure mode ordered sensibly. The trailing 'Example' sentence about a deal reaching Proposal is illustrative rather than operational and is the only slightly loose element.

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 destructive, multi-field mutation tool it covers target selection, replace-all semantics, guardrails on stage removal, and the default-pipeline edge case, and it notes the return value. With an output schema present, nothing an agent needs to invoke it 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 coverage is 100%, so the schema already documents all six parameters in depth, including the id-wins precedence and requires/requires_mode interplay. The description largely restates this (e.g. 'id wins if both are given'), adding little parameter meaning the schema doesn't already carry, so the baseline 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 (Update) and resource (pipeline), then enumerates exactly what can change (rename, re-point, replace stages, set default types) and the special workspace-default case. An agent can distinguish this from define_pipeline or archive_pipeline 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?

Has an explicit 'When to use' block listing the concrete admin scenarios and the omit-the-key trick for the default pipeline. It does not, however, name sibling alternatives (define_pipeline, archive_pipeline) or state when NOT to use it, so it falls short of a 5.

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

All Capable 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.

Resources

Need Help?