货运报价与轨迹查询的 MCP 服务器

物流 MCP 服务器是做什么的

面向货运的 MCP 服务器，把报价和轨迹查询暴露成带类型的工具，让助手直接发起一次查询，而不是由人去打开费率后台。MCP（Model Context Protocol）是这层接口规范：它定义了 Claude、ChatGPT、Codex、Cursor、VS Code 这类客户端如何发现服务器提供哪些工具、每个工具接受什么参数、返回什么结构。落到物流上，它把「这单要多少钱」和「货到哪了」这两件反复出现的杂事变成了函数调用。

下面讲清楚每类工具应该长什么样、不同运输方式的报价差别在哪、以及怎么接一个能用的服务器。示例用的是公开的 JTLGO Commerce MCP 连接器，它报的是中国出口线路，并提供轨迹查询。

一个货运 MCP 服务器应该暴露哪些工具

好用的服务器都很小。四到六个定义清楚的工具，胜过二十个含糊的，因为客户端只能靠描述来做选择。

工具	用途	典型输入	返回
quote_shipping_rates	线路与费用估算	重量、目的国、长宽高、货物类型	线路选项，含计费重与时效估计
track_shipment	包裹或订单状态	单个或多个运单号	最新轨迹节点与异常提示
search_products	确定要发什么货	关键词、平台、数量上限	候选商品及其标识
get_product_detail	报价前确认单个商品	商品 id 或链接	规格字段，含卖家已公布的重量
human_handoff	置信度不足时转人工	语言、原因	人可以接手的支持路径
get_mcp_config	验证连接	无	连接器元数据与工具清单

最后两个比看上去重要。配置工具让你能在不消耗一次报价查询的前提下证明连接器可达；显式的转人工工具，则在答案确实不确定时给助手一个去处，而不是让它自己编一个数字出来。

不同运输方式的报价，输入也不同

买家会搜「MCP server for LTL quote」「MCP server for FTL quote」，仿佛报价是同一个问题，就像把四层协议栈当成一件事那样。它不是。运输方式决定了报价工具必须要求哪些输入，而输入要得太少的工具，会给出很自信的胡话。

方式	价格由什么决定	报价工具必须要求的输入
快递小包	实重与体积重取大者	重量、完整三边、目的地、货物类型
LTL 零担	货物等级或密度，加附加服务	托盘数、尺寸、等级或密度、提送附加项
FTL 整车	线路、车型与日期	起讫点、挂车类型、提货日期
空运	按体积除数计算的计费重	毛重、尺寸、机场对、品名限制
海运 LCL / FCL	立方数，或箱型与箱量	体积或箱型、港口对、贸易术语

两个实际结论。第一，任何只要重量、不要尺寸的报价工具都是在猜，因为几乎所有方式的计费重都由体积决定。第二，目的国境内的 LTL / FTL 报价与国际出口报价是两套数据源，能做前者不等于能做后者。在把工作流搭上去之前，先确认你接的是哪一套。

JTLGO 的连接器报的是中国出口线路，也就是从中国出发的快递、空运与海运选项，计费重由你提供的尺寸算出。它不报目的国境内的整车运输。同一套报价引擎也以网页形式开放在运费预估，轨迹则在物流查询。这是刻意划定的范围，提前知道总比在 agent 循环里才发现要好。

怎么接

托管型 MCP 服务器就是一个 URL。多数客户端只需要这个，传输是基于 HTTP POST 的 JSON-RPC。

{
  "mcpServers": {
    "jtlgo": {
      "url": "https://jtlgo.com/api/mcp"
    }
  }
}

接进客户端之前想手工验证，可以先 initialize，再列工具。这个端点要求 POST，并且 Accept 头必须同时包含 JSON 与 event-stream 两种类型；直接 GET 会被刻意拒绝。

curl -X POST https://jtlgo.com/api/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

报价调用和其他工具调用没有区别。记得给尺寸，不要只给重量。

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "quote_shipping_rates",
    "arguments": {
      "weight": 12,
      "countryCode": "US",
      "length": 40,
      "width": 30,
      "height": 25,
      "goodsType": "general"
    }
  }
}

公开访问与账号访问

货运连接器通常需要两档权限，把两者混为一谈是最常见的接入错误。报价和公开轨迹这类开放工具不需要登录，因为没有属于某个账号的东西需要保护；而读取客户自己的订单、工单或工单历史就需要，OAuth 属于这一档。

JTLGO 的做法是同一个服务器两个 URL：https://jtlgo.com/api/mcp 提供六个公开工具，https://jtlgo.com/api/mcp/account 提供同样这六个再加四个账号范围的工具，客户端只在真正需要账号数据时才发起 OAuth。助手要回答某个具体客户的货件问题时选账号 URL，否则选公开 URL。两个都配没有任何好处。

信任一个货运连接器之前该检查什么

• 工具调用是否真的打到了上游？能响应 tools/list 不代表它在工作，列表通常来自静态 schema。要调一次真实工具。
• 报价工具是否强制要求尺寸？如果只接受重量，那么对轻抛货——也就是大多数消费品——它的结果一定是错的。
• 轨迹查询是否区分「暂无数据」和「查无此单」？这两者对客户意义完全不同，混为一谈会让助手给出很有把握的错误安抚。
• 有没有明确的转人工路径？限制类品名和冷门线路本来就查不出费率，正确的行为是转人工，不是外推。
• 范围是否写清楚？起运地区、覆盖的运输方式、是否包含目的国境内整车报价。

常见问题

什么是货运 MCP 服务器？

它是一个把货运报价和轨迹查询以 Model Context Protocol 暴露成可调用工具的服务，让 AI 助手可以直接请求报价或状态，而不必由人去操作费率后台。

MCP 服务器能报 LTL 和 FTL 吗？

可以，前提是它接了这两种方式的承运商报价引擎，并且要求了正确的输入：LTL 要托盘数、尺寸和货物等级，FTL 要线路、车型和提货日期。包括 JTLGO 在内的不少物流连接器覆盖的是国际出口方式而非境内整车，依赖之前先确认范围。

用物流 MCP 服务器需要 API key 吗？

公开报价和轨迹通常不需要。涉及读取某个具体客户账号的功能需要，而且应该是客户端发起的 OAuth 流程，不是往配置文件里粘一个 key。

哪些 MCP 客户端可以用？

任何支持托管 HTTP 服务器的客户端，目前包括 Claude、ChatGPT、Codex、Cursor 和 VS Code。连接器就是一个 URL，传输由客户端处理。

为什么这个端点拒绝 GET？

因为 MCP 的 HTTP 传输是基于 POST 的 JSON-RPC。用 GET 返回元数据等于多了一个未写进文档的第二接口，所以它被以 405 拒绝，而不是被非正式地支持。