저는 여행 물류(travel-logistics) MCP 커넥터를 구축했습니다. 6개의 도구(렌터카, 공항 픽업/샌딩, 투어, 여행용 eSIM, 수하물 보관, 항공 보상)로 구성되어 있으며, 그중 3개는 MCP Apps 위젯을 렌더링합니다. Remote Streamable HTTP를 사용하며, 인증(auth)이 없는 개인 프로젝트입니다.

빈 저장소(repo)에서 서버 제출까지 4일, 그 후 20일간의 대기 시간이 있었습니다. 7월 10일에 Anthropic 커넥터 디렉토리에 제출하여 7월 30일에 승인되었습니다.

제출을 준비하면서 이 과정에 대해 쓰인 글을 거의 찾을 수 없었습니다. 그래서 제가 간절히 원했던 정보들, 즉 실제 관문(gates), 나중에 알게 되면 낭패를 볼 수 있는 문서화되지 않은 캐싱(caching) 규칙, 그리고 승인 후 게시자 입장에서 보는 디렉토리의 모습에 대한 노트를 정리했습니다.

이 글은 "MCP란 무엇인가"에 대한 글이 아닙니다. 이미 작동하는 서버를 가지고 있으며, 이를 제출할지 고민 중인 분들을 대상으로 합니다.

요약 버전 (이것만 찾으러 오셨다면):

• 제출 포털을 이용하려면 Team 또는 Enterprise 조직(org)이 필요합니다. 최소 요건은 5석이 아니라 2석이며, 비용은 월 약 52유로입니다.
• 법인(legal entity)은 필요하지 않습니다. 저는 개인 저자로 제출했습니다.
• 제출부터 승인까지 20일이 걸렸으며, 제가 먼저 문의한 적은 없습니다. 공개된 SLA(서비스 수준 협약)는 없습니다.
• 승인되면 기본적으로 Community 티어로 분류되며, 거기서 Verified(인증됨) 단계로 가는 공개된 경로는 없습니다.
• 도구 세트(tool set)는 연결 시점(connect time)에 고정됩니다. 이미 연결된 모든 사용자에게 동일하게 적용됩니다. 설명(Descriptions)은 언제든 수정할 수 있지만, 도구 목록은 수정할 수 없습니다.
• 디렉토리를 통해 연결된 경우, 도구들은 기본적으로 "항상 허용(always allow)" 상태로 제공됩니다. URL을 통해 연결된 경우에는 그렇지 않습니다. 동일한 서버임에도 차이가 있습니다.

나머지 내용은 제가 이 사실들을 어떻게 알게 되었는지, 그리고 그 대가가 무엇이었는지에 대한 설명입니다.

비용이 발생하는 유일한 관문

제출 포털은 조직 관리자(org admin) 설정에 있으며, Team 또는 Enterprise 조직에서만 사용할 수 있습니다. 개인용 경로는 존재하지 않습니다.

개인 개발자에게는 조직을 생성하고 Team 플랜에 비용을 지불해야 한다는 의미입니다. 흔히 언급되는 최소 인원은 5석이지만, 이것 때문에 저는 몇 주 동안 망설였습니다. 이는 잘못된 정보입니다. 실제 최소 인원은 2석이며, 부가세(VAT)를 포함하여 월 약 €52입니다.

이것이 진정한 시작 비용입니다. 그 과정의 나머지 모든 것은 무료입니다.

제가 돈을 지불하기 전에도 답할 수 없었고, 지금도 여전히 답하지 못하는 질문이 있습니다. 이것이 초기 등록비인가요 아니면 임대료인가요? 조직 등급을 낮춘 후에도 승인된 리스팅이 유지되나요? 저는 제출한 날짜에 검토팀에 서면으로 이 질문을 했습니다. 한 달이 지나도 답장이 없습니다. 누군가 달리 증명하기 전까지는, 원하는 기간 동안 리스팅을 유지하려면 구독료로 예산 책정하는 것이 안전합니다. 이것이 제가 가정하고 있는 부분입니다.

(€52에는 제 현지 VAT가 포함되어 있습니다. 귀하의 금액은 다를 수 있으니, 세전 금액을 비교해 보세요.)

법인 단체일 필요는 없습니다. 저는 개인 작가 자격으로 제출했고, 양식에 있는 소유권 질문은 기업 구조가 아니라 사용자의 API 관계에 관한 것입니다.

타임라인

• 7월 10일 — 관리자 포털을 통해 제출했습니다.
• 7월 30일 — 커뮤니티 커넥터로 승인되었습니다.
• 7월 30일, 몇 분 후 — 게시되었습니다. 승인 후의 게시는 셀프 서비스 방식입니다. 즉, '게시(Publish)' 버튼을 누르면 리스팅이 활성화됩니다.

20일 만에 제가 아무런 알림도 받지 않았습니다. 공식적으로 공표된 SLA는 없으며, 공식 지침은

annotations.title 누락은 즉시 플래그(flag)가 지정됩니다. 저는 제 도구(tools)들에 제목을 설정하지 않았었습니다. 양식에서 이를 지적했고, 제목을 추가한 뒤 재배포(redeploy)하고 동일한 세션 내에서 다시 점검을 실행했더니 통과되었습니다. 수정 후 재시도(Fix-and-retry)가 가능하며, 처음부터 다시 시작할 필요는 없습니다.

공개된 개인정보 처리방침(privacy policy)과 랜딩 페이지(landing page)가 필수입니다. 선택 사항이 아니며,

다섯 가지 상황 모두에서 살아남는 멘탈 모델(mental model)은 다음과 같습니다: 인터페이스는 연결 시점(connect time)에 고정되며, 그 뒤의 동작은 실시간(live)으로 작동한다.

이 모든 것은 2026년 7월 말에 테스트된 관찰된 클라이언트 동작(client behaviour)입니다. 이는 문서화된 계약(documented contract)이 아니며, 어떤 릴리스(release)에서든 변경될 수 있습니다. 만약 변경 사항이 발생하면 이 포스트를 업데이트하겠습니다.

실질적인 결과:

1. 배포하기 전에 도구 세트(toolset)를 확정하세요. 어제 연결한 사용자는 당신이 내일 출시하는 도구를 볼 수 없습니다. 사용자가 이유 없이 수동 작업을 수행하지 않는 한, 영원히 볼 수 없습니다.
2. 배포하기 전에 위젯(widget)도 다듬으세요. 저는 위젯 HTML이 실시간 리소스(live resource)여서 출시 후에도 개선할 수 있다고 가정했습니다. 하지만 그렇지 않았습니다. 저는 패딩(padding) 수정 사항이 새로고침(Refresh) 전까지 반영되지 않는 것을 보고 제 생각이 틀렸음을 증명했습니다.
3. 설명(Descriptions)은 영구적으로 수정 가능합니다. 이것은 실질적인 탈출구(escape hatch)입니다. 도구 설명은 당신의 트리거 표면(trigger surface)이자 검색 인덱스(search index)이며, 출시 후에도 계속해서 미세 조정(tuning)할 수 있습니다.
4. 도구의 동작을 제한해야 한다면, 메타데이터(metadata)가 아닌 핸들러(handler)에서 수행하세요. 메타데이터는 사용자별로 고정되지만, 핸들러 코드(handler code)는 호출될 때마다 실행됩니다. 어노테이션(Annotations)은 선언하고, 핸들러(handlers)는 강제합니다.

그렇다면 언제 개발을 멈추고 제출해야 할까요?

이것은 캐시 규칙(cache rule)이 당신에게 강요하는 질문이며, 저도 답변하는 데 예상보다 오랜 시간이 걸렸습니다. 여기서 두 가지 별개의 사항이 혼동되므로, 이를 나누어 설명하겠습니다.

당신의 서버는 언제든 원하는 대로 변경할 수 있습니다. 목록은 특정 URL을 가리킵니다. 아무도 당신의 코드를 재승인(re-approve)하지 않습니다. 수정 사항을 배포하고, 데이터 소스(data sources)를 교체하고, 핸들러(handlers)를 다시 작성하세요. 이 중 그 어떤 것도 디렉토리(directory)와는 관련이 없습니다.

당신의 인터페이스는 사실상 그렇게 할 수 없습니다. 금지되었기 때문이 아니라, 캐시(cache) 때문입니다. 배포 후에 추가된 도구(tool)는 오직 새로운 연결에만 도달합니다. 이미 연결된 모든 사용자는 수동적인 조치를 취할 이유가 없는 한, 첫날에 받았던 인터페이스(surface)를 그대로 유지합니다. 따라서 실질적인 답변은 "영원히 동결하라"가 아니라, **"나중에 추가하는 모든 것은 기존 사용자가 아닌 미래의 사용자에게만 제공된다"**입니다.

이것은 개발 중단 결정을 다시 정의합니다. 질문은 "내 제품이 완성되었는가?"가 아니라, "이번 달에 연결하는 누구에게나 제공하기에 이 인터페이스가 충분히 넓은가?"가 되어야 합니다. 제가 정확히 이 이유 때문에 여섯 개의 수직적 기능(verticals)을 모두 출시한 뒤에 제출했습니다. 여섯 개가 적절한 제품이었기 때문이 아니라, 그 이후에 추가한 도구들은 처음에 도착한 사람들에게는 보이지 않았을 것이기 때문입니다.

당신의 리스팅(listing)은 별도의 복사본이며, 스스로 업데이트되지 않습니다

저는 몇 주가 지난 후에 제 퍼블리셔 설정(publisher settings)을 주의 깊게 읽고 나서야 이 사실을 발견했습니다.

당신의 리스팅은 도구 이름의 자체 복사본을 보유합니다. 제출 시 마법사(wizard)는 라이브 서버(live server)를 조사하여 발견된 도구 이름들을 기록합니다. 그 목록은 편집 가능한 필드로서 리스팅에 머물게 되며, 당신의 서버를 따라가지 않습니다. 일곱 번째 도구를 출시하더라도, 직접 가서 수정하기 전까지 리스팅은 여전히 여섯 개만을 광고하며, 그 수정 사항은 라이브(live) 상태가 되기 전에 검토를 거쳐야 합니다.

이것이 들리는 것보다 더 중요한 이유: 설정 페이지에는 **"광고된 이름들이 커넥터 제안(connector suggestions)을 구동한다"**라고 명시되어 있습니다. 즉, 발견 인터페이스(discovery surface)는 서버가 아닌 리스팅을 읽습니다. 리스팅이 광고하지 않는 도구는 서버가 완벽하게 제공하고 있더라도 제안 목록에는 나타나지 않습니다. 클라이언트 측 캐시(client-side cache)와 이 문제를 고려하면, "나중에 추가하자"는 전략은 보기보다 훨씬 취약한 선택지입니다.

암기할 가치가 있을 만큼 일관성이 없는 나머지 편집 규칙들은 다음과 같습니다:

• Listing metadata (태그라인 (tagline), 설명 (description), 카테고리 (categories), 링크 (links), 아이콘 (icon)): 수정 가능하며, 라이브(live) 상태가 되기 전에 검토를 거칩니다. 이미 게시된 리스팅에 이 항목들을 일괄 제출하여 어떤 일이 일어나는지 지켜보았습니다. 상태는 Published로 유지되되, 옆에 "검토 중인 변경 사항 대기 중 (pending changes in review)"라는 메모가 표시됩니다. 편집을 한다고 해서 리스팅이 목록에서 내려가지는 않습니다.
• Advertised tool and prompt names (광고된 도구 및 프롬프트 이름): 수정 가능하며, 검토를 거칩니다.
• Testing instructions for reviewers (검토자를 위한 테스트 지침): 즉시 저장되며, 별도의 검토가 없습니다.
• Use cases, data handling, compliance answers (사용 사례, 데이터 처리, 규정 준수 답변): 게시되면 영구적으로 잠깁니다 (locked permanently). 이를 변경하려면 검토 팀에 이메일을 보내야 합니다.
• Display name (표시 이름): 수정 가능하지만, 전체 재검토를 강제하며 기존 사용자에게 영향을 미치는 것으로 플래그(flag)가 지정됩니다. 슬러그 (slug)는 절대 변경되지 않습니다.

따라서 제출하기 전에 가장 신중하게 고민해야 할 필드들은 여러분이 예상하는 것들과 다릅니다. 규정 준수 답변이 단방향(one-way)이라는 사실을 아무도 경고해주지 않습니다.

해당 페이지에서 수정할 수도, 신청할 수도 없는 단 한 가지는 Verified (인증) 티어입니다. 이에 대해서는 아래에서 더 자세히 다루겠습니다.

위젯은 렌더링됩니다 — 모바일에서도 포함

제3자 (third-party) 커넥터의 MCP Apps 위젯이 실제로 claude.ai에서 렌더링되는지, 아니면 그것이 퍼스트 파티 (first-party) 통합 전용인지에 대한 명확한 답변은 어디에도 없었습니다. 결론부터 말하자면, 렌더링됩니다. 웹과 모바일 앱 모두에서 가능하며, csp.resourceDomains를 통해 선언된 외부 도메인에서 이미지를 로드하고, 버튼 클릭 시 네이티브 "외부 링크 열기" 확인 창이 나타납니다.

[

A tours widget rendered inside a Claude conversation: photo cards with ratings, durations, prices and book buttons<br> ]

한 가지 주의사항: 위젯을 렌더링하는 도구는 인터랙티브 (interactive)로 분류되며, 이는 도구 레지스트리 (tool registry)에서 옵트인 (opt-in) 게이트를 거쳐야 함을 의미합니다. 이미 귀하의 서버를 연결한 사용자에게는 이것이 호출을 차단하지 않지만, 발견 가능성 (discovery)을 기대하고 있다면 추가로 고려해야 할 사항입니다.

승인 후: 두 가지 티어

디렉토리는 두 가지 티어로 나뉘며, 이는 배지가 암시하는 것보다 더 중요합니다:

• Community — 자동화된 검사(automated checks)를 통과했습니다. 이것이 기본 결과입니다.
• Verified — Anthropic에 의해 수동으로 검토되며, 체크 표시가 붙습니다.

Community에서 Verified로 넘어가는 공개된 프로세스는 존재하지 않습니다 — 기준도, 트리거도, 신청할 수 있는 방법도 없습니다. 고객 지원팀에 직접 문의했으나 기준이 그들의 지식 베이스(knowledge base)에도 없다는 답변을 받았습니다. 그 이후 검토 팀에 질문을 던져두었으나 아직 답변을 듣지 못했습니다. 만약 귀하의 계획이 Verified가 정해진 일정에 따라 도입되는 것에 의존하고 있다면, 현재로서는 의존할 수 있는 일정이 없습니다. 만약 이것이 실제로 어떻게 작동하는지 알고 계신다면, 진심으로 듣고 싶습니다.

제가 처음에 틀렸던 점: 저는 채팅창 내의 "도움이 될 수 있는 커넥터(Connectors that could help)" 제안 패널이 Verified 등급에 따라 제한된다고 가정했습니다. 제 테스트에서 Community 티어의 커넥터는 무시된 반면, 세 개의 Verified 커넥터는 제안되었기 때문입니다. 하지만 문서는 다르게 말합니다 — 모든 디렉토리 항목이 자격이 있으며, **랭킹은 사용량 기반(usage-based)**입니다. 따라서 이것은 배지(badge)에 의한 제한이 아니라 순위(rank)에 의한 제한입니다. 사용량이 거의 제로에 가까운 커넥터는 Verified 여부와 상관없이 하단으로 밀려납니다. 첫날의 실질적인 결과는 같지만, 전략은 완전히 다릅니다. 레버(lever)는 배지가 아니라 사용량입니다.

권한에 관한 놀라운 사실

이것은 제가 문서 어디에서도 찾을 수 없었던, 제출을 권장하는 단 하나의 가장 강력한 근거입니다.

URL을 통해 커스텀(custom) 커넥터를 연결할 때, 모든 도구의 기본값은 "요청(ask)"으로 설정됩니다. 즉, 사용자가 수동으로 설정을 변경하기 전까지는 새로운 채팅이 시작될 때마다 사용자에게 권한 승인 프롬프트가 나타납니다.