Jecfa

JECFA — 食品添加剂安全评估（WHO/FAO）

FAO/WHO 食品添加剂联合专家委员会的安全评估：每日可接受摄入量（ADI）、委员会的结论、膳食暴露结果，以及作为依据的会议报告和毒理学专著——涵盖食品添加剂、香料、食品污染物和兽药残留。

属于 Pipeworx — 一个将 AI Agent 连接到 1882+ 个实时数据源的 MCP 网关。这是一个独立的非官方集成，与上游提供方无关联、未获其认可，也非由其发布。

JECFA 是监管机构在设定限值时引用 ADI 的机构。此工具包回答的是“这种物质是否经过评估，委员会认为可接受的摄入量是多少”，而不是“这种物质是否获准用于欧盟的酸奶”——后者是 Codex GSFA / 国家监管机构的问题。

工具

工具	可回答的问题
jecfa_search	按物质名称、CAS 编号或 INS/E-number 查询 → ADI、CAS、功能类别、化学品 ID
jecfa_chemical	单个 ID 的完整记录：同义词、INS，以及 JECFA 开展过的每项评估——年份、ADI、结论、摄入量结果、会议编号、TRS 报告、毒理学专著
jecfa_by_functional_class	查询某一类别（甜味剂、防腐剂、着色剂……）或四个组别之一中的所有物质
jecfa_functional_classes	71 类术语表，便于调用方了解应传入的准确名称
jecfa_by_number	根据 FEMA 或 JECFA 物质编号查询
jecfa_recent_evaluations	查看委员会最近评估过的内容

覆盖范围

3,245 种物质：777 种食品添加剂、2,289 种香料、115 种兽药、64 种食品污染物。评估涵盖从委员会最早的会议至今——例如，阿斯巴甜的评估记录从 1981 年一直延续到第 96 次会议的 2023 年重新评估。

认证

无需认证。无需密钥、无需注册，也没有配额。

数据来源

• 数据库：https://apps.who.int/food-additives-contaminants-jecfa-database/
• 关于 JECFA：https://www.fao.org/food-safety/scientific-advice/jecfa/en/

该数据库没有文档化的 API。此工具包调用的端点用于支持网站自身的 Kendo 网格，是从页面中读取的。这些端点没有文档，也没有版本控制，因此可能在不另行通知的情况下发生变化；工具包自身的注意事项注释（位于 src/index.ts 顶部）记录了经实时验证的数据结构。

注意事项

上游有 5 种行为，若照单全收，会让结果看似可信，实则错误。此工具包已对所有这些情况进行防护，但如果你要扩展它，就需要留意：

1. /SearchChemical/ByPartialName 会伪造一行结果。 它会将你的查询字符串作为结果添加到最前面，Id: 0，ADI 为空——这是 UI 提供的“搜索此字面文本”功能。若原样传递，就会凭空捏造一种从未经过评估的物质。此工具包会删除所有 Id <= 0 的行。

2. 即使按 CAS 搜索，同一端点也会返回 CAS_NO: null。 搜索 50-70-4 会正确找到 SORBITOL，但随后将其 CAS 报告为 null。只有 /ChemicalData/GetBy/par/ 会返回已填充记录，而 jecfa_search 实际调用的正是该端点。

3. /ChemicalData/GetBy/fir/ 需要的是字符，而不是 ID。 它的配套端点 /FilterData/Get/FirstCharacter 会返回 {"Id": 65, "Name": "A"}；传入 65 会返回 HTTP 500，传入 A 则会返回 501 行。

4. INS/E 编号完全无法搜索。 ByPartialName/951 会返回 0 行——INS 编号只存在于服务器渲染的详情页中。因此，jecfa_search 会通过 INS_INDEX 查找它们；该索引是在构建时从全部 777 个添加剂详情页中提取的，其中 486 个页面包含 INS 编号。会议新增物质后，使用 node mcps/jecfa/scripts/build-ins-index.mjs 重新生成。

5. 详情页中的引用行使用了与其他字段不同的 CSS 类。 ADI、评论、摄入量和会议内容在 col-sm-8 中渲染；报告、毒理学专论和规格行则在 col-**md**-8 中渲染，并将文本包裹在 <a> 中。只匹配 col-sm-8 的解析器会对这三项全部返回 null，让人以为“JECFA 未发布该评估的报告”，而实际上 TRS PDF 的链接就在页面上。每条引用的 url 都来自上游，通常是 iris.who.int 上的直接 PDF 链接。

纯 INS 编号确实存在歧义——INS 160 代表 19 种分别经过评估的胡萝卜素——因此，索引会将每个键映射到一个列表，而 jecfa_search 会返回所有候选项并标记 ambiguous: true，而非擅自选择一个。上游对亚型的写法并不一致（既有 100(i)，也有 100i），因此键会规范化为字母数字字符；生成器和工具包必须始终使用相同的规范化方式，否则每次查找都会悄无声息地失败。

快速开始

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

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

此端点实际提供的内容

https://gateway.pipeworx.io/jecfa/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 都会访问同一个网关和相同的 1882+ 个数据源。唯一的区别在于，直接列出的是哪个工具包的工具；无论使用哪个 URL，ask_pipeworx 都能访问所有工具。

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

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

首次调用无需账号。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/jecfa_search。查找工具：使用 {"query":"..."} 调用 POST https://gateway.pipeworx.io/v1/tools/search_packs。

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

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

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

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

npx -y @pipeworx/mcp-jecfa

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

使用 ask_pipeworx

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

ask_pipeworx({ question: "your question about Jecfa data" })

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT