Israeli customs duty by tariff code and origin country, read from the official gazette (Reshumot). Cites the gazette issue and page, flags what it is unsure of as needs_review and does not charge for those answers. Pay per call via x402 (USDC on Base).
Scored across 2 tools
The names distinguish a point-in-time lookup (get_tariff_line) from a full version history (get_tariff_history), but the descriptions are almost entirely copy-pasted, including a history tool that says 'see get_tariff_line' and discusses line-specific status semantics. An agent must rely on the tool names, not the descriptions, to choose between them, and the near-identical payloads invite misselection.
Both tools follow the same get_tariff_<noun> pattern, clearly parallel and predictable. No mixed conventions or vague verbs.
Two read-only tools is thin even for a narrow domain; there is no way to validate or discover codes, only to query a known code. Each tool earns its place, but the surface is borderline minimal.
Current-rate and historical reads are covered, including origin-aware general rates and renumbering metadata, so core lookups work. However, there is no code search/validation, no listing of codes, and no bulk or coverage-status lookup, leaving agents with dead ends when they do not already know a code.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | HS tariff code: "07.10.210000", "0710210000" or the old 8-digit "07102100". |
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.
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.
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.
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.
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.
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.
Look up the duty on one Israeli tariff line on a date. 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. date is YYYY-MM-DD (default today in Israel). origin_country is the goods' ISO 3166-1 alpha-2 country of origin, not the shipping country. Origin-specific rates and quotas are conditional on eligibility and documentation; the country alone does not establish entitlement. The general_rate is the separate general reading; country_treatment lists sourced options and import levies. An origin-aware answer includes general_rate only when that reading needs review; request without origin for a verified general rate. conditional_duty_scenarios are hypothetical customs-duty components under stated assumptions, not payable or final duties; other measures remain separate. Scenarios require a country-scoped preference rule that requires qualifying origin; wildcard and no-origin rules remain options only. Canada preference rules carry an audit field marked withhold, so they remain options and do not produce scenarios. A matching preference coverage row with complete other than true or malformed/nonempty review_reasons suppresses a scenario and adds preference_coverage_unusable; missing coverage remains an unresolved assumption. An origin answer is charged only when the line is verified and it returns at least one source-reviewed preferential option with no overlapping or unverified preference, quota or levy rule, no failed quota audit and no unusable coverage (status "options_only"; confidence high means the options are source-reviewed, not that the shipment qualifies); it never asserts entitlement, quotas, levies or a final shipment duty, whose gaps stay in review_reasons. An origin answer with no such option is status needs_review and is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | HS tariff code: "07.10.210000", "0710210000" or the old 8-digit "07102100". | |
| date | No | YYYY-MM-DD, default today in Asia/Jerusalem | |
| origin_country | No | Goods' country of origin, ISO 3166-1 alpha-2 (e.g. US), not shipping country |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-open-world behavior, and the description adds extensive operational context: status meanings, found:false semantics, unverified readings, renumbering, charging behavior, and origin limitations. There is no contradiction with the annotations.
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 purpose is front-loaded, but the description is a very long dense block with repeated status and origin-answer explanations. Much of the detail is relevant, but it is not structured for scanning and contains significant redundancy, making it poorly concise.
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 absence of an output schema and the complexity of tariff, origin, status, and charging semantics, the description is highly complete. It explains the key return fields, edge cases, and when results are or are not reliable or charged.
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 schema already documents all three parameters. The description still adds meaningful semantics for origin_country, especially that origin-specific rates are conditional and that origin answers do not establish entitlement, though code and date details largely repeat 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 opening sentence gives a specific verb and resource: look up the duty on one Israeli tariff line on a date. It also clarifies code-only lookup and no product-name search, which distinguishes it from a search tool and from the sibling history tool.
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 gives clear context for using code-only lookup and for when origin_country should or should not be supplied, such as requesting without origin for a verified general rate. It references get_tariff_history but does not explicitly route the agent between the two tools with a clear condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_tariff_historyget_tariff_line
Add one secure layer between your agents and this server.