학생 한 명이 npm 키워드·MCP 레지스트리·깃허브 토픽으로 모은 MCP 서버 248곳에 도구 목록만 물어보는 호출을 하루 사이 두 번 넣어 도구 정의 7,022개를 대조했더니, 14곳(5.6%)에서 설명문 54개가 다시 쓰였고 설명문은 한 글자도 안 바뀐 채 스키마나 표시만 바뀐 게 17건, 도구는 9개가 늘고 7개가 사라졌어요. 서버별 기록을 열어 보면 @ironbee-ai/devtools 는 도구 6개가 없어지고 시나리오 저장 방식이 '바뀐 키만 보내라'는 RFC 7386 부분 수정에서 통째 덮어쓰기로 뒤집혔고, context-mode 의 ctx_execute 에선 destructiveHint: true 가 담긴 표시 블록이 통째로 빠졌는데, 노션·클라우드베이스 서버의 변경은 목록 순서만 바뀐 것이라 뜻은 그대로였어요. 다만 악의로 보이는 변경은 한 건도 없었고, 측정한 사람이 바뀌면 연결을 막아 주는 도구를 만드는 중이라 저장소는 측정 하루 전에 만들어졌으며, 본인도 '두 번 돌린 걸로는 추세라 할 수 없다'고 적어 뒀어요.
용어 풀이
- MCP
- Model Context Protocol. 에이전트가 외부 도구·데이터에 붙는 연결 표준
- destructiveHint
- MCP 도구가 '되돌릴 수 없는 일을 한다'고 스스로 붙여 두는 표시
- RFC 7386
- 바뀐 키만 보내 문서를 부분만 고치는 방식(JSON Merge Patch)을 정한 표준 문서
- npx
- npm 패키지를 따로 설치하지 않고 그 자리에서 받아 실행하는 명령
- stdio
- 프로그램을 직접 띄워 표준 입출력으로 주고받는 연결 방식
운영자 인사이트
승인은 한 번인데 도구 설명·스키마는 서버가 새 판을 낼 때마다 바뀌고, 바뀌었다고 다시 물어보는 절차는 없다는 게 이 조사의 요지예요. npx 로 최신 판을 끌어오는 서버가 있다면 버전부터 정확히 고정하고, 받아 온 도구 목록을 해시로 남겨 배포 검사에서 대조해 두세요 — 남의 도구를 믿느냐 마느냐 이전에, 바뀐 사실을 알 수 있게 해 두는 게 먼저예요.
여러 관점으로 보기