Loading ToolBench
Remote MCP server for patent search via EPO OPS, deployed on Cloudflare Workers.
Patent MCP server demonstrates solid definition quality with comprehensive tool descriptions in Chinese and well-structured schemas. All 5 tools have detailed descriptions (194 - 500+ chars, well above the 10 - 1024 baseline), clear input schemas with type definitions, and proper parameter documentation. Tool names follow verb_noun convention (search_*, get_*). However, output schemas are not explicitly documented in the visible code, and error handling guidance is minimal. The server targets a specialized domain (patent search) with sophisticated query syntax documentation, which is a strength, but lacks explicit recovery paths for common failures (invalid publication numbers, API rate limits, network timeouts).
取单篇专利的完整权利要求文本（按权利要求编号分条）及总条数。用于 claim 分析、FTO（自由实施）评估、enablement 评估，或用户想读某专利保护范围时使用。
取单篇专利的著录项目（biblio）与摘要：标题、摘要、申请人、发明人、IPC/CPC 分类、申请日、公开日、优先权日。已知具体公开号、需要专利书目信息或摘要时使用。
取 INPADOC 专利族成员（各成员公开号 + 国家）与法律状态事件。用于全球专利布局分析、同族检索、以及有效性 / 法律状态判断时使用。
按关键词、申请人或分类号检索专利（EPO OPS），返回命中概览（公开号、标题、申请人、发明人、公开日、IPC 分类、family_id）。用于发现某主题/公司/技术领域的相关专利、landscape 初筛、或不知道确切公开号时。 检索策略（提高召回、避免漏检，适用所有技术领域）： ① 别只用单一关键词——同一技术常有多种写法，用同义/近义术语做 OR 扩展。例：生物 ta=siRNA or ta="iRNA agent" or ta="RNAi agent" or ta=dsRNA；电池 ta="solid-state electrolyte" or ta="solid electrolyte" or ta=SSE；半导体 ta=FinFET or ta="fin field-effect transistor"。 ② 用分类号 ic=（IPC）/ cpc=（CPC）兜底——分类号不受用词影响，能跨术语捕获（如 ic=C12N15/113 覆盖 siRNA 类），是治术语变体漏检最有效的免费手段。 ③ 锁定龙头/竞品时用 pa= 申请人定向兜底（如 pa=alnylam）。 ④ 对命中结果可取其 family_id 调 get_patent_family 顺藤摸同族、交叉验证。 注意：OPS 仅匹配【标题+摘要】、做字面匹配。若担心术语变体仍漏检（尤其 FTO 场景），改用 search_patents_google（Google 引擎自带语义/同义扩展，召回更高）。拿到 publication_number 后用 get_patent_details / get_patent_claims / get_patent_family 取详情。
用 Google Patents 引擎做【高召回 / 跨术语】检索（经 SerpApi），Google 会自动做相关性排序与同义扩展。适用场景：FTO 初筛广撒网；或当 search_patents（基于 EPO OPS 标题摘要的字面匹配）可能漏掉术语变体时（例如 siRNA 在专利里又写作 'iRNA agent' / 'RNAi agent' / 'dsRNA'）。查询用 Google Patents 风格的关键词与布尔运算（如 '(PCSK9) (siRNA OR "iRNA agent" OR dsRNA)'），不要用 OPS 的 CQL 语法。返回含 publication_number，可再用 get_patent_details / get_patent_claims / get_patent_family 取结构化详情、权利要求与同族。
Output schemas not documented in visible code. Tools return structured data but LLMs cannot see what fields to expect (e.g., search_patents returns 'publication_number, title, applicant, inventor, publication_date, ipc_classification, family_id' but this is not in a schema definition). Forces LLMs to infer output structure.
Error handling lacks recovery guidance. No documented error responses for common failures: invalid publication_number format, EPO OPS API rate limits, network timeouts, malformed CQL queries. LLMs cannot self-correct or know whether to retry.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 83 | 2026-07-28+ | v2 |
No pagination or result limits documented for search_patents and search_patents_google. search_patents accepts limit (1 - 25, default 10) but search_patents_google accepts limit (10 - 100, default 10). If EPO OPS or Google Patents returns thousands of results, response could exceed context window. No 'next_cursor' or 'total_count' fields documented.
Parameter descriptions use domain-specific jargon (CQL, INPADOC, IPC, CPC, kind code, epodoc, docdb) without sufficient explanation for LLMs unfamiliar with patent terminology. Example: 'epodoc' vs 'docdb' format choice is not explained, LLMs may not know which to use.
No idempotency guarantees documented. Patent search tools should be idempotent (same query → same results), but this is not stated. If an LLM retries a failed search_patents call, it should know the operation is safe to repeat.