Skip to main content
Glama

get_tariff_history

Read-onlyIdempotent

Every reading of the duty on one Israeli tariff line, with its dates and the gazette issue and page that set it. A temporary version overrides a permanent one while it applies; suppressions list windows in which permanent versions are hidden. HS tariff code: "07.10.210000", "0710210000" or the old 8-digit "07102100". Israel customs import duty read from the official gazette, by code only (no search by product name). Amounts are in ILS. A duty of kind ending in _bounded, or with a min or max, has a floor or cap (for example 12% but not less than 1.27 ILS/kg): a caller that ignores min and max will compute the wrong duty. purchase_tax and surcharge are the table's raw cells, not parsed. VAT is not included. Free trade agreement (preferential) rates are NOT included in the general-duty reading (preferential_rates_included is false); agreement_tags only names agreements mentioned on the line. status is "verified" when confidence is "high". An origin answer with a source-reviewed preferential option has status "options_only" (see get_tariff_line). Otherwise it is "needs_review" when confidence is "low" (review_reasons is non-empty): some gazette instruction touching the line could not be applied, the duty text could not be parsed, a check digit failed, or an annual amount reading needs its next update. annual_update_required means the annual general-duty reading has passed its verification year. A year-end valid_to before that held continuation is a source verification horizon, not a statutory expiry of the code or duty. The held continuation remains found:true; no earlier rate is substituted. For a general-rate needs_review line duty, purchase_tax and surcharge are null and the reading we have is in unverified_reading: do not rely on it, check the gazette issue and page in source. needs_review answers are not charged; a history containing any needs_review version is not charged. For get_tariff_history status and unverified_reading are on each element of versions, not on the top-level object. found:false NEVER means the duty is zero (a fully exempt line is found:true with duty.kind "free"): not_found.reason says whether the code is not in the tariff, is not yet in force, has ended, or has no applicable version on that date. Renumbering: replaced_by (for an ended code) and replaces (for a new code) list the other code(s), the date and the gazette issue and page, exactly as the gazette states them; kind is one_to_one, split (one old code, several new), merge (several old codes, one new) or group (a whole subtree was rewritten: the old code is replaced by that group of codes, not equal to any one of them). An ended code with no replaced_by has no successor stated in the gazette (not_found.successor says so); none is guessed. A suppression window means a temporary instruction stands in for the permanent codes, named in temporarily_replaced_by. The data runs through gazette issue data_through_issue, and history starts on 2017-01-01. Not legal or customs advice.

Input Schema

NameRequiredDescriptionDefault
codeYesHS tariff code: "07.10.210000", "0710210000" or the old 8-digit "07102100".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only cover read-only/idempotent/closed-world, and the description adds substantial behavior beyond them: found:false never means zero duty, needs_review histories are not charged, valid_to at year-end is a verification horizon rather than statutory expiry, and min/max floors or caps must be applied or the duty is computed wrong. It also discloses renumbering kinds and suppression-window semantics.

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 core purpose, code format and the most consequential warnings (min/max, found:false, status semantics) are front-loaded, and with no output schema most of the detail earns its place. It is still a single dense block of many clauses that would read better segmented, and some sentences restate the same status logic twice.

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

Completeness5/5

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

With no output schema, the description carries the full burden and does so: it explains versions, status values, unverified_reading, replaced_by/replaces kinds, temporarily_replaced_by, data_through_issue and not_found.reason. An agent can interpret the response without guessing.

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?

There is a single parameter at 100% schema description coverage, so the schema already documents the code format and the description's duplicated examples ('07.10.210000', '0710210000', old 8-digit) add nothing new. Baseline 3 applies since the schema does the work.

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 opening sentence states a specific resource and scope: every duty reading for one Israeli tariff line, with dates, gazette issue and page. It differentiates from get_tariff_line only indirectly (via the note that status/unverified_reading live on each element of versions here rather than at top level), so the sibling distinction is inferable but not stated outright.

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

Usage Guidelines4/5

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

Gives a concrete usage constraint — lookup by code only, no product-name search — plus accepted code formats and the 2017-01-01 history floor. It never explicitly says 'use get_tariff_line for the current rate, this for the historical series', so the primary routing decision is left implicit.

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