Skip to main content
Glama

Create quote

create_quote

Draft a quote on an account from a SELECTION of catalog products + quantities. You pick the products and the count for each (e.g. the metric value — the number of units the item scales on); the SERVER prices it — it snapshots each product's price from the catalog and computes every line total and the quote total. You never pass a price. 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 quantity, flat charges once regardless of quantity, and a missing or unknown pricing_mode resolves to flat (a flat line with quantity > 1 is flagged so a mispriced catalog is never silent). Discounts are by PERCENT only (a per-line discount_pct on a line, and/or a quote-level discount_pct) — the server computes the discount cents; you never pass a money amount. Bundled items are expanded automatically (a discounted line discounts its bundled extras too). A quantity that falls outside a product's tier — or a discount above the workspace cap — is flagged (not blocked) so you can fix the selection. A quote is a pre-commit artifact: status is draft or sent (invoicing and contracts happen elsewhere). Returns the quote, its priced lines, and any flags.

When to use: When the user wants a priced quote for a customer. You pick the catalog items and how many of each; the server reads each item's price from the catalog and computes every line total and the quote total — you never pass a price. Bundled extras are added automatically; a count outside an item's range is flagged, not blocked. A quote is a pre-commit document (invoicing and contracts happen elsewhere).

Example: Quote Acme for 15 units of the standard plan plus onboarding.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional display name for the quote; stored on the quote header, null when omitted.
linesYesAt least one item.
notesNoOptional free-text notes stored on the quote header (terms, context); never read for pricing.
statusNoOne of: draft | sent.
account_idYesA uuid.
valid_untilNoMust match /^\d{4}-\d{2}-\d{2}$/.
discount_pctNoA number from 0 to 100.
opportunity_idNoA uuid.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
quoteNo
createdNo
guidanceNo
line_itemsNo
mixed_cadenceNo
missing_objectsNo
tier_validationsNo
annualized_total_centsNo
pricing_mode_validationsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare the generic mutation profile (not read-only, not destructive, not idempotent), so the description carries the real burden and does so well: the server snapshots catalog prices, the caller never passes money amounts, pricing_mode resolves per_unit/flat with missing mode defaulting to flat, bundles expand automatically, and out-of-tier quantities or over-cap discounts are flagged rather than blocked.

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 opening paragraph is dense but well front-loaded. The problem is redundancy: the 'When to use' block restates the pricing/never-pass-a-price/bundling/flagging points nearly verbatim, so a meaningful share of the text does not earn its place.

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?

With an output schema present and 100% schema coverage, the description only needs to cover behavior and it largely does: it explains the pricing model, discount rules, flagging, and the draft/sent lifecycle. Minor gaps remain (e.g., no mention of account/opportunity linkage requirements or permission needs), but nothing essential to correct invocation is missing.

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 description coverage is 100%, so the baseline is 3, but the description adds genuine semantics: discount_pct is percent-only with the server computing cents, quantity is an integer unit count, pricing_mode governs multiplication behavior, and a flat line with quantity > 1 is flagged. It does not add anything about name, notes, valid_until, or opportunity_id beyond the schema, keeping it short of a 5.

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 description states a precise verb and resource ('Draft a quote on an account') plus the key mechanic that separates it from sibling mutations: the caller selects catalog products and quantities while the server prices them. It clearly frames the artifact as pre-commit (draft/sent), distinguishing it from invoicing or contract tools.

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 keyed to the user intent ('wants a priced quote for a customer') and a clear exclusion that invoicing and contracts happen elsewhere. However, it never names the closest siblings (update_quote, set_opportunity_products) or states when to prefer them, so routing between quote tools is still left partly to inference.

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