How I built an MCP server for 27 government registries in a week

Source: Dev.to

Example shape

• registry: UK Companies House
• lookup: exact name match plus fallback fuzzy search
• result: company number, status, incorporation date, registered office, officers, filing links

The early version failed in predictable ways. UK and Ireland both accept names that look similar but point to different legal entities. Germany and Cyprus can return records in forms that are technically valid but not readable unless you keep the original language in the payload. Taiwan and Norway were easier on the data side, but they still disagreed on how much structure you get back from a simple company search.

Design Changes

1. Separate source and normalized data

I stopped pretending every registry should look the same. The response object now keeps a source block and a normalized block side by side. This lets Claude answer in plain language while preserving the exact registry fields, and it makes debugging mismatches much easier.

2. Treat rate limits as product behavior

Rate limits are now considered part of the product, not just an error path. Some registries are fine for interactive lookups but awkward for polling; others are generous until you request too many related records. The server now marks which endpoints are safe for one‑off human questions and which are better for follow‑up detail.

3. Make the connector usable for non‑developers

Many users don’t want an API; they just want to ask simple questions like “Is this company real?”, “Who is the director?”, “What filings changed?”, and “Is the ownership trail consistent?”. With the MCP layer in place, the question stays simple even if the underlying registry is not.

Demo Conversation

User: Check whether this company is actually active and who runs it.

Claude: I found the company record, the current status is active, and the officer list includes two directors. The filing history shows the most recent confirmation statement was filed on time.

User: Can you show the original source?

Claude: Yes, here are the registry links and the exact fields I used.

Lessons Learned

• Source vs. normalized data: Keep them separate to retain honesty of the original data.
• Messy identifiers: Assume identifiers will be inconsistent across registries.
• Human‑first design: Design for answering human questions before optimizing for bulk extraction.
• Multi‑step workflow: A good company lookup often requires a sequence—confirm the entity, inspect officers, check filings, then follow cross‑jurisdiction links. The MCP layer preserves this sequence without forcing users to handle each registry’s quirks.

Try It

You can try the connector here: