Skip to main content
Glama

Quote products

quote_onboarding_products
Read-only

Calculates indicative prices for up to twenty products for the company with this CVR, from one flat answers object. A plain key answers a question for the company and for every selected product that asks it; <product>.<name> answers one product's question. Stored answers and company discounts are not reused; supply required answers explicitly. An optional partnerCode applies that partner's discount. Enum fields use {value, label: {da, en}}. Each product has a status.value: only quoted products have a price; contactPlain products need an individual offer from Plain and unavailable ones cannot be offered (see issue). Prices are in DKK (major units) per billingFrequency.value period, with annualPrice for comparison and totals across products. State prices with each quote's display text in the customer's language, and always show the disclaimer. When pricePerEmployee is true, the price is per employee: say so using the quote's notice, as the customer selects the covered employees on Plain. Unknown answer keys are ignored and reported in warnings; required answers are never inferred. Nothing is bound, created or charged. Works without signing in, as a public new-company quote. Quotes for an existing customer must use the selected, authorized company's CVR. Active products return status.value alreadyInsured with no new-offer price and are excluded from totals and creation; held prerequisites do not need to be selected again. Check list_companies.canCreateOffers before promising to create offers. Quoting itself only needs policies:read. For existing companies, use get_onboarding_payment_link after creating offers for authenticated review; continueUrl is the public new-company signup page and does not apply private policy exclusions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cvr": "<cvr>",
      "products": "<products>",
      "answers": "<answers>"
    },
    "name": "quote_onboarding_products"
  }
}

Input Schema

NameRequiredDescriptionDefault
cvrYesDanish company registration number (CVR), eight digits, e.g. 39488914.
regionNoMarket. Only Denmark (dk) is supported. Optional; defaults to dk.dk
answersYesEvery answer in one object, keyed by the catalog question `name`. A plain name answers that question for the company and for every selected product that asks it; `<product>.<name>` (e.g. loesoereforsikring.basement) answers only that product's question and takes precedence. Employee FTE questions are answered as `<name>.fullTime` and `<name>.partTime` head counts: integers from 0 to 9999 inclusive. When required, send both counts explicitly, including zero.
productsYesThe products to quote: 1 to 20 distinct slugs, including any products they require.
startDateNoPolicy start date (YYYY-MM-DD). Defaults to today. Must be between today and one year ahead.
partnerCodeNoOptional partner discount code, 2-64 letters, digits, hyphens or underscores. Must be active.

Output Schema

NameRequiredDescriptionDefault
quotesYesOne quote per selected product, in request order.
totalsYesTotals of the quoted products; null when no product is included.
quoteIdYesIdentifies these prices; pass it as `quoteId` to /start with the exact original quote request. Only quoted products become offers. Null when no product is quoted.
warningsNoNon-fatal problems with ignored answers. Omitted when there are none.
expiresAtYesUntil when quoteId can be used for /start, unless prices change first; then request a new quote.
startDateYesThe insurance start date the prices apply to; today when the request has none.
disclaimerYesShow with the prices: they are indicative, and nothing binds until the customer signs on Plain.
continueUrlYesWhere the customer reviews this quote on Plain and continues to sign up. Opening it creates nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly and non-destructive annotations, the description discloses that stored answers and company discounts are not reused, unknown keys are ignored and reported in warnings, and required answers are never inferred. It further explains product statuses such as quoted, contactPlain, unavailable and alreadyInsured, including how they affect pricing and totals.

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 description is dense but front-loads the core purpose and then proceeds through answer semantics, product statuses, pricing output and authorization guidance in a coherent order. Some sentences, especially the presentation guidance about display text, disclaimer and continueUrl, are tangential to invoking the tool and make the paragraph longer than necessary.

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 complex quoting tool with nested answers, product statuses, pricing rules and an output schema, the description covers the behavior an agent needs to call it correctly and interpret the result. Remaining parameter details such as region and startDate are fully documented in the schema, so no critical invocation information 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 coverage is already 100%, so the schema carries the baseline parameter documentation, but the description adds important semantics for the answers object, product qualification, partnerCode discount behavior and the requirement to use the selected authorized company's CVR for existing customers. It does not add much for region or startDate, which remain covered only by the schema.

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 opens with a specific verb and resource: it calculates indicative prices for up to twenty products for a company identified by CVR. It also distinguishes the operation from related siblings by stating that nothing is bound, created or charged, and by pointing to get_onboarding_payment_link for the post-offer review flow.

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?

It gives explicit usage conditions: public new-company quoting works without signing in, existing customers must use the selected authorized company's CVR, and list_companies.canCreateOffers should be checked before promising offer creation. It also names the follow-on tool for existing companies and clarifies that quoting itself only needs policies:read.

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