공식 MCP Registry는 MCP 클라이언트와 디렉터리가 서버를 조회하는 곳이므로, 서버를 구축했다면 이곳에 등록되기를 원합니다. 저희는 Apify에서 웹 스크래퍼를 구축하고 이를 그룹화하여 원격 MCP 서버로 묶었으며, 지난 2주 동안 이 중 7개를 게시했습니다. 첫 번째 4개는 10월 1일에, 이후 3개는 10월 7일에 추가로 게시했으며, 이때 처음 4개의 3개도 업데이트했습니다. 실제 제한 사항과 오류를 통해 저희가 직면했던 문제점들을 공유합니다.
1. 서버당 포함할 도구 결정하기
저희의 첫 생각은 모든 도구를 담는 하나의 거대한 서버였습니다. 하지만 대신 사용 사례별로 분리했습니다. 예를 들어, 지역 비즈니스 리드(local business leads), 고객 리뷰(customer reviews), YouTube 데이터 등이 있습니다. 각 서버는 2개에서 7개의 도구를 포함합니다.
두 가지 이유가 있습니다:
- 모델이 비슷한 도구 몇 개만 볼 때 잘못된 도구를 선택할 확률이 줄어듭니다.
- 사용자의 게이트웨이가 자체적으로 도구를 추가할 수 있기 때문입니다. 저희의 경우, 작업 확인(checking a job), 결과 페이징(paging through results), 파일 읽기(reading a file), 작업 중지(stopping a job)를 위한 4개의 보조 도구가 모든 서버에 추가됩니다. 따라서 7개 도구로 구성된 서버는
tools/list에서 11개 도구로 표시됩니다.
여기에는 부가적인 이점도 있습니다. 각 서버가 자체 목록을 갖게 되므로,
mcp-publisher login github # github.com/login/device에서 입력할 코드를 표시합니다
mcp-publisher validate server.json
mcp-publisher publish server.json
...
네임스페이스를 소유한 계정으로 로그인하면서 코드를 승인하세요. 한 번의 로그인이 필요한 만큼 많은 게시물을 처리합니다. 공유된 장치에서 사용한다면, 토큰이 디스크에 남아있지 않도록 작업 완료 후 로그아웃하는 것이 좋습니다. 또한 이 바이너리는 GitHub 토큰을 처리하므로 실행하기 전에 릴리스의 체크섬 파일과 비교하여 SHA-256 값을 확인했습니다.
4. 업데이트는 새 버전이며, 이전 버전은 유지됩니다
서버를 변경하려면 더 높은 version으로 다시 게시해야 합니다. 레지스트리는 둘 다 보관합니다: 저희가 업데이트한 후, local-business-leads는 isLatest: false인 1.0.0과 isLatest: true인 1.1.0을 표시했으며, 둘 다 여전히 active 상태였습니다. 레지스트리를 읽는 클라이언트는 최신 버전을 사용해야 하지만, 이전 버전이 사라진다고 가정해서는 안 됩니다.
공개 API도 느릴 수 있습니다. 두 개의 항목을 반환하는 검색은 저희에게 약 23초가 걸렸으므로 스크립트에는 충분한 타임아웃 시간을 할당해 주세요.
5. 도구 이름은 64자를 넘지 않도록 유지하세요
저희 게이트웨이는 각 도구를 owner--tool-name 형식으로 이름을 지정합니다. 저희 중 하나는 66자로 나왔기 때문에 64자로 잘리고 짧은 해시 접미사가 붙었습니다:
...--ebay-product-reviews-scraper-with-advanced--60e9
이 절단은 임의적이지 않습니다. OpenAI나 Anthropic 같은 모델 API는 최대 64자까지 도구 이름만 허용합니다. 모델은 여전히 해당 도구를 받지만, 사용자 요청과 일치시키기 더 어려운 이름을 갖게 됩니다. 만약 근본적인 이름들을 제어할 수 있다면 짧게 유지하세요.
6. 디렉터리는 자동으로 목록화하며, 때로는 비정상으로 간주할 수 있습니다
저희는 Glama에 아무것도 제출하지 않았지만, 이 시스템은 하루 만에 레지스트리에서 저희의 모든 서버를 가져왔고, 나중에 업데이트된 설명도 가져왔습니다.
모두 'Unhealthy'로 표시됩니다. Glama의 검사기는 자격 증명 없이 연결되지만, 저희 서버는 사용자에게 로그인(OAuth)을 요구하므로 검사가 시작 단계에서 통과할 수 없습니다. 해결책은 해당 목록을 소유하고 Glama가 건강 상태 확인용으로만 사용하는 테스트 프로필을 추가하는 것입니다. 그렇게 한다면, 주 자격 증명이 아닌 제한된 자격 증명을 부여해야 합니다.
7. 멋진 목록에는 규칙이 있고, 대기열도 있다
awesome-remote-mcp-servers는 원격 서버에 대한 주요 큐레이션 목록입니다. 이 저장소의 CONTRIBUTING.md에는 다음 사항이 요청되어 있습니다:
- MCP
initialize 요청에 응답하는 엔드포인트 (CI가 모든 PR에서 확인)
- Glama 커넥터 배지 (CI도 확인)
- PR을 여는 계정으로부터의 저장소 스타
- 알파벳 순서로, 각 PR당 하나의 서버와 마침표로 끝나는 최대 120자 설명
- 인증 유형에 대한 표시: none, API key 또는 OAuth.
저희를 놀라게 한 것은 대기열이었습니다. 저희가 PR을 연 후 거의 일주일 동안 저장소에서 아무것도 병합되지 않았습니다. 그러다가 관리자가 며칠 만에 거의 400개의 PR을 병합했고, 저희의 PR은 그중 하나가 아니었습니다. 다른 항목들이 같은 섹션에 저희 옆에 도착하면서 이제 충돌(merge conflict)이 발생했습니다. PR에 달린 댓글에서 최신 main을 먼저 리베이스하거나 병합하라고 요청했습니다. 제출할 때는 PR을 주의 깊게 지켜보고 충돌을 빠르게 해결해야 합니다. 왜냐하면 병합은 일괄적으로 이루어지기 때문입니다.
또 다른 함정: 배지 검사는 Glama를 호출합니다. Glama가 잠시 다운되었을 때, 저희의 PR은 'no such connector' 오류로 실패했습니다. PR 설명을 편집하자 복구된 후 검사가 다시 실행되었습니다.
8. 게시하기 전에 체크리스트
- 사용 사례별로 서버를 하나씩 만들고, 모델이 처리할 수 있는 도구 개수를 고려하세요.
- 실제 URL에서 자격 증명(credentials) 유무에 관계없이
initialize와 tools/list를 호출하고, 도구 이름을 읽어보세요.
title과 description은 100자 이내로 작성한 후, mcp-publisher validate를 실행하세요.- 변경 사항이 있을 때마다
version을 올리세요.
- 공유 장비에서는 퍼블리셔(publisher)에서 로그아웃하세요.
- 하루 뒤에 디렉터리가 서버를 어떻게 보여주는지, 건강 상태(health status) 포함하여 확인해 보세요.
- 큐레이션된 목록의 경우: 서버당 PR을 하나씩 제출하고, 이를 주시하세요.
혹시 MCP 서버도 게시하고 계신가요? 사용자분들이 실제로 어떤 디렉터리를 통해 여러분을 찾는지 알고 싶습니다.
AI 도움을 받아 작성됨.