Skip to main content
Glama

出口单 chukoudan

运费估算

freight
Read-onlyIdempotent

运费估算(Freight estimate):海运整柜、拼箱、空运和快递:你填运价,算出这批货的运费。 Sea FCL, LCL, air and express: you enter the rate, it works out the freight for this shipment. 读取数据 / Reads: divisors@current. 输入为精确的十进制字符串 / Inputs are exact decimal strings. 用户没有给的数字和日期不要自己编:必填的先问用户,选填的不填。 / Never make up a figure or a date the user did not give: ask for a required one, leave an optional one out. 回复时引用回答里的 provenance.source_line / Quote provenance.source_line in your reply. 结果仅供计算参考,不是税务、法律或投资意见;回答时请带上返回的说明和来源行。 / 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.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mode": "lcl",
      "rate": "100",
      "width": "40",
      "extras": [
        {
          "name": "订舱费",
          "amount": "50"
        },
        {
          "name": "文件费",
          "amount": "30"
        }
      ],
      "height": "50",
      "length": "60",
      "cartons": "40",
      "currency": "USD",
      "containers": "2",
      "grossWeight": "18",
      "containerType": "40hq"
    },
    "name": "freight"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeYes运输方式。可选值:fcl = 海运整柜;lcl = 海运拼箱;air = 空运;express = 快递 / Mode. options: fcl = Sea FCL; lcl = Sea LCL; air = Air; express = Express
rateYes运价 / Rate
widthNo宽(cm) / Width (cm)
extrasNo附加费 / Extra charges
heightNo高(cm) / Height (cm)
lengthNo长(cm) / Length (cm)
cartonsNo箱数 / Cartons
currencyNo币种 / Currency
containersNo柜数 / Containers
grossWeightNo每箱毛重(kg) / Gross weight per carton (kg)
containerTypeNo柜型。可选值:20gp = 20GP;40gp = 40GP;40hq = 40HQ / Container type. options: 20gp = 20GP; 40gp = 40GP; 40hq = 40HQ

Output Schema

NameRequiredDescriptionDefault
toolYes
linksYes
stepsYes
outputsYes
warningsYes
normalizedNo
provenanceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / description
      Previous value: -"数字最好写成字符串(十进制,如 \"12.5\"),JSON 数字也行;千位逗号只认 1,234,567 这种写法,小数点用英文句点,不要带货币符号或单位。币种可写 USD、usd 或 美元,单位可写 cm 或 厘米,日期可写 2026-05-01、2026/05/01 或 20260501。读不准的一律拒绝并说明原因,绝不猜;回答里的 normalized 列出实际采用的值。 / Figures are best sent as decimal strings such as \"12.5\"; a JSON number is accepted too. A thousands comma only as 1,234,567; the decimal point is a dot; no currency symbols or units. A currency may be USD, usd or 美元, a unit cm or 厘米, a date 2026-05-01, 2026/05/01 or 20260501. Anything that cannot be read in exactly one way is refused with a reason, never guessed; `normalized` in the answer lists what was used."New value: +"数字最好写成字符串(十进制,如 \"12.5\"),JSON 数字也行;千位逗号只认 1,234,567 这种写法,小数点用英文句点,不要带货币符号或单位。币种可写 USD、usd 或 美元,单位可写 cm 或 厘米,日期可写 2026-05-01、2026/05/01 或 20260501。读不准的一律拒绝并说明原因,绝不猜;回答里的 normalized 列出实际采用的值。 / Figures should be sent as decimal strings such as \"12.5\"; a JSON number is accepted too. A thousands comma only as 1,234,567; the decimal point is a dot; no currency symbols or units. A currency may be USD, usd or 美元, a unit cm or 厘米, a date 2026-05-01, 2026/05/01 or 20260501. Anything that cannot be read in exactly one way is refused with a reason, never guessed; `normalized` in the answer lists what was used."
  2. Added

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower, and the description still adds real behavior: it reads divisors@current, refuses any input that cannot be read in exactly one way rather than guessing, echoes the chosen values in `normalized`, and requires passing on the notice and provenance.source_line. The disclaimer ('calculation and reference only, not tax, legal or investment advice') is behavior-shaping context an agent cannot get from annotations.

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?

Purpose is front-loaded, which is good, but every sentence is duplicated in Chinese and English, roughly doubling length without adding information for a bilingual reader. The guardrail and disclaimer clauses are individually justified, yet the packaging is dense and repetitive rather than tight.

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?

An output schema exists, so return values need not be explained, and annotations cover safety. What is missing for an 11-parameter tool is mode-dependent input requirements — e.g. that FCL wants containerType/containers while LCL/air/express want cartons and dimensions — and the description never says which fields matter per mode, leaving the agent to discover this from the schema example.

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 coverage is 100%, so the schema already documents all 11 parameters including the mode and containerType enums. The description's format rules (decimal strings, 1,234,567 commas, dot decimal point, USD/usd/美元, cm/厘米, several date formats) largely restate the schema's top-level description, so this is baseline value rather than new meaning.

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+resource (运费估算 / 'works out the freight for this shipment') and enumerates the four supported modes (FCL, LCL, air, express), which is enough to identify the tool. It never contrasts itself with look-alike siblings such as cbm, container-load or make_quote, so the agent must infer the boundary.

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?

'你填运价,算出这批货的运费' gives an implied usage model: the caller supplies the rate and the tool only computes. The instruction to ask for missing required inputs and omit optional ones is useful operating guidance, but there is no explicit when-to-use/when-not-to-use versus sibling calculators, which is the main gap.

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