Skip to main content
Glama

出口单 chukoudan

出口退税率查询

lookup_refund_rate
Read-onlyIdempotent

查询一个海关编码(HS 编码、商品编码,8 位或 10 位,可带点)在出口退税率文库中的出口退税率(退税率、征税率),用于“帮我查一下海关编码 … 的出口退税率”这类问题。返回该编码的各个时期,并标出适用的一期:给出 export_date(报关单出口日期,不是开票日期)就按那一天;没给就按今天(北京时间),回答里的 lookup.in_force_on 写明用的是哪一天。用户问“现在”“今天”时不要填 export_date,绝不要自己猜今天的日期;回答时说明是按哪一天标出的。编码不在文库中时返回 found: false 和相近编码,绝不编造税率。本站非官方渠道,仅供参考,以官方公布为准,请把答案里的 notes 一并转告用户。 Look up the export VAT refund rate (出口退税率, 退税率) of ONE customs / HS code (海关编码, 商品编码; 8 or 10 digits, dots allowed, e.g. 8506101110) in the 出口退税率文库. Use it for "帮我查一下海关编码 … 的出口退税率" / "what is the export refund rate of HS code …". Returns every period of the code (refund rate, levy rate 征税率, from, to) and the period in force on one day: export_date when given, otherwise today by the Beijing calendar (lookup.in_force_on names the day). The rate that counts is the one on the export date of the customs declaration (报关单出口日期), not the invoice date: for “now” or “today” leave export_date out and never guess today’s date; say in your reply which day the period was marked for. An unknown code answers found: false with nearby codes, never a rate. Reference data from this site, not the official channel; the official publication prevails. Pass on the notes in the answer. 结果仅供计算参考,不是税务、法律或投资意见;回答时请带上返回的说明和来源行。 / The result is for calculation and reference only, not tax, legal or investment advice; when you answer, pass on the returned notice and source line.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "lookup_refund_rate"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYes海关编码(HS 编码),8 位或 10 位,可带点或空格,例如 8506101110。 The customs code, 8 or 10 digits (dots and spaces allowed), e.g. 8506101110.
export_dateNo报关单上的出口日期(不是开票日期),格式 YYYY-MM-DD;不填则按今天(北京时间)标出适用的一期。用户问“现在”就不填,绝不要自己猜今天的日期。 The export date on the customs declaration, YYYY-MM-DD (not the invoice date). Optional: without it the period in force today (Beijing calendar) is marked; leave it out for “now” and never guess today’s date.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantive behavior: it returns every period and marks the one in force, names lookup.in_force_on, returns found: false with nearby codes for unknown codes, forbids fabricating a rate, and requires carrying forward the notes/source line and the non-official disclaimer. This is exactly the kind of context annotations cannot supply.

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

Conciseness3/5

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

The key constraint (which day the period is marked for) is front-loaded, which is good, but the text is very long and the disclaimer ('not official, official prevails', 'pass on the notes') is repeated three times across the Chinese and English halves. The bilingual duplication is defensible for a CJK tool, yet the disclaimer repetition is wasted length.

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?

No output schema exists, so the description must explain return values — and it does: every period with refund rate, levy rate, from/to, the in-force period, lookup.in_force_on, and the found: false + nearby-codes shape for misses. There is nothing an agent needs in order to call this correctly and explain the result that is missing.

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 100%, so both parameters are already documented in the schema — including that export_date is the customs declaration date and not the invoice date, and the 'never guess today' rule. The description restates the same guidance rather than adding new syntax or constraints, so it earns the baseline 3 rather than more.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/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 the export VAT refund rate of ONE customs/HS code in the 出口退税率文库, with the input format (8 or 10 digits, dots allowed) spelled out. The bilingual phrasing and the example query ("帮我查一下海关编码 … 的出口退税率") make it clearly distinguishable from siblings like tuishui or get_dataset.

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 concrete use conditions: use it for "what is the export refund rate of HS code …" questions, and it explains the export_date branching (provide it for a specific declaration date, omit it for "now"/"today"). It does not, however, name an alternative sibling or state when NOT to use it — for example, how it differs from tuishui is left to inference.

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