tools/list는 MCP 서버의 준비 상태를 확인하는 지표가 아닙니다

mcp-probe의 첫 번째 버전은 다음과 같은 명백한 사항들을 확인했습니다:

• MCP 서버가 초기화될 수 있는가?
• tools/list가 작동하는가?
• 도구 스키마 (tool schemas)가 존재하는가?

이는 유용했지만, 충분하지 않았습니다.

실제 MCP 워크플로우 (workflows)를 더 많이 테스트할수록 문제는 더욱 명확해졌습니다:

tools/list는 자기 보고 (self-report)입니다. CI (지속적 통합)에는 영수증 (receipt)이 필요합니다.

MCP 서버는 깨끗한 도구 카탈로그 (tool catalog)를 광고할 수 있지만, OAuth 핸드오프 (handoff), 스코프 (scopes), 다운스트림 자격 증명 (downstream credentials), 행 제한 (row limits), 테넌트 경계 (tenant boundaries) 또는 응답 형태 (response shapes)가 깨져 있기 때문에 모든 실제 호출에서 실패할 수 있습니다.

따라서 mcp-probe의 최신 릴리스는 "프로세스가 시작되는가?"보다는 "CI가 에이전트 (agent)가 실제로 의존하는 계약 (contract)을 강제하고 있는가?"에 더 집중합니다.

새로운 부트스트랩 (bootstrap) 흐름

npx @k08200/mcp-probe@latest init \
  --target @your-org/your-mcp-server \
  --discover \
...

이 명령은 다음을 생성합니다:

• mcp-probe.config.json
• .mcp-probe.json
• .github/workflows/mcp-probe.yml

중요한 부분은 --discover 중에 일어나는 일입니다.

mcp-probe는 서버에 연결하여 라이브 tools/list 카탈로그를 읽고, 관찰된 도구 스키마 (tool schemas)로부터 시작 계약 (starting contract)을 생성합니다.

스키마 인지 사이드카 샘플 (Schema-aware sidecar samples)

이전에 생성된 샘플들은 너무 단순했습니다. 만약 스키마가 다음과 같이 정의되어 있다면:

{
  "type": "object",
  "required": ["location", "count"],
...

이전의 폴백 (fallback) 방식은 빈 문자열이나 0 값을 생성했을 수 있습니다. 이는 종종 입력 유효성 검사 (input validation)에 걸려 실제 호출 경로를 테스트하지 못하게 만들었습니다.

v1.11.0은 이제 다음과 같은 스키마 힌트 (schema hints)를 사용합니다:

• default (기본값)
• enum (열거형)
• numeric minimum (숫자 최소값)
• string minLength (문자열 최소 길이)
• nested objects (중첩된 객체)
• array minItems (배열 최소 항목 수)

따라서 생성된 샘플은 다음과 같이 변합니다:

{
  "location": "Chicago",
  "count": 1
...

이는 여전히 시작 단계일 뿐입니다. 특히 상태를 변경(mutating), 관리(admin), 내보내기(export) 또는 환경 조사(environment-inspection) 도구의 경우, 프로덕션 자격 증명 (production credentials)으로 실행하기 전에 생성된 샘플을 검토해야 합니다.

카탈로그 잠금 (Catalog locking)

또 다른 새로운 기능은 --lock-tools입니다.

--discover를 사용하면, mcp-probe는 이제 관찰된 도구(tool) 이름들을 expectedTools에 기록하므로, 필수적인 도구가 사라질 경우 CI(지속적 통합)가 실패하게 됩니다.

--lock-tools를 사용하면 allowedTools 또한 기록하므로, 예상치 못한 도구가 나타날 경우 CI가 실패하게 됩니다.

이는 신뢰도가 낮은 에이전트 접점(agent surfaces)에서 중요합니다. 만약 서버가 갑자기 delete_user, export_all, 또는 rotate_api_key를 노출한다면, 단지 tools/list가 여전히 유효한 JSON을 반환한다는 이유만으로 에이전트가 이를 조용히 사용할 수 있게 되는 것을 원치 않기 때문입니다.

설정 예시:

{
  "timeoutMs": 10000,
  "servers": [
...

영수증 (Receipts)

CI를 위해, 워크플로우는 민감 정보가 삭제된(redacted) 영수증 아티팩트(artifact)를 보관할 수도 있습니다:

npx @k08200/mcp-probe@latest \
  --config mcp-probe.config.json \
  --github-summary \
...

그 영수증이 바로 제가 CI가 신뢰하기를 바라는 대상입니다. 도구를 가지고 있다고 주장하는 서버도 아니고, 나중에 어떤 일이 일어났다고 주장하는 에이전트도 아닌, 경계(boundary)를 대상으로 실제로 실행된 독립적인 프로브(probe)입니다.

사용해 보기

npx @k08200/mcp-probe@latest @modelcontextprotocol/server-memory

GitHub: k08200/mcp-probe

Release: v1.11.0

저는 특히 실제 Datadog, Supabase, 그리고 Gmail MCP 레시피를 찾고 있습니다. 공개된 피스처(fixtures)들도 유용하지만, 진정한 가치는 CI에서 인증 핸드오프(auth handoff), 권한(permission), 테넌트 범위(tenant-scope), 그리고 응답 규약(response-contract) 실패를 잡아내는 데 있습니다.