The #1 Most Popular MCP Server Gets an F

Context

MCP 서버 개발 시 도구 설명 길이와 명명 규칙에 대한 표준이 없어서, 개발자들이 스키마 필드에 시스템 프롬프트 수준의 상세 지시사항을 담고 있다. 그 결과 Context7은 2개 도구만 노출하지만 스키마 로딩 시 1,020개 토큰을 소비하며, 이는 모든 사용자 세션에서 모델의 컨텍스트 윈도우를 낭비한다.

Technical Solution

• 도구 설명을 2,006자에서 200자 이하로 제한: 도구의 기능만 명시하고 사용 방법, 응답 형식, 엣지 케이스는 제외
• 도구 명명 규칙을 하이픈에서 언더스코어로 변경: resolve-library-id → resolve_library_id
• 다단계 선택 프로세스와 응답 형식 정보를 스키마에서 시스템 프롬프트나 README로 이동
• 자동화된 그레이딩 파이프라인 도입: validate, audit, optimize, fix, grade 프로세스를 agent-friend 도구로 구현
• 토큰 효율성을 평가 기준에 포함: 스키마 품질(40%), 토큰 효율성(30%), 모범 사례(30%)로 가중치 설정

Impact

• Context7 예상 최적화 결과: 1,020토큰에서 298토큰으로 71% 감소
• 상위 4개 서버의 평균 토큰: 288개 vs 하위 4개 서버 평균: 2,573개(9배 차이)
• PostgreSQL(1개 도구, 46토큰, A+) vs Context7(2개 도구, 1,020토큰, F) 비교
• SQLite 6개 도구 322토큰 A+, Playwright 78개 도구 7,502토큰 D+ 등 도구 개수와 무관하게 설계 품질이 성능 결정

Key Takeaway

MCP 서버의 인기도와 스키마 품질은 무관하며, 도구 설명을 간결하게 유지하고 상세 지시사항을 시스템 프롬프트로 분리하면 모든 사용자 세션에서 토큰 낭비를 방지할 수 있다.