Skip to main content
Glama

Estimate shipping price

estimate_shipping_price
Read-only

Estimate the SAMOS price (GBP) to ship a parcel from the UK to a country, or to return a parcel from that country to the UK. Max weight 20 kg, max dimensions 100 cm x 43 cm x 43 cm.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNo"shipping" (UK to country, default) or "return" (country back to UK).
countryYesDestination country (or origin country for returns), as a name like "France" or ISO 3166-1 alpha-2 code like "FR".
weight_kgYesParcel weight in kg, between 0.1 and 20.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld=false/no destructive behavior, so the bar is lower; the description adds real behavioral constraints (20 kg and 100x43x43 cm caps) and discloses the returned currency, which the annotations do not. It omits whether overweight/oversize input errors or how pricing is derived, keeping it short of a 5.

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 sentences, zero filler: the core operation and modes come first, then the hard limits. Every clause carries usable information.

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?

For a read-only estimator with a fully documented schema and no output schema, the description supplies currency and mode semantics that help interpret the result. Minor gap: it advertises dimension limits while the schema exposes no dimension parameter, which could make an agent think dimensions are in scope.

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 description coverage is 100%, so the schema already documents country format, weight range, and the type enum. The description echoes the direction logic and the 20 kg ceiling but adds no syntax or format detail beyond the schema; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (estimate), resource (SAMOS shipping price), currency (GBP), and both directional modes (UK→country, country→UK). This is clearly distinguishable from track_parcel, list_destinations, estimate_duties, and search_help, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the two modes and their direction semantics, which implies when each applies, but gives no explicit when-to-use/when-not-to-use guidance and never points to estimate_duties for customs costs or list_destinations for valid country values.

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