@pipeworx/china-medical-devices

China's medical-device Unique Device Identification (UDI) register — search by product/trade name or model, resolve one device identifier, look up a manufacturer, and list what changed since a date, refreshed from the publisher's release files.

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

Tools

• udi_search(query, manufacturer?, limit?) — free-text search over product name, trade name, and model (all terms must match), optionally filtered by registrant/manufacturer name.

• udi_resolve(udi_di) — exact lookup of one product-level UDI-DI.

• udi_manufacturer(name?, registrant_id?, limit?) — registrants matching a name or unified social credit code, with how many device identifiers and registration numbers each holds.

• udi_recent_changes(since, limit?) — devices whose latest published version is on or after a date, newest first, drawn from the publisher's delta release files.

• udi_coverage() — device count, newest/oldest dates, and whether the search indexes are built yet. Check this before trusting udi_search latency on a very broad term.

Related MCP server: Enterprise MCP Server

Auth

Keyless. No vendor key is involved — the data lives in Pipeworx's own store, loaded from the publisher's own release files.

Data sources

• NMPA (National Medical Products Administration), Unique Device Identification database — the official register of medical-device Unique Device Identifiers for devices sold in China. The publisher distributes this as periodic bulk release files (a full release plus delta files), not a public query API, so this pack is refreshed on that cadence rather than calling the publisher per request. The exact release/delta routes live only in src/index.ts and scripts/nmpa-udi-load.py.

Licence note: the publisher's download page carries only a copyright line (版权所有：国家药品监督管理局); no explicit reuse terms were found on it or in the release files themselves. Under the standing rule for a source that only publishes bulk files and is silent on reuse (hold only when terms forbid redistribution; build and flag when they are silent), this pack ships with that flag rather than a hold. If explicit terms forbidding redistribution turn up later, this needs to be revisited.

What is deliberately not stored: registrants' contact details (e-mail, phone) the release carries — personal data this pack has no reuse ruling to serve — and packaging/carton-level identifiers, a different register at a different grain nobody has asked for. A lookup for one of those resolves found: false with a note, not an error.

Demand status: this pack was built from a standing Bruce ask to assess China-source coverage (2026-10-21), not from measured demand — the 30-day miss log showed zero misses for this specific register at the time it was proposed. Build-to-see-what-it-does, not a backlog item that real traffic was waiting on.

Cross-link: @pipeworx/china-pharma covers NMPA drug approvals and policy announcements (via HKEX disclosure filings and the NMPA English-language announcements) — a different register, drugs rather than devices, at a different grain. Use that pack for drug approvals; use this one for device identifiers.

Data and refresh

The register is loaded from the publisher's full release and kept current by applying its delta files (daily, weekly, monthly) in date order. The loader is resumable and idempotent: a stored device is only replaced by a version that is not older. Every response carries data_as_of (the release date of the latest file applied) and, for udi_resolve / udi_coverage, ingested_at.

Individuals are not served. Some registrants are sole proprietors filing in their own name (the published registrant name is just a personal name). Their registrant name, English name and credit code are withheld at load and never stored; the device record itself (name, model, registration number) is served. udi_manufacturer therefore lists companies only.

Search speed. udi_search and udi_manufacturer scan the table until the search indexes are built (a separate database step run after the bulk load); until then expect roughly 10-15 seconds on a broad term.

Quick Start

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

{
  "mcpServers": {
    "china-medical-devices": {
      "url": "https://gateway.pipeworx.io/china-medical-devices/mcp"
    }
  }
}

What this endpoint actually serves

tools/list at https://gateway.pipeworx.io/china-medical-devices/mcp returns the tools in the table above plus the shared Pipeworx meta-tools — ask_pipeworx, discover_tools, search_within, remember/recall and the rest of the gateway-wide set. So the tool count you see is larger than this table: a single-pack endpoint currently lists roughly 30 shared tools alongside the pack's own. The connection's initialize response states its exact scope, and is the authoritative answer for a given day.

This is deliberate, not multiplexing by accident. The meta-tools are what let a scoped connection answer a question this pack does not cover — via ask_pipeworx, which routes across the whole catalog — without you adding a second MCP server. There is currently no way to mount a pack endpoint without them; if the extra schemas cost you more context than the routing is worth, connect to the full gateway once rather than to several pack endpoints.

Or connect to the full Pipeworx gateway to get every pack's tools listed directly, instead of just this one's:

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

Both URLs reach the same gateway and the same 1861+ data sources. The only difference is which pack's tools are listed directly; ask_pipeworx reaches all of them from either one.

No MCP client? Call it over HTTP

curl -X POST https://gateway.pipeworx.io/v1/tools/udi_search \
  -H 'Content-Type: application/json' \
  -d '{"query":"起搏器","manufacturer":"美敦力","limit":3}'

No account needed for the first calls. Inspect any tool: GET https://gateway.pipeworx.io/v1/tools/udi_search. Find one: POST https://gateway.pipeworx.io/v1/tools/search_packs with {"query":"..."}.

Run it from npm

@pipeworx/mcp-china-medical-devices is a local stdio bridge to the Pipeworx gateway: your MCP client starts it with npx, and it forwards every call to the same https://gateway.pipeworx.io/china-medical-devices/mcp endpoint shown above. It needs network access; there is no offline mode.

{
  "mcpServers": {
    "china-medical-devices": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-china-medical-devices"]
    }
  }
}

Without a key it calls anonymously, capped at 50 calls a day. A free account raises that to 200 a day: get a key at https://pipeworx.io/signup and add "env": { "PIPEWORX_API_KEY": "<your key>" } to the server entry. The key is sent as a Bearer token, the same way a hosted connection sends it, so calls are metered and billed exactly as they are there.

It lists only this pack's tools by default. Set PIPEWORX_META_TOOLS=1 to also list ask_pipeworx and the other gateway-wide tools.

Behind an HTTPS proxy: Node's built-in fetch does not read HTTPS_PROXY by default. Newer Node releases honour it when NODE_USE_ENV_PROXY=1 is set; check your Node version's documentation.

Using with ask_pipeworx

Instead of calling tools directly, you can ask questions in plain English — this works on the pack endpoint above as well as on the full gateway:

ask_pipeworx({ question: "your question about China Medical Devices data" })

The gateway picks the right tool and fills the arguments automatically.

More

• Docs and guides

• pipeworx.io

License

MIT