customswise
Server Details
Practitioner-verified EU customs facts: classification, duty, origin, procedures. x402.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: general Q&A, restrictions screening, classification, origin rules, procedures, tariff lookup, and catalog listing. No overlap or ambiguity.
All names use lowercase with underscores and follow a verb_noun pattern (e.g., ask_customs, class_product). Minor variation in verb choice ('get' used three times, 'list' once) but consistent style.
Seven tools cover the core customs workflow (FAQ, restrictions, classification, origin, procedures, tariffs, and a catalog) without being excessive. Each tool has a clear role.
Covers major customs needs including general questions, restrictions, classification, origin, procedures, and tariffs. Minor gaps such as a dedicated duty calculation tool are mitigated by tariff rates. High-risk cases are escalated, so no dead ends.
Available Tools
7 toolsask_customsAInspect
Ask a general EU/Italy customs question in natural language and get a practitioner-verified answer. Covers common real-world topics such as the required import-documentation checklist, duties on goods from China, transfer-of-residence duty/VAT relief, temporary admission / inward processing for repair, and Italy-San Marino trade formalities. Use it when you don't know which specialised tool fits, or for procedural 'how do I…' questions. Guidance only, not binding advice; high-risk cases are flagged for expert escalation. Cost: $0.25 per call, paid automatically via x402 (USDC micropayment over HTTP 402).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Your customs question in plain language, e.g. 'What documents do I need to import from China?' or 'Do I pay duty moving personal goods to Italy from outside the EU?'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that answers are guidance only, not binding advice; high-risk cases are flagged for expert escalation; and cost is disclosed. No annotations to contradict.
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?
Three sentences covering purpose, usage, examples, behavior, and cost. No unnecessary words, front-loaded with key information.
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?
Covers topics, behavior, cost, and usage. No output schema but for a Q&A tool this is reasonable. Could mention return format or limitations more explicitly.
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 coverage is 100% with a clear description for the 'q' parameter. The description adds examples, enhancing understanding beyond the 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 clearly states the tool answers EU/Italy customs questions in natural language with practitioner-verified answers, and explicitly distinguishes from sibling tools by advising use when unsure which specialized tool fits.
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?
Explicit guidance provided: 'Use it when you don't know which specialised tool fits, or for procedural 'how do I…' questions.' Also mentions escalation for high-risk cases and cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_restrictionsAInspect
Expert-verified EU import/export restriction screening. Give a product, HS code or country and get known prohibitions, licence/authorisation requirements, sanctions exposure and dual-use flags, reviewed by a licensed customs professional. Use it to check whether goods can legally move before you ship. High-risk topics (Russia/sanctions clearance, dual-use determinations) are NEVER answered autonomously — they are flagged for mandatory expert escalation. Guidance only, not binding advice. Cost: $0.25 per call, paid automatically via x402 (USDC micropayment over HTTP 402).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Product, HS code or country to screen, e.g. 'drone with camera', '8525' or 'export to Russia'. | |
| lang | No | Response language: 'en' (default) or 'it'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is expert-verified, provides guidance only (not binding advice), flags high-risk topics for escalation, and costs $0.25 per call via x402 micropayment. This adds significant behavioral context beyond the input schema.
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 description is well-structured with a lead sentence summarizing the tool, followed by usage, behavioral constraints, and cost. It is somewhat lengthy but each sentence adds value without redundancy.
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?
Given the tool has no output schema, the description compensates by detailing return information (prohibitions, licences, sanctions, dual-use flags) and includes cost, payment method, and escalation policy. It is comprehensive for a two-parameter screening tool.
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 coverage is 100% and the description adds concrete examples for each parameter (e.g., 'drone with camera', '8525', 'export to Russia'), clarifying usage beyond the schema's plain descriptions. It also explains the output nature and language option.
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 clearly states the tool screens EU import/export restrictions, using specific verbs like 'screen', 'check', and references a distinct resource (prohibitions, licences, sanctions, dual-use). It distinguishes itself from siblings by focusing on restriction checking, not tariff or classification.
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 description explicitly advises using the tool before shipping ('Use it to check whether goods can legally move before you ship') and identifies high-risk topics that are never answered autonomously. It does not explicitly contrast with sibling tools, but the context of when-not-to-use (escalation required) is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
classify_productAInspect
Expert-verified EU/Italy customs classification support. Give a plain-language product description and get the likely HS/CN tariff heading orientation, the classification reasoning/notes, and any import-restriction flags — reviewed and signed by a licensed customs professional. Use it before shipping cross-border to avoid a wrong HS code, which causes fines, seized goods and back-duties. Guidance only, NOT a legally binding Tariff Information (BTI/ITV); genuinely ambiguous cases are flagged for expert escalation. Cost: $0.50 per call, paid automatically via x402 (USDC micropayment over HTTP 402).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Plain-language description of the product to classify — include material, function and form for a better match, e.g. 'stainless steel vacuum flask with plastic lid' or 'men's cotton knitted t-shirt'. | |
| lang | No | Response language: 'en' (default) or 'it'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it provides a 'likely' classification, notes each call costs $0.50 via HTTP 402, flags ambiguous cases for escalation, and clarifies it's guidance only. No destructive actions are implied, and no contradictions exist.
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 description is a single, well-structured paragraph that front-loads the core purpose. Every sentence adds value (purpose, use case, cost, caveats). Could be slightly more concise but remains clear and effective.
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?
Given the tool's complexity (customs classification) and lack of output schema, the description adequately explains return values (HS heading, reasoning, flags). It includes cost, legal caveats, and escalation handling, making it sufficiently complete for an agent.
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?
The schema covers both parameters with solid descriptions (100% coverage). The tool description adds valuable context, including example product descriptions ('stainless steel vacuum flask') and reinforces the format expectations, exceeding the baseline of 3.
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 clearly states the tool's purpose: expert-verified EU/Italy customs classification. It specifies the action (classify product), the resource (HS/CN tariff heading), and distinguishes from siblings like 'ask_customs' and 'get_tariff' by focusing on classification guidance.
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 description provides when to use ('before shipping cross-border'), what it returns, and cautions that it's not legally binding. However, it does not explicitly contrast with sibling tools or state when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_origin_ruleAInspect
Expert-verified preferential rules of origin for EU trade agreements. Give a product or an agreement and get the applicable rule of origin (e.g. tariff-shift or value-added criteria) plus how origin must be proven — EUR.1 movement certificate, statement on origin, or the REX registered-exporter system — reviewed by a licensed customs professional. Use it to determine whether goods qualify for a reduced/zero preferential duty and what documentation is required. Guidance only, not binding advice. Cost: $0.50 per call, paid automatically via x402 (USDC micropayment over HTTP 402).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Product or trade agreement to check, e.g. 'olive oil' or 'EU-South Korea EUR.1'. | |
| lang | No | Response language: 'en' (default) or 'it'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses cost ($0.50/call via HTTP 402), non-binding guidance status, and expert verification. It does not mention auth, rate limits, or data freshness, but the provided traits are valuable.
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 description is four sentences, front-loaded with the main purpose, and every sentence adds value (purpose, output, disclaimer, cost). No wasted words.
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?
Given no output schema, the description compensates by describing what is returned (rule + proof method). It covers input, output, cost, and disclaimer. Could mention error handling or limitations, but adequate for a simple query tool.
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 100%, so baseline is 3. The description does not add new meaning beyond the schema; it only reinforces the usage of the 'q' parameter. No value add for 'lang'.
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 clearly states the tool returns expert-verified preferential rules of origin for EU trade agreements, with specific examples of outputs (tariff-shift criteria, documentation methods). It distinguishes from siblings like get_tariff and classify_product by focusing on origin rules.
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 description explains the tool is for determining origin qualification and required documentation, giving clear context. It does not explicitly exclude use cases or contrast with siblings, but the purpose statement is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_procedureAInspect
Expert-verified explanation of EU special customs procedures: inward processing, outward processing, returned goods relief, and temporary admission. Returns the purpose, eligibility conditions, required documents and practical notes for the chosen regime, reviewed by a licensed customs professional. Use it to understand how to suspend or reclaim duty/VAT when goods are processed, repaired or temporarily moved across the EU border. Complex regime structuring is flagged for expert escalation. Guidance only, not binding advice. Cost: $0.25 per call, paid automatically via x402 (USDC micropayment over HTTP 402).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Special-regime keyword(s), e.g. 'inward processing', 'temporary admission', 'returned goods relief' or 'repair'. | |
| lang | No | Response language: 'en' (default) or 'it'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behaviors: expert-verified, non-binding advice, cost of $0.25 per call via HTTP 402, and escalation for complex cases. Destructive behavior is not applicable.
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 description is concise, front-loaded with purpose, and every sentence adds value without redundancy. It covers purpose, output, usage, cost, and limitations efficiently.
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?
Despite no output schema, the description explains what the output contains (purpose, eligibility, documents, notes). It sets expectations for guidance vs binding advice and cost. Complete for the tool's scope.
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 coverage is 100% with descriptions for 'q' and 'lang'. The description adds context by suggesting example keywords and specifying language options, going beyond the 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 clearly states the tool provides expert-verified explanations of EU special customs procedures like inward processing and temporary admission. It distinguishes from sibling tools by focusing on suspension/reclaim of duty/VAT for specific regimes.
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 description explains when to use (to understand duty/VAT suspension/reclaim) and flags complex regimes for escalation, but does not explicitly state when not to use or list alternative tools. The context and sibling tools imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tariffAInspect
Expert-verified import duty and Italian import VAT for any EU HS/CN code. Returns the practitioner-verified third-country duty where available; for every other valid code it still returns the normalized/validated code, the applicable Italian import VAT rate, and a direct deep link to the official EU TARIC page — so you always get a usable answer. Use it to estimate landed cost or confirm the duty on a classified good. Duty rates change over time, so treat this as reference, not a binding ruling. Cost: $0.25 per call, paid automatically via x402 (USDC micropayment over HTTP 402). Example code: '6109100010'.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | HS/CN tariff code to look up (6-10 digits; spaces or dots allowed), e.g. '6109 10 00' or '8471300000'. | |
| lang | No | Response language: 'en' (default) or 'it'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses what the tool returns (duty, VAT, normalized code, link) and includes critical behavioral details: cost ($0.25/call), payment method (x402 via HTTP 402), and a caveat that rates change over time. No annotations were provided, so the description carries the full burden.
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 description is concise yet info-dense. It starts with the main purpose, then details the outputs, use case, caveat, and cost—all in a logical, front-loaded structure. Every sentence serves a purpose without redundancy.
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?
Given no output schema, the description thoroughly explains what the tool returns and how to interpret it. It covers usage, limitations, and cost, making it complete for an agent to decide when and how to invoke the tool.
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?
The input schema already provides descriptions for both parameters (100% coverage), so the baseline is 3. The description adds value by explaining the code format in more detail (6-10 digits, spaces or dots allowed), providing an example code, and specifying the default language. This goes beyond the 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 clearly states that the tool returns expert-verified import duty and Italian import VAT for EU HS/CN codes. It distinguishes itself from siblings by focusing on tariff lookup and landed cost estimation, with specific mention of third-country duty and deep links to official TARIC page.
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 description explicitly says 'Use it to estimate landed cost or confirm the duty on a classified good.' It provides context on when to use (for duty/VAT information) and includes a note on rate changes. However, it does not explicitly mention when not to use or compare with sibling tools like classify_product or check_restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_catalogAInspect
FREE. Directory of everything CustomsWise can answer, and how much expert-verified content is available right now. Returns, per category — classification support, import duty & VAT, restrictions/sanctions, preferential origin, special procedures, and the natural-language FAQ — the count of verified entries, the tool that serves it and its price, plus supported languages (en/it). Call this FIRST to discover the paid tools and confirm verified content exists before spending. All answers are reviewed by a licensed customs professional.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the free nature, the returned data (counts per category, tool name/price, languages), and that answer are verified by professionals. It does not mention any side effects, but given the read-only nature, this is sufficient.
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 description is front-loaded with key information (FREE, directory) and is efficient. It could be slightly shorter, but every sentence adds value.
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 tool has no input parameters and no output schema. The description fully explains what will be returned (counts per category, tool, price, languages) and provides usage context. It is complete for an agent to understand and invoke correctly.
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?
The tool has no parameters, so the baseline is 4. The description adds meaning by explaining what the tool returns in detail, which goes beyond the empty 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 clearly states the tool is a free directory of everything CustomsWise can answer, returning counts per category. It distinguishes from sibling tools by advising to call this first to discover paid tools, which differentiates it from the other tools that provide specific answers.
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?
Explicitly says 'Call this FIRST to discover the paid tools and confirm verified content exists before spending.' This provides clear when-to-use guidance and implies it is a prerequisite for other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!