Skip to main content
Glama

Price a configuration

price_configuration
Read-only

Prices a configuration with the website's price list and gives, for each production speed (urgente, standard, economica), the estimated ship date: the day the order leaves the warehouse and is handed to the courier, not the delivery date. Prices VAT excluded as the product page shows them (total_excl_vat, struck-through list_total_excl_vat) and VAT included (total); promotions with their end date. Call get_product first: product_id, variant_id, options and allowed quantities come from there. Options left out take the default value of the product page (default: true in the response); those hidden by the rules are listed in ignored_option_ids. Guest prices (no loyalty discounts), excluding shipping, packaging and payment-method fees (e.g. cash on delivery), which the website adds at checkout.

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": {
      "product_id": "<product_id>",
      "variant_id": "<variant_id>",
      "quantity": "<quantity>"
    },
    "name": "price_configuration"
  }
}

Input Schema

NameRequiredDescriptionDefault
widthNoWidth in cm, for made-to-measure products.
heightNoHeight in cm.
quantityYesNumber of pieces, among those allowed in metadata.configurator.
subjectsNoNumber of different artworks sharing the quantity, up to metadata.configurator.max_subjects.
product_idYesProduct id.
selectionsNoChosen values: attribute_option_id and value_id from metadata.configurator.attributes.
variant_idYesMaterial id: metadata.configurator.variant_id of get_product.
graphic_serviceNo0 none, 1 operator check of the print file, 2 basic graphic design, 3 advanced graphic design; priced per subject as in metadata.configurator.graphic_services. Omit it when that list is empty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / graphic_service / description
      Added value: +"0 none, 1 operator check of the print file, 2 basic graphic design, 3 advanced graphic design; priced per subject as in metadata.configurator.graphic_services. Omit it when that list is empty."
    • changedInput schema / properties / height / description
      Previous value: -"Altezza in cm."New value: +"Height in cm."
    • changedInput schema / properties / product_id / description
      Previous value: -"id del prodotto."New value: +"Product id."
    • addedInput schema / properties / quantity / description
      Added value: +"Number of pieces, among those allowed in metadata.configurator."
    • addedInput schema / properties / selections / description
      Added value: +"Chosen values: attribute_option_id and value_id from metadata.configurator.attributes."
    • addedInput schema / properties / subjects / description
      Added value: +"Number of different artworks sharing the quantity, up to metadata.configurator.max_subjects."
    • changedInput schema / properties / variant_id / description
      Previous value: -"id del materiale: metadata.configurator.variant_id."New value: +"Material id: metadata.configurator.variant_id of get_product."
    • changedInput schema / properties / width / description
      Previous value: -"Larghezza in cm, se il prodotto e' a misura."New value: +"Width in cm, for made-to-measure products."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond the read-only annotations: ship date is defined as warehouse hand-off not delivery, prices are guest prices without loyalty discounts, shipping/packaging/payment fees are excluded, promotions carry end dates, and defaults/ignored options are described. This is exactly the kind of behavioral detail an agent needs.

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 and front-loaded with purpose and output meaning. Some sentences are long and clause-heavy, but each carries useful information and there is no 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 no output schema and eight parameters, the description supplies the output semantics (total_excl_vat, list_total_excl_vat, total, promotions, default, ignored_option_ids) and the pricing scope. An agent has enough to call it correctly and interpret the response.

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 adds relational meaning: product_id, variant_id, options and quantities come from get_product, omitted options take the product-page default, and rule-hidden options appear in ignored_option_ids. It does not document selection object syntax beyond the schema, but it meaningfully enriches parameter interpretation.

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 ('Prices a configuration') and immediately scopes the output: per-speed ship dates, VAT-inclusive/exclusive totals, and promotions. It explicitly routes the agent to get_product first, distinguishing this tool from its siblings.

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?

Gives a strong prerequisite ('Call get_product first: product_id, variant_id, options and allowed quantities come from there') and explains how omitted options behave. It does not explicitly compare against lookup_catalog or search_catalog, but the workflow context is clear.

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