Wipo Ipc

@pipeworx/wipo-ipc

国际专利分类（IPC）查询——分类符号的标题、有效性和结构分解、其下的组／小组，以及按关键词搜索分类标题。无需密钥。

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

工具

• ipc_lookup(symbol, version?) — 查询一个 IPC 符号的标题（英语／法语）、结构分解及其当前是否有效。
• ipc_children(symbol, version?) — 查询直接归属某个 IPC 符号的分类符号（例如，子类下的主组、组下的小组），并附带各自的标题。
• ipc_search(query, version?, limit?) — 搜索标题文本与关键词匹配的 IPC 符号，例如 “vaccine”。
• ipc_versions() — 查询 WIPO 当前公布的 IPC 版本日期，并标明当前（生效中）和最新（已发布，日期可能在未来）的版本。

身份验证

无需密钥。无需账户或注册；未公布速率限制。

数据来源

• 世界知识产权组织（WIPO），《国际专利分类（IPC）表》。

给接手者的说明

• IPC 不等于 CPC。 合作专利分类（由 EPO 和 USPTO 共同维护）在 IPC 的基础上细分得更精细，也是 EPO/USPTO 实际用于大多数现代专利分类的体系。即使 CPC 代码看起来相似，也不能与 IPC 代码互换，例如 epo-ops 或 epo-publication-server 原样返回的 CPC 代码。本工具包完全不支持 CPC——本文撰写时，Pipeworx 没有专门的 CPC 查询工具包。
• 目录为此服务列出的 OpenAPI 规范是失效的 404 链接，位于 wipo.int 上。 此处的所有操作都是通过阅读 IPCPUB 自己的前端 JavaScript 并实时探测由此得到的候选路径发现的——没有已发布的规范可供核对。
• 符号格式： 人们会写成 “A61K 31/00” 或 “A01N”；Web 服务本身只接受固定的 4 字符小类格式（“A01N”），或固定的 14 字符格式，其中主组补零至 4 位、分组补零至 6 位（“A61K” + “0031” + “000000”）。转换只在 parseSymbol() 中进行——长度为 1 或 3 字符的不完整符号（仅有部或类）要么返回 404，要么在上游自己的有效性端点上返回 500（具体来说，3 字符的类级符号会返回 500）；这里不会尝试这类请求。
• 标题查询确实很慢，而且在大型小类中偶尔会失败——这是上游的问题，不是缺陷。 IPCPUB 的树形导航端点（ancestors/children）会在每次请求时于服务器端渲染某个分类的完整嵌套标题树，而且不做缓存：同一次小类查询（A01N）有时测得 1.4 秒，有时则要 20.8 秒。对于异常庞大的小类——A61K（“医药制剂”），整个体系中最大的小类之一——其中的每个查询键都会稳定地在 AWS API Gateway 自身约 29.5 秒的集成超时时间处返回 504，并附带 {"message":"Endpoint request timed out"}，无论查询的是哪个具体节点（符号自身的键、其直接主组包装节点，还是小类本身）。ipc_lookup 和 ipc_children 都会将请求限制为一次 28 秒的尝试，随后降级为 title_en: null / title_fr: null，并返回普通的 title_error，而不会一直挂起——无论结果如何，valid/structure（来自另一个快速可靠的 getvalidity 端点）都不受影响。A61K 下的主组——例如 A61K 31/00——最容易触发此问题，因此实时查询其标题时发生超时并不意外；多次直接探测已确认，这是上游自身的渲染开销，并非此工具包的缺陷。
• 格式正确但虚构的符号在 getvalidity 上不会返回 404——它会返回 classification-validity: "N"（无效），而 ipc_lookup 会将其报告为 valid: false。格式确实错误的符号（部字母错误、缺少小类）会在调用上游之前被此工具包自己的解析器拒绝，并返回 found: false, reason: "invalid_format"。

快速开始

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

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

此端点实际提供的内容

https://gateway.pipeworx.io/wipo-ipc/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 都连接到同一个网关和相同的 1837+ 个数据源。唯一的区别在于，哪个工具包的工具会被直接列出；无论连接哪个端点，ask_pipeworx 都可以访问所有工具。

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

curl -X POST https://gateway.pipeworx.io/v1/tools/ipc_lookup \
  -H 'Content-Type: application/json' \
  -d '{"symbol":"A01N 1/00"}'

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

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

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

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

或者直接运行，确认服务可以启动：

npx -y @pipeworx/mcp-wipo-ipc

它通过 stdin/stdout 使用 MCP，并针对仅此工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接额外提供的任何共享元工具。来源相同，工具相同，但没有 ask_pipeworx 路由功能。

与 ask_pipeworx 搭配使用

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

ask_pipeworx({ question: "your question about Wipo Ipc data" })

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT