Skip to main content
Glama

Set opportunity products

set_opportunity_products
DestructiveIdempotent

Set the products on an opportunity so its VALUE derives from them (replace-all). You pick a SELECTION of catalog products + a count for each; the SERVER prices it — it snapshots each product's price from the catalog, computes every line total, and writes the total into the opportunity's value (amount). You never pass a price. The list you pass becomes the WHOLE product set on the opportunity (the previous lines are replaced); pass an empty list to clear the products (the value follows to zero — no products, no value). Catalog products live on the product object: each prices from its unit_price_cents (an INTEGER number of cents) and its pricing_mode — per_unit multiplies by the count, flat charges once regardless of count (a flat line with count > 1 is flagged so a mispriced catalog is never silent). Discounts are by PERCENT only (a per-line discount_pct, and/or a top-level discount_pct for the whole opportunity) — the server computes the discount cents; you never pass a money amount. Bundled items are expanded automatically. A count outside a product's tier is flagged (not blocked). A discontinued catalog item can still be priced on an existing agreement by passing include_discontinued:true on its line (a boolean, not a price). Available once the 'opportunity_products' template is applied. Returns the opportunity's fresh state, its priced lines, and any flags.

When to use: When an opportunity's value should come from the products on it (available once the 'opportunity_products' template is applied). You pick the catalog items and how many of each; the server prices them and writes the total into the opportunity's value — you never pass a price. The list you pass replaces the whole product set; pass an empty list to clear it (the value follows to zero).

Example: Put 15 units of the standard plan on the Acme opportunity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linesYesThe WHOLE product set (replace-all): [{product_id: product uuid, quantity: integer ≥ 0, discount_pct?: 0–100, include_discontinued?: boolean}]; [] clears every line.
discount_pctNoA number from 0 to 100.
opportunity_idYesA uuid.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
updatedNo
guidanceNo
line_itemsNo
opportunityNo
missing_objectsNo
tier_validationsNo
pricing_mode_validationsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations declare destructive=true and idempotent=true, and the description independently justifies both: it spells out that the previous lines are destroyed ('the list you pass becomes the WHOLE product set... previous lines are replaced') and that a repeated call with the same list is stable. It further discloses server-side pricing, snapshotting, discount computation, automatic bundle expansion, flag-not-block behavior for tier violations, and the include_discontinued escape hatch — all 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 core facts are front-loaded, but the 'When to use' paragraph largely restates the opening paragraph verbatim ('you never pass a price', 'The list you pass replaces the whole product set; pass an empty list to clear it'). Heavy ALL-CAPS emphasis (VALUE, SELECTION, SERVER, WHOLE, PERCENT) adds length without adding information; a third of the text is redundant.

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?

An output schema exists, so return values need not be enumerated, yet the description still notes that it returns fresh state, priced lines, and flags. Combined with the template prerequisite, pricing model, clearing behavior, and edge-case flags, an agent has everything needed to invoke this correctly on the first attempt.

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 the baseline is 3, but the description genuinely adds meaning: it establishes that no price is ever passed ('You never pass a price', 'a boolean, not a price'), that discounts are percent-only and server-computed, and what quantity/flag semantics mean at the line level. It stops short of documenting per-parameter formats already covered by the schema, which is appropriate.

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 ('Set the products on an opportunity'), plus the key semantic consequence ('so its VALUE derives from them (replace-all)'). This distinguishes it from sibling mutation tools like update_record or update_quote, which would not replace the whole product set and reprice.

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?

A dedicated 'When to use' section gives the routing condition (value should come from products) and the prerequisite (the 'opportunity_products' template must be applied). It also covers the clear-case behavior (empty list clears). However, it never names competing siblings such as update_quote or create_quote, so the agent must infer that this tool is preferred over them.

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