Codex Mrl

Codex MRL — 最大残留限量（FAO/WHO Codex Alimentarius）

由 Codex Alimentarius 委员会通过的、国际公认的农药残留和兽药残留法定上限。Codex MRL 是食品贸易的参考标准——货物在边境遭拒，通常就是因为超出其中某项限量。

这是 Pipeworx 的一部分——一个将 AI agents 连接到 1875+ 个实时数据源的 MCP 网关。这是一项独立、非官方的集成，与上游提供方无关，未经其认可，也并非由其发布。

这是食品化学中关于许可的一面。关于安全性的一面——即限量背后的每日可接受摄入量和毒理学评估——请参阅 jecfa 套件；此处的兽药记录包含 jecfa_chemical_id，可用于关联两者。

工具

工具	可查询内容
codex_pesticide_search	按名称查找农药 → ID
codex_pesticide_mrls	查询一种农药 → ADI、残留定义及其在每种商品中的限量
codex_commodity_search	按名称查找食品商品 → ID
codex_commodity_mrls	查询一种食品 → 适用于该食品的所有农药限量
codex_vetdrug_search	列出或搜索 85 种兽药
codex_vetdrug_mrls	查询一种药物 → 按物种和组织划分的限量，以及其 JECFA 交叉引用

覆盖范围

涵盖 240 种农药和 85 种兽药，限量支持双向索引（按物质和食品查询）。农药限量包含其通过年份、JMPR 评估年份和步骤代码——CXL 表示已通过的 Codex 限量；数字步骤表示限量仍在 8 步通过程序中，尚无约束力。

身份验证

无需身份验证。无需密钥、注册或配额。

数据来源

• 农药残留：https://www.fao.org/fao-who-codexalimentarius/codex-texts/dbs/pestres/en/
• 兽药残留：https://www.fao.org/fao-who-codexalimentarius/codex-texts/dbs/vetdrugs/en/

没有公开记录的 API。这些端点为网站自有的 jQuery 页面提供支持，因此未公开文档且没有版本控制，可能在不事先通知的情况下发生变化。

此处未涵盖的内容：GSFA

Codex 的第三个数据库——GSFA，即《食品添加剂通用标准》，用于说明某种添加剂是否允许用于特定食品以及允许的用量——不在涵盖范围内，因为无法从服务端访问。fao.org/gsfaonline 有 Cloudflare JavaScript 验证挑战，所有非浏览器客户端（包括请求该标准自己的 PDF）都会收到 403。这不是 IP 信誉封锁，因此出口代理无济于事：SharePoint 镜像需要 FAO SSO，网站自有的 sh-proxy 返回相同的 403，FAO 的 OpenKnowledge 存储库 API 也拒绝访问。要访问 GSFA，需要通过浏览器驱动抓取，这是另一种类型的项目。

注意事项

如果相信上游的行为，会有 4 种情况导致错误答案。这里都已处理，但如果你要扩展功能，仍需留意：

1. 约有 10% 的农药记录不是有效的 JSON。 商品名称的字符串字面量中包含原始制表符，例如 "Dry peas \t\t(subgroup)"。RFC 8259 禁止字符串中出现未转义的 U+0000–U+001F，因此 JSON.parse 会抛出 Bad control character in string literal，导致无法访问该记录。抽查 30 条记录时发现有 3 条受影响，其中包括 glyphosate。sanitizeJson() 只会转义字符串内部的控制字符，并跟踪是否处于字符串状态，因为标记之间的制表符和换行符是合法空白，必须保持原样。

2. 搜索没有匹配结果时，返回的是搜索表单，而不是空列表。 搜索一个不存在的商品时，会得到描述搜索界面的 {forms: {...}}。查找 commodities 却找不到的代码，很容易报告“没有适用限量”——这是个自信但错误的答案。isEmptySearchResponse() 可区分这两种响应结构。

3. 未知 ID 返回 HTTP 500，而不是 404。 因此，错误 ID 与上游服务宕机无法区分。codex_pesticide_mrls 和 codex_vetdrug_mrls 都会先在目录中解析参数，绝不会使用未见过的 ID 查询详情端点。

4. 缺失与零并不相同，而且两者都有意义。

   • 限量为零是一项发现：由于 Codex 认定某种物质没有安全的残留水平，因此不为其设定任何 MRL，chloramphenicol 返回 count: 0。将其报告为“没有数据”会颠倒其含义。
   • 缺少某种物质同样是一项发现：此数据库只列出当前已采纳的限量；撤销限量时，Codex 会移除相应条目。chlorpyrifos 缺失正是这个原因——已通过上游自身的搜索结果确认，搜索同样没有返回任何内容。因此，缺失并不能证明某种物质从未经过评估，no_match 提示也说明了这一点。

快速开始

将其添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "codex-mrl": {
      "url": "https://gateway.pipeworx.io/codex-mrl/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/codex-mrl/mcp 上的 tools/list 会返回上表中的工具，以及 Pipeworx 的共享元工具——ask_pipeworx、discover_tools、search_within、remember/recall 和网关范围内的其他工具。因此，你看到的工具数量会多于此表所列：目前，单个工具包端点除了列出该工具包自身的工具，还会列出约 30 个共享工具。连接的 initialize 响应会说明其确切范围，也是当天情况下最权威的答案。

这是有意为之，并非意外的多路复用。元工具可让受限连接通过 ask_pipeworx 跨整个目录进行路由，从而回答此工具包未涵盖的问题，无需再添加第二个 MCP 服务。目前无法挂载不含这些元工具的工具包端点；如果额外的架构定义占用的上下文多于路由功能带来的收益，请连接一次完整网关，而不是连接多个工具包端点。

也可以连接完整的 Pipeworx 网关，直接获取所有工具包的工具列表，而不仅仅是此工具包的工具：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都连接到同一网关和相同的 1875+ 个数据源。唯一的区别是直接列出哪个工具包的工具；无论连接哪一个，ask_pipeworx 都能访问所有工具包。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/codex_pesticide_search \
  -H 'Content-Type: application/json' \
  -d '{"query":"glyphosate"}'

首次调用无需账户。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/codex_pesticide_search。查找工具包：使用 {"query":"..."} 向 https://gateway.pipeworx.io/v1/tools/search_packs 发送 POST 请求。

独立运行（无需网关账户）

此软件包也可作为本地 stdio MCP 服务运行，无需 Pipeworx 账户，也无需经过网关往返：

{
  "mcpServers": {
    "codex-mrl": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-codex-mrl"]
    }
  }
}

也可以直接运行，确认它能正常启动：

npx -y @pipeworx/mcp-codex-mrl

它通过 stdin/stdout 使用 MCP 通信，并针对仅限此软件包的工具响应 initialize/tools/list/tools/call——不包含上方网关连接所添加的任何共享元工具。相同的源代码，相同的工具，无需 ask_pipeworx 路由。

使用 ask_pipeworx

你也可以用通俗的英语提问，而不是直接调用工具——这既适用于上方的软件包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Codex Mrl data" })

网关会选择合适的工具并自动填写参数。

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT