Skip to main content
Glama

Look up a tariff

lookup_tariff

Access: API key, OAuth, or x402 payment when offered. Look up a US HTS classification with bounded CBP CROSS ruling evidence and, when origin is supplied, its supported duty layers, warnings, coverage, and provenance.

Input Schema

NameRequiredDescriptionDefault
htsYesUS HTS code, dotted or undotted
viewNocompact projects the same answer into components, claims and coverage; legacy (the default) is the full response.
as_ofNoISO date in YYYY-MM-DD form
factsNoFacts the entry declares (for example usmca_qualifying, manufacture_year, us_content_share). Structured chapter98 declarations carry valuation, facts, components and evidence. Structured chapter99.exclusion declarations carry a source clause, individual product facts and reference-only documents for the governing 9903.88.69 (note 20(vvv)) or 9903.88.70 (note 20(www)) claim. The section_338_canada declaration carries importation_time and direct_to_consumption_container for the Proclamations 11061–11063 import exclusion (a listed Canadian line imported on or after 12:01 a.m. Eastern time on September 29, 2026 returns error import_prohibited with the determination and no duty total), and the U.S. note 51 facts personal_use_accompanied_baggage, us_content_approved and import_adjustment_offset. general_note_6_eligible decides the note 51(d) civil aircraft exemption from the Section 338 duty. A USMCA claim does not remove the Section 338 duty. The preference declaration (claimed, program, origin_qualified, evidence_on_file, quota_available) claims special tariff treatment on calculate_duty: the preferential rate applies only when all are declared, and the answer is marked as based on the importer's declaration. Unknown keys are rejected by the API. Documentary references are not verified approval.
matchNobest
claimsNoChapter 98/99 headings the entry claims. Listed but unimplemented treatments return an explicit entry-claim review response, not a duty exemption or total.
detailNoOptional detail with view compact. predicates adds every resolved treatment with its condition tree (satisfied, not satisfied or unknown leaves on canonical facts), its relationship (additive, alternative with a shared group_id, or replaces) and the programs that expose trees.
countryNoISO-2 country code of origin

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

No annotations, so the description carries the full burden. It does useful work by naming accepted auth modes (API key, OAuth, x402) and describing the shape of the answer (ruling evidence, duty layers, warnings, coverage, provenance). It says nothing about the read-only nature of the call, error/failure behavior, or how much evidence is 'bounded'.

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

Conciseness4/5

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

Two sentences with no padding, but the leading 'Access: API key, OAuth, or x402 payment' clause sits ahead of the actual purpose, delaying front-loading of what the tool does. Beyond that ordering, every clause earns its place.

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?

For an 8-parameter tool with a deeply nested facts object and no output schema, the description does well to say the response includes duty layers, warnings, coverage and provenance. But it leaves the agent without guidance on the facts declaration surface or on how its duty output relates to calculate_duty, so a substantial complexity gap remains.

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 88%, so the schema already documents hts, view, as_of, country, match, claims, detail and facts in depth. The description adds only the origin-supplied conditional, and it never touches the very complex facts declaration semantics, which the schema alone carries.

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 and resource ('Look up a US HTS classification') plus what accompanies it (CBP CROSS ruling evidence, duty layers, warnings). It doesn't differentiate from close siblings like calculate_duty, compare_tariff_codes or search_tariffs, so an agent must infer the boundary from the duty-layer wording alone.

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 only conditional guidance is 'when origin is supplied', which explains a branch of behavior rather than when to pick this tool over alternatives. With near-identical siblings such as compare_tariff_codes and calculate_duty, some explicit routing ('use X to find a code, use this once you have one') would be needed for a 4 or 5.

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