Wipo Ipc MCP server

@pipeworx/wipo-ipc

International Patent Classification (IPC) lookup — title, validity and structural breakdown of a classification symbol, the groups/subgroups under it, and keyword search over classification titles. Keyless.

Part of Pipeworx — an MCP gateway connecting AI agents to 1837+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.

Tools

structural breakdown and whether it is currently valid.

• ipc_lookup(symbol, version?) — one IPC symbol's title (English/French),

one IPC symbol (main groups under a subclass, subgroups under a group), each with a title.

• ipc_children(symbol, version?) — the symbols classified directly under

matches a keyword, e.g. "vaccine".

• ipc_search(query, version?, limit?) — IPC symbols whose title text

current (in force) and latest (published, may be future-dated) editions.

• ipc_versions() — IPC edition dates WIPO currently publishes, naming the

Auth

Keyless. No account, no registration, no rate limit documented.

Data sources

Classification (IPC) scheme.

• World Intellectual Property Organization (WIPO), International Patent

Notes for the next person

maintained by EPO and USPTO) extends IPC with much finer subdivisions, and is what EPO/USPTO actually classify most modern patents under. A CPC code (e.g. one returned verbatim by epo-ops or epo-publication-server) is not interchangeable with an IPC one even when it looks similar. This pack has no CPC awareness at all — Pipeworx has no dedicated CPC lookup pack at the time this was written.

• IPC is not CPC. The Cooperative Patent Classification (jointly

wipo.int. Every operation here was found by reading IPCPUB's own front-end JavaScript and probing the resulting candidate paths live — there is no published spec to check this against.

• The catalog's own listed OpenAPI spec for this service is a dead 404 on

itself only accepts a fixed 4-character subclass form ("A01N") or a fixed 14-character form with the main group zero-padded to 4 digits and the subgroup zero-padded to 6 ("A61K" + "0031" + "000000"). parseSymbol() is the one place that conversion happens — a 1- or 3-character partial symbol (just a section, or a class) either 404s or, for a 3-character class-level symbol specifically, 500s on the upstream's own validity endpoint; neither is attempted here.

• Symbol format: humans write "A61K 31/00" or "A01N"; the web service

subclasses — this is upstream, not a bug. IPCPUB's tree-navigation endpoints (ancestors/children) render a classification's entire nested title tree server-side on every request, with no caching: the SAME subclass fetch (A01N) measured 1.4s once and 20.8s another time. For an unusually large subclass — A61K ("medicinal preparations"), one of the biggest in the whole scheme — every key inside it reliably 504s at AWS API Gateway's own ~29.5s integration ceiling, with {"message":"Endpoint request timed out"}, regardless of which specific node is queried (the symbol's own key, its immediate group wrapper, or the subclass itself). ipclookup and ipcchildren both bound this to one 28-second attempt and degrade to titleen: null / titlefr: null with a plain titleerror rather than hanging — valid/structure (from the separate, fast, reliable getvalidity endpoint) are unaffected either way. A main group under A61K — e.g. A61K 31/00 — is the single symbol most likely to hit this, so don't be surprised if a title request for it times out live; that is the upstream's own rendering cost, confirmed by repeated direct probes, not a defect in this pack.

• **Title lookup is genuinely slow and occasionally fails for huge

returns classification-validity: "N" (invalid), which

• A made-up but well-formed symbol does not 404 on getvalidity — it

Shortened. The full README is on GitHub.