Skip to main content
Glama

get_shipping_quote

Resolve a seller's shipping cost to a destination country before buying, without leaving this connector. Pass the seller_mcp_url from the listing's mcp_ref and the ISO 3166-1 alpha-2 country. Returns the flat rate, a per-order-quote signal, or a rejection. Call this before buy_product and pass buyer_country there to fold shipping into the total.

Input Schema

NameRequiredDescriptionDefault
deliveryNoRRG-network brands on VIA: the full delivery address, for live carrier rates.
product_idNoRRG-network brands on VIA quote live rates per item: pass the listing id (mcp_ref.product_id).
buyer_countryYesISO 3166-1 alpha-2 destination country code (e.g. GB, US, JP).
selected_sizeNo
selected_colorNo
seller_mcp_urlYesmcp_ref.seller_mcp_url from a find_seller / get_seller_products result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / delivery
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "RRG-network brands on VIA: the full delivery address, for live carrier rates.",
      +  "properties": {
      +    "address_line1": {
      +      "maxLength": 200,
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "address_line2": {
      +      "maxLength": 200,
      +      "type": "string"
      +    },
      +    "city": {
      +      "maxLength": 120,
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "country": {
      +      "maxLength": 2,
      +      "minLength": 2,
      +      "type": "string"
      +    },
      +    "name": {
      +      "maxLength": 200,
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "phone": {
      +      "maxLength": 40,
      +      "minLength": 4,
      +      "type": "string"
      +    },
      +    "postcode": {
      +      "maxLength": 40,
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "region": {
      +      "maxLength": 120,
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "name",
      +    "address_line1",
      +    "city",
      +    "postcode",
      +    "country",
      +    "phone"
      +  ],
      +  "type": "object"
      +}
    • addedInput schema / properties / product_id
      Added value: +{
      +  "description": "RRG-network brands on VIA quote live rates per item: pass the listing id (mcp_ref.product_id).",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / selected_color
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / selected_size
      Added value: +{
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and discloses the three distinct outcome branches: 'the flat rate, a per-order-quote signal, or a rejection'. That branch disclosure is genuinely useful. It stops short of stating auth needs, rate limits, or explicitly that it is side-effect-free, so it is not fully transparent.

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?

Four tight sentences: purpose, required inputs, return outcomes, and workflow placement. It is front-loaded with the core action and contains no filler.

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?

No output schema exists, and the description partially compensates by enumerating the possible return shapes. However, for a tool with a nested delivery object and several optional parameters, it omits guidance on when those inputs matter, leaving some operational gaps.

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

Parameters3/5

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

Schema coverage is 67% and the schema already documents buyer_country (ISO code) and seller_mcp_url (source). The description largely restates these ('ISO 3166-1 alpha-2 country', 'seller_mcp_url from mcp_ref') and adds only the delivery-address linkage. It says nothing about the delivery object, product_id, selected_size, or selected_color.

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+resource ('Resolve a seller's shipping cost to a destination country') and scopes it ('before buying, without leaving this connector'). An agent can distinguish it from get_quote or request_quote without opening a schema.

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?

Explicitly instructs 'Call this before buy_product and pass buyer_country there to fold shipping into the total', naming the sibling tool and the sequencing. It also names the alternative flow ('without leaving this connector'), so when-to-use is unambiguous.

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