Skip to main content
Glama

get_quote

Delivered price for one variant to a US zip code: item + the store's own shipping rate for that address + estimated sales tax, plus the delivery estimate. Nothing is bought. Use it to compare real totals across stores.

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>",
      "zip": "<zip>"
    },
    "name": "get_quote"
  }
}

Input Schema

NameRequiredDescriptionDefault
zipYes
stateNo
quantityNo
product_idYes
variant_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose the key behavioral fact — this is a read-only quote, nothing is purchased — plus exactly what the returned number is composed of. It omits whether quotes expire or are re-fetched live, which matters for comparison shopping.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the computed price is front-loaded, followed by the non-purchase clarification and the use case. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the safety profile is covered. But for a total-price calculator, leaving quantity and state semantics unaddressed is a real gap an agent could get wrong.

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 description coverage is 0% across 5 parameters, so the description must compensate and largely does not. It implies variant and zip but never explains quantity (which changes the total), state (likely tax-relevant), or product_id.

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?

Names the exact resource (a delivered price for one variant to a US zip) and enumerates its components: item price, the store's own shipping rate, estimated sales tax, plus the delivery estimate. This is clearly distinguishable from purchase-oriented siblings such as place_order and create_checkout.

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?

"Use it to compare real totals across stores" gives an explicit use case, and "Nothing is bought" draws the boundary against the checkout/order siblings. It stops short of naming those siblings or stating when not to use it.

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