MCP server unifies 27 government registries for plain-language company lookups
OpenRegistry built an MCP server in one week that connects Claude Desktop to 27 government company registries, normalizing responses while preserving original source data and registry-specific quirks.
Score breakdown
Developers building MCP-based data connectors can adopt the dual `source`/`normalized` response pattern and rate-limit-as-product-behavior approach to handle messy real-world APIs without sacrificing debuggability or data fidelity.
- 01Built an MCP server connecting Claude Desktop to 27 government company registries in one week.
- 02Each response carries both a `source` block (exact registry fields) and a `normalized` block (readable output) side by side.
- 03UK and Ireland name collisions, German/Cypriot language-dependent records, and Taiwan/Norway structural differences were key cross-registry challenges.
OpenRegistry describes building an MCP server in one week that connects Claude Desktop to 27 government company registries, enabling plain-language queries like "is this company active and who runs it?" to return structured, source-linked answers. The core architectural insight was abandoning the assumption that every registry should look the same. Each response object now carries both a `source` block with exact registry fields and a `normalized` block for readable output — a design that preserves debuggability and keeps the original data honest while still letting Claude respond conversationally.
Rather than flattening these differences, the adapter layer became the place where normalization work happened.
The build surfaced several cross-registry challenges: UK and Ireland accept similar company names that map to different legal entities; Germany and Cyprus return technically valid records that require the original language to remain readable; Taiwan and Norway disagreed on how much structure a basic company search returns. Rather than flattening these differences, the adapter layer became the place where normalization work happened. Rate limits were also reclassified as product behavior — some registry endpoints are marked safe for one-off human lookups, others for follow-up detail queries — rather than treated as generic errors.
A third design shift was orienting the server toward non-developer users who want to ask sequential questions: confirm the entity, inspect officers, check filings, follow cross-jurisdiction links. The MCP layer preserves that multi-step workflow without exposing registry quirks to the end user. The demo was redesigned accordingly, replacing a wall of data with a short conversation and a visible source trail. The connector is available at `https://openregistry.sophymarine.com`.
Key facts
- 01Built an MCP server connecting Claude Desktop to 27 government company registries in one week.
- 02Each response carries both a `source` block (exact registry fields) and a `normalized` block (readable output) side by side.
- 03UK and Ireland name collisions, German/Cypriot language-dependent records, and Taiwan/Norway structural differences were key cross-registry challenges.
- 04Rate limits are treated as product behavior: endpoints are marked safe for interactive lookups vs. follow-up detail retrieval.
- 05Normalization bugs — not registry data bugs — were the source of most inconsistencies found during testing.
- 06The server is designed for non-developer users asking plain-language questions about company status, directors, filings, and ownership trails.