MCP 서버를 프로그램용 규격(API)이 아니라 사람이 쓰는 화면(UI)처럼 설계하라는 글이에요. 네 가지 규칙을 제시해요. ① 접속점(엔드포인트)이 아니라 '사용자가 뭘 하려는가'에서 출발해 도구를 정의하기, ② 도구 개수는 15~20개 이하로 줄이고 이름은 명확하게·입력 구조는 평평하게, ③ 도구 설명이 곧 문맥이므로 이름과 겹치지 않게 명령형으로 구체적으로 쓰고 기본값·예외·도움 되는 오류 메시지를 남기기, ④ 응답은 꼭 필요한 항목만 걸러 내보내기(예시로 802자 응답을 필요한 3개 항목만 남겨 79자로 90% 줄임)예요. 깃허브(GitHub) MCP 서버가 도구 27개로만 1만 8천 토큰을 먹는 것처럼, 불필요한 토큰이 사용자 프롬프트·문맥과 자리를 다투는 문제를 풀자는 취지예요.
용어 풀이
- MCP(Model Context Protocol)
- AI 에이전트가 외부 도구·데이터에 접근하게 해 주는 표준 규약.
- API
- 프로그램끼리 기능·데이터를 주고받게 하는 규격.
- UI
- 사람이 화면에서 정보를 보고 조작하는 사용자 접점.
- 스키마(schema)
- 데이터가 어떤 항목·구조로 이뤄지는지 정한 형식.
- 토큰(token)
- 언어 모델이 글을 처리하는 최소 단위이자 문맥 용량·요금의 기준.
운영자 인사이트
'대부분의 MCP 서버는 필요 없다'는 최근 담론이 서버를 만들지 말지를 물었다면, 이 글은 '만들기로 했다면 어떻게'를 다뤄 각도가 겹치지 않아요. 요지는 토큰 효율이에요 — 도구 수를 줄이고 응답을 걸러 문맥을 아끼면 모델이 사용자 의도에 더 집중해요. 에이전트가 실제로 쓰는 도구를 만드는 팀에 바로 적용할 실무 지침이에요.
여러 관점으로 보기
- 원본 설계론(UI처럼) 사용자 의도에서 출발해 도구는 15~20개 이하로 줄이고 설명을 문맥처럼 쓰고 응답은 필요한 항목만 걸러 내라고 해요. Bump.sh
- 보완·대조 담론 이블 마션스는 '대부분의 MCP 서버는 필요 없다'며 스킬·CLI·직접 API가 더 나을 때가 많다고 봐요 — '만들지 여부'를 다룬 다른 각도예요. Evil Martians