Skip to main content
Glama

USTariffRates

by com.ustariffrates
OverviewDiscussionsAdmin

Replay a historical tariff stack

replay_tariff

Access: API key, OAuth, or x402 payment when offered. Compare a supported historical tariff stack with the current stack while reporting archive coverage explicitly.

Input Schema

NameRequiredDescriptionDefault
htsYesUS HTS code, dotted or undotted
as_ofYesISO 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.
matchNoexact
claimsNoChapter 98/99 headings the entry claims. Listed but unimplemented treatments return an explicit entry-claim review response, not a duty exemption or total.
countryYesISO-2 country code of origin

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses authentication modes and that archive coverage is reported explicitly, but it does not state whether the operation is read-only, how incomplete archive coverage affects results, or what the response shape contains.

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?

The description is only two short sentences and avoids repetition. However, it leads with access mechanics before the core purpose, which is slightly less front-loaded than ideal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex, with six parameters, required historical inputs, nested facts structures, and no output schema. The description does not explain return values or how archive coverage, match mode, or claims affect invocation, leaving significant gaps for an agent despite the rich input schema.

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 high at 83%, so the schema already documents most parameters. The description adds no specific meaning for hts, country, as_of, match, claims, or facts, so the baseline of 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?

The description states a specific action and resource: comparing a supported historical tariff stack with the current stack while reporting archive coverage. That is clear enough to distinguish it from lookup or calculation tools, though it does not explicitly name or differentiate against siblings like compare_tariff_codes or calculate_duty.

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

Usage Guidelines2/5

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

It gives no explicit guidance on when to use this tool versus alternatives. The phrase 'historical tariff stack' implies a use case, but there are no conditions, exclusions, or named alternatives to route the agent between replay_tariff, compare_tariff_codes, and calculate_duty.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All USTariffRates toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources