Retrieves EPO OPS INPADOC patent family members across countries, including publication, application, and priority numbers, with optional biblio or legal constituent details.
EPO OPS INPADOC 專利家族成員（各國公開／公告號、申請號、優先權）；constituent 可為 biblio 或 legal。預設回壓平摘要，raw=true 回原始 JSON。
| Name | Required | Description | Default |
|---|---|---|---|
| fmt | No | auto | |
| raw | No | ||
| number | Yes | ||
| constituent | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.2.0Input schema / properties / rawAdded value: +{
+ "default": false,
+ "title": "Raw",
+ "type": "boolean"
+}v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, non-destructive, open-world). The description adds useful behavioral context by explaining that the default response is a flattened summary and that raw=true returns raw JSON.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the core resource first and then the key parameter/return-format details. Every clause contributes useful information without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and an output schema present, the description does not need to explain return values in depth. Still, it omits the meaning of number and fmt, so an agent has to infer how to use those parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains constituent values (biblio or legal) and raw behavior, but does not explain the required number parameter or the fmt parameter, leaving two of four parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as EPO OPS INPADOC patent family members, including the kinds of numbers returned. It is specific enough to distinguish this tool from generic bibliographic or legal-status tools, though it does not explicitly name those siblings as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: retrieve patent family members and optionally choose biblio or legal constituent data. However, there is no explicit guidance on when to use this tool versus ops_biblio, ops_legal_status, or ops_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.