Capable

Define pipeline

define_pipeline

Create an additional pipeline (a named stage sequence) for opportunities or a custom object. Omit stages to seed from the workspace default pipeline, or pass stages as [{key, label, role, is_closed?, is_won?, requires?, requires_mode?}] (role one of unqualified/qualifying/active/commit/won/lost; requires lists the field keys a deal must have filled to enter the stage). default_for_types names the opportunity type keys this pipeline is the default for, so new deals of a mapped type start on it (a type maps to one pipeline). Returns the created pipeline.

When to use: When a motion needs its own stage sequence — e.g. an investor raise separate from the customer pipeline. Optionally set which deal types default onto it.

Example: Create an investor pipeline: Intro, Pitch, Diligence, Committed, Invested.

Input Schema

Name	Required	Description
`label`	Yes	Display name. Its slug (lowercase, underscores) becomes the stable pipeline_key, which must be unique in the workspace.
`stages`	No	Ordered stages [{key,label,role,is_closed?,is_won?,requires?,requires_mode?}], role unqualified/qualifying/active/commit/won/lost; omit or [] copies the default pipeline's stages.
`applies_to`	No	The object key this pipeline runs on (e.g. opportunity). Defaults to opportunity when omitted.
`default_for_types`	No	Opportunity `type` value keys this pipeline is the default for: new deals of a mapped type start on it. A type maps to one pipeline (a double claim is rejected; an unknown key is rejected with the known keys). Registry value keys, not fixed type names.

Output Schema

Name	Required	Description	Default
`pipeline`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
Changed4 schema fields changedOct 19, 2026
- removedOutput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
- removedOutput schema / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / pipeline / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / pipeline / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```

Changed4 schema fields changedOct 19, 2026

changedInput schema / properties / default_for_types / description

Previous value: -"The workspace's opportunity `type` VALUE KEYS this pipeline is the default for. New deals of a mapped type start on this pipeline. A type can map to only one pipeline (a double-claim is rejected); an unknown type key is rejected with the known keys. Registry data — not fixed type names."New value: +"Opportunity `type` value keys this pipeline is the default for: new deals of a mapped type start on it. A type maps to one pipeline (a double claim is rejected; an unknown key is rejected with the known keys). Registry value keys, not fixed type names."

changedInput schema / properties / stages / items / properties / requires / description

Previous value: -"Stage gate: the field keys a deal must have FILLED to ENTER this stage. Two namespaces — a plain field key on the object (amount_cents, close_date, a custom field key) and the active qualification framework's keys as \"qualification.<key>\" (describe_schema lists both). At most 10. Omit or pass [] for no gate — that is every workspace by default. A key the workspace can no longer fill is skipped rather than trapping the deal, and a backward move out of a gated stage is never blocked."New value: +"Stage gate: field keys a deal must have filled to ENTER this stage. Two namespaces — a plain field key on the object (amount_cents, close_date, a custom key) or a framework key as \"qualification.<key>\" (describe_schema lists both); at most 10. Omit or [] for no gate (every workspace's default). A key the workspace can no longer fill is skipped rather than trapping the deal, and a backward move is never blocked."

changedInput schema / properties / stages / items / properties / requires_mode / description

Previous value: -"How hard the gate is. \"require\" (the default) refuses the move until the fields are filled; \"warn\" lets it through and reports what is still empty. Only meaningful alongside requires."New value: +"How hard the gate is: \"require\" (default) refuses the move until the fields are filled; \"warn\" lets it through and reports what is empty. Only meaningful alongside requires."

changedInput schema / properties / stages / items / properties / role / description

Previous value: -"The stage's semantic role — unqualified, qualifying, active, commit, won or lost — which drives lens membership and the open-pipeline boundary; labels are free, roles are not. Omit to let the registry infer it from position and the closed/won flags."New value: +"Semantic role — unqualified, qualifying, active, commit, won or lost — which drives lens membership and the open-pipeline boundary (labels are free, roles are not). Omit to infer it from position and the closed/won flags."

First observedOct 6, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only establish the safety profile (writable, non-destructive, non-idempotent, closed-world). The description goes further: omitted stages seed from the workspace default, a type maps to exactly one pipeline, double claims and unknown type keys are rejected, and the call returns the created pipeline. It does not mention the uniqueness requirement being an error at runtime beyond the label's slug note, but the creation-side behavior is well disclosed.

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?

Front-loads the operation, then seeding behavior, then a labeled "When to use" and "Example" section. Slightly over-long because the inline stage object shape duplicates the schema's own description, which is redundant rather than harmful.

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?

An output schema exists, so the single "Returns the created pipeline" line suffices. For a 4-parameter create tool with rich annotations and a full schema, the definition covers purpose, seeding fallback, validation, and type mapping — only authentication/preconditions and alternative routing are absent.

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 label, stages, applies_to and default_for_types in depth. The description largely restates what the schema says (stage shape, role enum, requires gate, type-to-pipeline mapping), adding little syntax or semantics the agent could not read in the schema. 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 and resource ("Create an additional pipeline") plus its scope (opportunities or a custom object), and the word "additional" plus "extra" cleanly separates it from update_pipeline/archive_pipeline in the sibling list. An agent can identify the 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?

An explicit "When to use" section names the trigger condition — a motion that needs its own stage sequence, with an investor-raise-vs-customer-pipeline example. It does not name the adjacent alternatives (update_pipeline, archive_pipeline) or state when NOT to create a new pipeline, so the routing guidance is clear but not exclusionary.

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?