Epo Publication Server MCP server

@pipeworx/epo-publication-server

As-published European patent documents — publication dates, per-date listings with titles and applicants, and full document text (biblio, abstract, claims, description) for granted patents and directly-filed applications. Keyless.

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

Tools

(weekly, almost always Thursdays, back to 1978) with a real per-date document count.

• epspublicationdates(year?, from?, to?, limit?) — EPO publication dates

on one date, with kind code, title and applicant(s); reports the true total before any filtering.

• epslistpublications(date, kind?, limit?) — every EP publication issued

data, abstract, claims or description text, as published.

• epsgetdocument(number, kind?, part?) — one publication's bibliographic

Auth

Keyless. No account, no registration.

EPO states a fair-use cap of 5 GB per rolling 7-day window per calling IP, confirmed live via the x-quotaperweek-remaining/x-quotaperweek-used response headers. General EPO site terms apply; no EPS-specific redistribution restriction was found.

Data sources

as-published XML/HTML of every EP patent application and granted European patent.

• European Patent Office (EPO), European Publication Server — the

Notes for the next person

publication date (wrong day of week, a future date, a typo) answers HTTP 200 with a tiny HTML shell and zero entries — not a 404, not an error. EPO has never actually had a genuinely empty publication date in 2,400+ weeks of history, so epslistpublications treats zero parsed entries as a loud failure rather than a silent empty list. Always get a real date from epspublicationdates first.

• The list-by-date trap: asking for a date that is not a real EPO

The large majority of EP applications enter via the PCT route, and EPO republishes only the bibliographic (SDOBI) record for those — the full specification was already published as the WIPO (WO) pamphlet, so EPO does not retype it. Full claims/description/drawings text is reliably present for granted (B-kind) patents and for directly-filed (non-PCT) applications. epsgetdocument reports which case it hit (and names the referenced WO publication when it's a PCT case) rather than returning an empty part silently.

• Most application (A-kind) publications carry NO claims/description text.

segment is a longer id like EP4819826NWA1 — the publication number, an internal marker (NW for the overwhelming majority of documents, W1 for a minority), and the kind code. epslistpublications returns these ids directly; epsgetdocument also accepts a bare number + kind and tries the common id forms in order.

• Document ids aren't just the publication number + kind. The REST path

({"code":9000,"message":"Unhandled internal server error."}). This is actually easy to work with: epsgetdocument tries its candidate ids and reports found:false with the upstream status once all of them fail.

• A made-up document id does not 404 — it 500s with a small JSON body

as-published document text itself, keyless. epo-ops keeps INPADOC worldwide legal status and CQL search across DOCDB (100+ patent offices); this pack only ever sees EP publications.

• What this adds over mcps/epo-ops (EPO Open Patent Services, OAuth2): the

Quick Start

Add to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):

{
  "mcpServers": {
    "epo-publication-server": {
      "url": "https://gateway.pipeworx.io/epo-publication-server/mcp"
    }
  }
}

What this endpoint actually serves

Shortened. The full README is on GitHub.