Indicative duty + VAT estimate. NOT authoritative — always render the returned disclaimer verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| declared_value_eur | Yes | ||
| destination_country | Yes | ISO-3166 alpha-2 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that results are indicative, not authoritative, and that the response contains a disclaimer that must be rendered verbatim. This is meaningful behavioral context beyond the bare operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one short sentence with the key qualification front-loaded. No wasted words; the disclaimer requirement earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple estimation call and covers the critical output caveat, but without an output schema or annotations it leaves parameter meaning and response shape partially implicit. The optional category in particular is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (destination_country has an ISO description). The description does not explain declared_value_eur or the optional category, nor how they affect the estimate, so it fails to compensate for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (customs duty and VAT) and the action (estimate), and flags the indicative nature. This is distinct from the sibling tools, which concern shipping quotes, routes, and tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use the tool, and the 'NOT authoritative' warning sets expectations, but there is no explicit when-to-use vs alternative guidance or exclusion. It tells the agent how to handle the result rather than when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action: reference data, pricing, customs, courier discovery, storefronts, and tracking. Even closely related tools like get_courier, get_storefront, and search_couriers are clearly separated by function.
All tool names follow a consistent imperative verb_noun snake_case pattern. The get_ prefix is used for lookups, while convert_, estimate_, search_, and track_ clearly signal different actions.
Twelve tools is well within the ideal range, and each tool covers a distinct operational need for the EuroCollis pre-booking and tracking workflow. There is no obvious redundancy or bloat.
The set covers routes, cities, services, prohibited items, quotes, customs estimates, currency conversion, courier discovery, storefronts, and tracking, so nearly all public user intents are supported. Minor gaps remain around explicit supported-country/currency lists and the final booking step, but agents can work around these via get_routes and get_eurocollis_info.