인기 MCP 서버 3분의 1이 낙제점

AI 에이전트에 외부 도구를 연결하는 표준인 MCP(모델 컨텍스트 프로토콜) 서버 상당수가, 규격은 완벽히 지키면서도 정작 AI가 제대로 쓰지 못하는 상태라는 진단이 나왔다. 한 머신러닝 엔지니어가 인기 MCP 서버 36개를 자동 채점한 결과 3분의 1이 D 또는 F 등급을 받았고, 여기에는 몽고DB·노션·에어테이블 같은 공식 서버도 포함됐다.

무슨 일인가

필자는 MCP 서버를 점검하는 채점 도구 '엠씨피그레이드(mcpgrade)'를 만들어, 명령 한 줄로 각 서버가 에이전트 친화적인지를 점수화했다. 규격 준수(전송 방식·스키마 형태)는 통과하지만, 정작 모델이 올바른 도구를 고르고 인자를 채우는지는 프로토콜이 보장하지 못한다는 문제의식에서 출발했다. 실제로 상위 A등급은 15개(브레이브 서치·엑사·슬랙 등)에 그친 반면, 하위 11개에는 유지보수가 활발한 상용 서버들이 대거 포함됐다.

핵심 짚어보기

가장 두드러진 원인은 설명 없는 파라미터의 만연이었다. 예컨대 최하위권 서버는 전체 오류 134건 중 132건이 '파라미터에 설명이 없음'이었다. 모델은 url이라는 이름과 타입만 받을 뿐, 어떤 URL을 어떤 형식으로 넣어야 하는지 알 수 없다는 뜻이다. 뿌리는 대개 같다. 스키마를 자동 생성 도구로 뽑아내고 설명(.describe())을 아무도 붙이지 않은 것이다.

또 하나의 발견은 문제는 도구 개수가 아니라 문서화 규율이라는 점이다. 도구 15개짜리 서버가 꼼꼼한 설명 덕에 A등급(96점)을 받은 사례가 있었다. 반대로 큰 카탈로그는 도구 이름이 서로 헷갈리기 쉬워, 실제 테스트에서 모델이 '범위 밖 요청'을 절반만 거절하고 나머지는 그럴듯한 엉뚱한 도구를 불러 실행했다. 아무 일도 하지 말아야 할 때 뭔가를 저지르는, 가장 위험한 실패다.

1인기업 실전 적용 포인트

• 직접 만든 MCP 도구가 있다면, 지금 열어 설명 없는 파라미터의 개수를 세고 채워라. 필자의 표현처럼 에이전트 신뢰성을 높이는 가장 가성비 좋은 한 시간이 될 수 있다.
• 파라미터 설명에는 형식과 예시값을 함께 적어라. '문자열'이 아니라 '예: https://로 시작하는 전체 URL'처럼.
• 서드파티 MCP 서버를 붙일 때는 도구 설명이 촘촘한 것을 우선 고르라. 규격 통과 여부보다 '모델이 헷갈리지 않게 쓰였는가'가 실사용 안정성을 좌우한다.
• 도구가 많아질수록 이름 충돌이 늘어 오작동 위험이 커지므로, 꼭 필요한 도구만 노출하고 이름을 뚜렷이 구분하라.

전망 / 주의점

이 진단은 에이전트 시대의 병목이 '엔지니어링'보다 '글쓰기'에 있음을 보여 준다. 다만 이번 결과는 특정 시점의 정적 분석이라는 한계가 있다. 실제로 한 문서화 도구는 지적을 받은 뒤 곧바로 파라미터 설명을 보강해 C에서 만점으로 뛰어올랐다. 가시화되면 생태계는 빠르게 개선된다는 신호다. 내 도구를 만들든 남의 것을 붙이든, 도구 설명의 품질을 성능만큼 챙기는 것이 앞으로의 기본기다.

출처: Teng Li 블로그 (https://tengli.dev/posts/mcp-servers-failing-agents.html)