일주일 만에 27개 정부 레지스트리를 위한 MCP 서버를 구축한 방법
Source: Dev.to
Example shape
- registry: 영국 Companies House
- lookup: 정확한 이름 일치와 백업 퍼지 검색
- result: 회사 번호, 상태, 설립일, 등록 사무소, 임원, 제출 링크
초기 버전은 예측 가능한 방식으로 실패했습니다. 영국과 아일랜드는 비슷해 보이지만 다른 법인에 해당하는 이름을 허용합니다. 독일과 사이프러스는 기술적으로는 유효하지만 원본 언어를 페이로드에 유지하지 않으면 읽을 수 없는 형태로 레코드를 반환할 수 있습니다. 대만과 노르웨이는 데이터 측면에서는 더 쉬웠지만, 단순한 회사 검색에서 반환되는 구조의 양에 대해 여전히 의견이 일치하지 않았습니다.
Design Changes
1. Separate source and normalized data
모든 레지스트리가 동일하게 보이도록 가장하는 것을 멈췄습니다. 응답 객체는 이제 source block과 normalized block을 나란히 유지합니다. 이를 통해 Claude가 일반 언어로 답변하면서도 정확한 레지스트리 필드를 보존할 수 있고, 불일치를 디버깅하기가 훨씬 쉬워집니다.
2. Treat rate limits as product behavior
속도 제한은 이제 단순 오류 경로가 아니라 제품의 일부로 간주됩니다. 일부 레지스트리는 인터랙티브 조회에는 적합하지만 폴링에는 부적합하고, 다른 레지스트리는 관련 레코드를 너무 많이 요청할 때까지는 관대합니다. 서버는 이제 어떤 엔드포인트가 일회성 인간 질문에 안전하고, 어떤 것이 후속 상세 정보에 더 적합한지 표시합니다.
3. Make the connector usable for non‑developers
많은 사용자는 API를 원하지 않습니다; 단순히 “이 회사가 실제로 존재하는가?”, “대표자는 누구인가?”, “어떤 제출물이 변경되었는가?”, “소유권 흐름이 일관되는가?”와 같은 질문만 하면 됩니다. MCP 레이어가 적용되면, 기본 레지스트리가 복잡하더라도 질문은 여전히 간단하게 유지됩니다.
Demo Conversation
User: 이 회사가 실제로 활동 중인지와 누가 운영하는지 확인해 주세요.
Claude: 회사 레코드를 찾았으며, 현재 상태는 활성이며, 임원 목록에 두 명의 이사가 포함되어 있습니다. 제출 이력은 가장 최근의 확인 진술서가 제때 제출되었음을 보여줍니다.
User: 원본 소스를 보여줄 수 있나요?
Claude: 네, 여기 레지스트리 링크와 제가 사용한 정확한 필드가 있습니다.
Lessons Learned
- Source vs. normalized data: 원본 데이터를 정직하게 유지하려면 두 데이터를 별도로 보관하세요.
- Messy identifiers: 식별자는 레지스트리마다 일관되지 않을 수 있다고 가정하세요.
- Human‑first design: 대량 추출을 최적화하기 전에 인간 질문에 답변하도록 설계하세요.
- Multi‑step workflow: 좋은 회사 조회는 종종 일련의 단계—엔티티 확인, 임원 검사, 제출물 확인, 그리고 관할 구역 간 링크 추적—를 필요로 합니다. MCP 레이어는 각 레지스트리의 특성을 사용자가 직접 다루지 않아도 이 순서를 보존합니다.
Try It
You can try the connector here: