我在一周内为27个政府登记机构构建了MCP服务器

Source: Dev.to

示例结构

• registry: 英国公司注册局（UK Companies House）
• lookup: 精确名称匹配并辅以模糊搜索
• result: 公司编号、状态、成立日期、注册办公地点、官员、文件链接

早期版本会以可预见的方式失败。英国和爱尔兰都接受看起来相似但对应不同法律实体的名称。德国和塞浦路斯可能返回技术上有效但除非保留原始语言在负载中否则不可读的记录。台湾和挪威在数据方面相对容易，但它们仍然在简单公司搜索返回的结构化程度上存在分歧。

设计变更

1. 将源数据与归一化数据分离

我不再假设每个注册机构的返回都必须相同。响应对象现在并列保留 source block（源块）和 normalized block（归一化块）。这让 Claude 能以自然语言回答的同时保留精确的注册字段，也让调试不匹配的情况更容易。

2. 将速率限制视为产品行为

速率限制现在被视为产品的一部分，而不仅仅是错误路径。有些注册机构适合交互式查询，但不适合轮询；有些则慷慨，直到你请求过多关联记录。服务器现在会标记哪些端点适合一次性的人类提问，哪些更适合后续细节查询。

3. 让连接器对非开发者可用

许多用户并不想使用 API；他们只想提出诸如“这家公司是真实存在吗？”、“谁是董事？”、“有哪些文件变更？”以及“所有权链是否一致？”之类的简单问题。有了 MCP 层，问题保持简洁，即使底层注册机构复杂多变。

演示对话

用户: 检查这家公司是否真的在运营以及谁在管理它。

Claude: 我找到了公司记录，当前状态为活跃，官员名单中包括两位董事。文件历史显示最近的确认声明已按时提交。

用户: 能展示原始来源吗？

Claude: 可以，这里是注册机构的链接以及我使用的精确字段。

经验教训

• 源数据 vs. 归一化数据: 将它们分开，以保留原始数据的真实性。
• 混乱的标识符: 假设不同注册机构的标识符会不一致。
• 以人为本的设计: 在优化批量抽取之前，先为回答人类问题而设计。
• 多步骤工作流: 一个好的公司查询通常需要一系列步骤——确认实体、检查官员、核对文件，然后跟踪跨司法管辖区的链接。MCP 层保留了这一顺序，而无需用户自行处理每个注册机构的怪癖。

试用

您可以在此处尝试该连接器：