Skip to main content
Glama

Pipeline summary

get_pipeline_summary
Read-only

Aggregate roll-up of the workspace's opportunities and revenue. Returns: opportunities broken down by type AND stage; the open pipeline segmented by lens (pipeline_by_lens), where lens membership is derived from each stage's role, not its label; each stage with its role (unqualified | qualifying | active | commit | won | lost) plus sales_boundary_stage (the first 'active'-role stage — the open-pipeline boundary); a revenue roll-up (total ARR, customer count, at-risk count); renewals due in the next 90 days (count + ARR at risk computed over EVERY renewal due, plus a list of up to 500 with coverage {status complete|truncated, returned, total} and truncated saying whether the list is a sample); and accounts in the explicit at-risk lifecycle stage. Optionally scope to ONE pipeline with pipeline_key (or pipeline_id): this filters ONLY the opportunity breakdowns (stages, pipeline_by_lens, pipeline_by_type_and_stage) to that pipeline — omit both for the workspace default pipeline + unassigned deals. The revenue roll-up, renewals, and at-risk accounts are always workspace-wide regardless of the pipeline filter. The additive forecast block carries per-person rows and the reporting-tree rollup, separate currencies, targets, human calls, and the exact deal ids behind every cell. Nothing predicts.

When to use: The Revenue sales pipeline — forecast, stage mix, renewals, ARR. It assumes a revenue pipeline, so it's only for workspaces that run a sales motion with real opportunities. Don't reach for it to answer a vague 'show me my data', and never before a workspace has chosen its motion — it has nothing to show then. Pass pipeline_key to scope the stage/type breakdowns to one named pipeline (revenue, renewals, and at-risk stay workspace-wide). The renewals-due count and ARR at risk cover every renewal; the list itself is capped at 500 and says so in its coverage.

Example: Give me a pipeline summary.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pipeline_idNoScope the opportunity breakdowns to this pipeline by id (uuid). Prefer pipeline_key.
pipeline_keyNoScope the opportunity breakdowns to this pipeline by its stable KEY (see the `pipelines` section / describe_schema). Omit both for the default pipeline + unassigned deals (today's behavior). pipeline_id wins if both are given.
forecast_periodNoCalendar forecast period in the workspace timezone; defaults to quarter.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
emptyNo
stagesNo
revenueNo
forecastNo
frameworkNo
pipeline_by_lensNo
total_opportunitiesNo
sales_boundary_stageNo
renewals_due_next_90_daysNo
pipeline_by_type_and_stageNo

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?

Annotations already establish read-only/safe/idempotent=false, and the description goes well beyond them: it defines lens membership as derived from stage role not label, defines sales_boundary_stage, states that pipeline filtering touches only the opportunity breakdowns while revenue/renewals/at-risk stay workspace-wide, and discloses the 500-item renewal cap with coverage{complete|truncated} and truncation semantics. It even pre-empts a misuse ('Nothing predicts').

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?

It is front-loaded with the return contents, which is good, but it is an unusually long, densely packed block that repeats the pipeline-filter scoping rule twice (main body and 'When to use'). The example 'Give me a pipeline summary.' adds no information. Functional but noticeably padded.

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 zero-required-param, high-complexity aggregate tool with an output schema, the description covers domain preconditions, filter semantics, result segmentation, and truncation behavior. An agent has everything needed to decide when to call it and how the filter changes the result.

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 baseline is 3, but the description adds real semantics the schema lacks: that the pipeline filter applies ONLY to the opportunity breakdowns while revenue/renewals/at-risk remain workspace-wide, and what omitting both keys yields (default pipeline + unassigned). Precedence of pipeline_id over pipeline_key is already in the schema, so the description's added value is partial rather than complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb+resource ('Aggregate roll-up of the workspace's opportunities and revenue') and the body enumerates exactly what is returned (stage/type breakdown, pipeline_by_lens, revenue roll-up, renewals, at-risk accounts). It is very clear what the tool produces. However, it never names or contrasts itself against adjacent read tools like run_report or export_report, so sibling differentiation is left to inference.

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?

There is an explicit 'When to use' section with domain ('The Revenue sales pipeline'), a precondition ('never before a workspace has chosen its motion'), and a when-not ('Don't reach for it to answer a vague show me my data'). This is strong guidance. It stops short of naming the alternative tool to use for those rejected cases, so it is not a 5.

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