Capable

Create quote

create_quote

Draft a quote for an account from catalog product IDs and quantities. The server snapshots catalog prices and computes lines/totals: never pass a price or money amount. Discounts are percentages (line and/or quote discount_pct); above-cap discounts are flagged. Products use unit_price_cents; per_unit multiplies by quantity, flat charges once, and missing/unknown pricing_mode means flat. A flat quantity >1 is flagged. Bundles expand automatically and inherit line discounts; out-of-tier quantities are flagged, not blocked. Returns the quote, priced lines and flags. Status draft/sent records a pre-commit artifact; invoicing and contracts happen elsewhere.

When to use: The user asks for a customer quotation.

Example: Quote Acme for 15 standard-plan units.

Input Schema

Name	Required	Description
`name`	No	Optional display name for the quote; stored on the quote header, null when omitted.
`lines`	Yes	At least one item.
`notes`	No	Optional free-text notes stored on the quote header (terms, context); never read for pricing.
`status`	No	One of: draft \| sent.
`account_id`	Yes	A uuid.
`valid_until`	No	Must match /^\d{4}-\d{2}-\d{2}$/.
`discount_pct`	No	A number from 0 to 100.
`opportunity_id`	No	A uuid.

Output Schema

Name	Required	Description	Default
`note`	No
`quote`	No
`created`	No
`guidance`	No
`line_items`	No
`mixed_cadence`	No
`missing_objects`	No
`tier_validations`	No
`annualized_total_cents`	No
`pricing_mode_validations`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 24, 2026
- removedInput schema / properties / discount_pct / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "string"
-  }
-]
```
- addedInput schema / properties / discount_pct / type
```
Added value: +[
+  "number",
+  "string"
+]
```
- removedInput schema / properties / lines / items / properties / discount_pct / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "string"
-  }
-]
```
- addedInput schema / properties / lines / items / properties / discount_pct / type
```
Added value: +[
+  "number",
+  "string"
+]
```
- removedInput schema / properties / lines / items / properties / quantity / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "string"
-  }
-]
```
- addedInput schema / properties / lines / items / properties / quantity / type
```
Added value: +[
+  "number",
+  "string"
+]
```
Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
Changed12 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 / guidance / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / guidance / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / line_items / items / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / line_items / items / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / pricing_mode_validations / items / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / pricing_mode_validations / items / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / quote / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / quote / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / tier_validations / items / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / tier_validations / items / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
First observedOct 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly=false, destructive=false, idempotent=false), and the description substantially exceeds that. It discloses that the server snapshots catalog prices and computes totals, that out-of-cap discounts and out-of-tier bundle quantities are flagged rather than blocked, that bundles expand and inherit line discounts, and that status draft/sent records a pre-commit artifact.

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?

The core constraint (never pass a price; server computes lines/totals) is front-loaded and most of the density is load-bearing pricing semantics. The pricing_mode clauses are somewhat compressed into run-on phrasing, costing a bit of readability, but no sentence is filler.

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?

With an output schema present, the description needn't detail return values, yet it still summarizes them ('the quote, priced lines and flags'). For a non-idempotent mutation with 8 parameters and nested line objects, the description covers the behavioral and pricing rules an agent needs to call it correctly.

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 would be 3, but the description adds real semantics the schema lacks: it forbids passing money amounts, explains that discounts are percentages at both line and quote level, and clarifies pricing_mode behavior (per_unit multiplies, flat charges once, missing/unknown means flat). The only gap is that it never explains opportunity_id or valid_until, which the schema covers only shallowly.

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 ('Draft a quote for an account') plus the input basis ('catalog product IDs and quantities'), and it explicitly bounds the scope by saying invoicing and contracts happen elsewhere. An agent can tell this apart from update_quote and from generic record creation without opening a 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?

There is an explicit 'When to use' line ('The user asks for a customer quotation') plus a concrete example, which is clear context for selection. It stops short of naming exclusions or the sibling to use for editing an existing quote (update_quote), so it is not a full when/when-not treatment.

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?