Quote Price Optimization (Win Probability)

Quote Price Optimization (Win Probability) — Saifs AI

quote_pricing

Read-only

Recommend the quote price that maximises expected margin, from your own won / lost quote history. Inputs: quote_history (quote_ref, date, segment, customer_type, product, qty, cost, list_price, quoted_price or amount, outcome won / lost / open, competitor_count; CRM / CPQ headers as exported), deal or deals (same fields, optional quoted_price to judge), quote_model_snapshot (from an earlier run), tender + tender_history (public bid results) for sealed bids, job (fit_win_model, price_recommendation, explain_price, tender_bid, discount_leakage, win_loss_report). Returns decision cards first, a price range with P(win) and expected margin at each price, explanation, Friedman / Gates tender bid, discount waterfall and leakage, win/loss report and an updated snapshot. Uses penalised logistic regression and Friedman bidding. Under 200 closed quotes gives rules of thumb only. Never uses protected attributes or competitors' private prices. Not for list price setting across a whole catalogue, demand forecasting or loan / interest pricing. Bigger exports: quote_pricing_get_engine.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "quote_pricing"
  }
}

Input Schema

Name	Required	Description	Default
`job`	No	Omit to run everything the inputs allow.
`deal`	No	The deal to price: segment, customer_type, product, qty, cost, list_price, competitor_count; quoted_price to judge a proposed price.
`seed`	No
`as_of`	No
`deals`	No	Several deals to price.
`forget`	No
`tender`	No	Sealed tender: engineers_estimate (or reference), our_cost, competitors (names) or competitor_count, date.
`mapping`	No	Header -> standard field overrides.
`our_name`	No	Our company's name as it appears in tender_history.
`date_order`	No
`expired_as`	No		lost
`max_listed`	No
`min_margin`	No
`min_quotes`	No
`margin_band`	No
`price_basis`	No		auto
`min_win_odds`	No
`quote_history`	No	Past quotes, won AND lost (open ones are ignored for fitting): quote_ref, date, segment, customer_type, product, region, rep, qty, cost, list_price, quoted_price or amount, discount, outcome, competitor_count; off-invoice rebate / freight / promo / cash_discount for the waterfall.
`segment_field`	No		segment
`tender_history`	No	Public bid results of earlier tenders: tender id, bidder, bid amount, engineer's estimate, date (one row per bidder per tender).
`currency_symbol`	No	Symbol on the cards, e.g. '₹' (lakh / crore grouping) or '$'. Default: the currency the data is written in.
`allow_above_list`	No
`protected_fields`	No
`min_segment_quotes`	No
`quote_model_snapshot`	No	quote_model_snapshot from an earlier run (the model).
`recency_half_life_days`	No

Output Schema

Name	Required	Description
`model`	No
`alerts`	No
`status`	Yes	1 = processed, 0 = refused (see decisions)
`tender`	No
`message`	No
`metadata`	Yes
`decisions`	Yes	Plain-language cards, priority order. Relay these first.
`assumptions`	No
`recommendations`	No
`win_loss_report`	No
`discount_leakage`	No
`data_quality_report`	No
`quote_model_snapshot`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/non-destructive/closed-world, and the description adds genuinely non-obvious behaviour: penalised logistic regression and Friedman bidding methods, a 200-quote threshold that downgrades to rules of thumb, and explicit statements that protected attributes and competitors' private prices are never used. It also sketches the return payload, which is partly redundant with the existing output schema but harmless.

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 critical purpose is front-loaded in sentence one, which is good. But the remainder is a single dense block of semicolon-separated parentheticals, and a substantial share of it restates the input schema and the output schema rather than adding new information.

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?

For a 26-parameter modelling tool with both an output schema and safety annotations, the description covers method, data prerequisites, exclusions, and escalation to the engine variant. The remaining gap is the opaque tuning parameters, which the agent must read from the schema alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 38% across 26 parameters, so the description has to carry weight, and it does not. It groups the major data inputs (quote_history, deal/deals, tender, tender_history, quote_model_snapshot, job) but repeats field lists already in the schema and says nothing about the many tuning knobs (margin_band, min_win_odds, price_basis, min_quotes, forget, recency_half_life_days, allow_above_list, protected_fields, mapping) that materially change the recommendation.

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?

Opens with a precise verb+resource+objective: 'Recommend the quote price that maximises expected margin, from your own won / lost quote history.' An agent immediately knows what the tool produces and the data basis, and the sibling quote_pricing_get_engine is distinguished later by scope ('Bigger exports').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit exclusions are stated ('Not for list price setting across a whole catalogue, demand forecasting or loan / interest pricing') and an alternative is named for a specific condition ('Bigger exports: quote_pricing_get_engine'). It also gives a data-sufficiency rule ('Under 200 closed quotes gives rules of thumb only') that tells the agent when results degrade.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Quote Price Optimization (Win Probability) 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.