Skip to main content
Glama

SzuruSzuru – rezerwacja czyszczenia tapicerki

Wycena

calculate_quote
Read-only

PURPOSE: Calculates the price of an order (unit prices, quantity discounts, add-ons, travel fee, minimum order) for a postal code. Returns quote_id (valid 30 minutes). WHEN TO USE: Whenever the customer asks how much a cleaning costs and you know the service(s), quantity and postal code. Also the first step before check_availability. WHEN NOT TO USE: Not for checking dates and never as a booking - it reserves nothing. REQUIRED: postal_code; items[] with service (id from list_upholstery_services) and quantity. Add-ons optional (names from the catalog; close spellings are matched, unknown ones return error unsupported_addon with allowed_addons). If postal code, service or quantity is unknown, ask the customer - do not guess. SIDE EFFECTS: none for the customer (stores a 30-minute quote only). CONSTRAINTS: Report total_from exactly; never estimate or adjust prices. Area not served -> error unsupported_postcode. below_min_order=true -> ask the customer to add a service before booking.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesServices to price
session_idNoOptional. session_id from the previous result, if you have it. The server also recovers the session from quote_id / slot_id / confirmation_id / customer_grant.
postal_codeYesPolish postal code NN-NNN, e.g. 80-180

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo
errorNoStable machine-readable error id when success=false, e.g. missing_required_fields, unsupported_postcode, no_availability
itemsNo
messageNo
successYestrue = operation done / data returned; false = see error
currencyNo
quote_idNo
expires_atNo
session_idNo
total_fromNo
delivery_feeNo
missing_fieldsNo
below_min_orderNo
services_subtotalNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / items / description
      Added value: +"Services to price"
    • changedInput schema / properties / items / items / properties / addons / description
      Previous value: -"Add-on names exactly as listed for the service"New value: +"Optional add-on names as listed for this service, e.g. \"Impregnacja Ochronna Przed Zabrudzeniami\""
    • changedInput schema / properties / items / items / properties / quantity / description
      Previous value: -"Pieces, mattress sides (1-2) or square metres for carpets"New value: +"Pieces (whole number), mattress sides (1-2) or square metres for carpets"
    • changedInput schema / properties / items / items / properties / service / description
      Previous value: -"Service id from list_upholstery_services"New value: +"Service id from list_upholstery_services, e.g. pranie_naroznika_l_4_5_os"
    • addedInput schema / properties / postal_code / description
      Added value: +"Polish postal code NN-NNN, e.g. 80-180"
    • changedInput schema / properties / postal_code / pattern
      Previous value: -"^\\d{2}-?\\d{3}$"New value: +"^\\d{2}[-\\s]?\\d{3}$"
    • changedInput schema / properties / session_id / description
      Previous value: -"Session id from a previous response (keeps quote, slots and confirmation together)"New value: +"Optional. session_id from the previous result, if you have it. The server also recovers the session from quote_id / slot_id / confirmation_id / customer_grant."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "below_min_order": {
      +      "type": "boolean"
      +    },
      +    "code": {
      +      "type": "string"
      +    },
      +    "currency": {
      +      "type": "string"
      +    },
      +    "delivery_fee": {
      +      "type": "number"
      +    },
      +    "error": {
      +      "description": "Stable machine-readable error id when success=false, e.g. missing_required_fields, unsupported_postcode, no_availability",
      +      "type": "string"
      +    },
      +    "expires_at": {
      +      "type": "string"
      +    },
      +    "items": {
      +      "type": "array"
      +    },
      +    "message": {
      +      "type": "string"
      +    },
      +    "missing_fields": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "quote_id": {
      +      "type": "string"
      +    },
      +    "services_subtotal": {
      +      "type": "number"
      +    },
      +    "session_id": {
      +      "type": "string"
      +    },
      +    "success": {
      +      "description": "true = operation done / data returned; false = see error",
      +      "type": "boolean"
      +    },
      +    "total_from": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "success"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context beyond them: the returned quote_id is valid for 30 minutes, side effects are none for the customer (the quote is stored only), and named error behaviors are documented (unsupported_addon, unsupported_postcode, below_min_order). This gives the agent a complete operational picture.

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 well-structured with front-loaded, capitalized section headings (PURPOSE, WHEN TO USE, WHEN NOT TO USE, REQUIRED, SIDE EFFECTS, CONSTRAINTS), making scanning easy. It is longer than a typical description, but almost every sentence carries operational value; only brief retellings of required parameters overlap with the schema.

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 quote-calculation tool with an output schema and rich annotations, the description covers all decision-critical points: prerequisites, alternatives, error conditions, quote expiry, side effects, and the constraint to report total_from exactly. Nothing an agent needs to call it correctly appears to be 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 100%, so baseline is 3. The description still adds value: it clarifies that service ids come from list_upholstery_services, that add-ons are optional and matched with close spellings, that unknown add-ons trigger unsupported_addon with allowed_addons, and that the agent should ask the customer rather than guess unknown values. This goes beyond what the schema alone communicates.

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 precise verb+resource: 'Calculates the price of an order (unit prices, quantity discounts, add-ons, travel fee, minimum order) for a postal code.' It also explicitly distinguishes this tool from siblings by naming check_availability and contrasting it with booking, so an agent can route correctly without schema inspection.

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 provides explicit WHEN TO USE ('Whenever the customer asks how much a cleaning costs...', 'first step before check_availability') and WHEN NOT TO USE ('Not for checking dates and never as a booking - it reserves nothing') sections. This is exactly the when/when-not/alternatives guidance the dimension rewards.

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