MCP 도구 스키마가 컨텍스트를 먹는다면, 화면으로 먼저 재보세요

프론트엔드 개발자 눈으로 보면 MCP 도구 스키마는 번들 크기와 같은 문제예요. 쓰지도 않는 컴포넌트를 초기 번들에 다 넣으면 첫 화면이 느려지듯, 에이전트 세션에 연결된 도구의 입력 스키마는 호출 여부와 상관없이 매 턴 컨텍스트에 실려요. 그래서 "어떤 도구를 CLI로 내릴까"를 감으로 정하지 않고 화면으로 재보기로 했어요.

재료는 tools/list 응답 하나

MCP 서버는 tools/list 요청에 도구 이름과 inputSchema를 돌려줘요. 이 응답을 JSON 파일로 저장해 두면 나머지는 순수 프론트엔드 작업이에요. 직접 만들어 보니 파일 3개면 충분했어요. 저장한 JSON, 크기를 계산하는 컴포넌트, 그걸 얹는 페이지. 처음 띄우기까지 10분 정도 걸렸어요.

크기는 JSON.stringify(tool.inputSchema).length로 잽니다. 토큰 수를 정확히 세는 게 아니라 순위를 매기는 게 목적이라 문자 수면 충분해요.

const rows = tools
  .map((t) => ({ name: t.name, size: JSON.stringify(t.inputSchema).length }))
  .sort((a, b) => b.size - a.size);

기준선은 슬라이더 하나로

임계값은 상수로 박지 않고 <input type="range"> 하나를 뒀어요. 라이브러리 없이 네이티브 요소면 끝나는 일이에요. 돌려 보니 막대 목록을 눈으로 훑는 것보다 슬라이더를 밀면서 "여기서 자르면 몇 개가 넘어가나"를 보는 쪽이 판단이 빨랐어요. 숫자 컬럼엔 font-variant-numeric: tabular-nums를 줘서 자릿수가 흔들리지 않게 했고, 넘는 행은 한쪽 테두리 띠 대신 이름 앞에 색 점 하나만 찍었어요.

내릴지 말지는 2축으로

크기만 보면 틀려요. 자주 쓰는 큰 도구를 내리면 매번 CLI 왕복이 생겨서 오히려 손해예요. 그래서 축을 하나 더 붙였어요. 호출 빈도예요.

제가 잡은 기준선은 스키마 5,000자 이상, 호출 주 1회 미만이에요. 두 조건을 다 만족하는 도구만 CLI 래퍼로 내리고, 에이전트에겐 "이 작업은 이 명령을 실행하라"는 한 줄만 남겨요. 적용해 봤더니 디자인 파일을 통째로 다루는 도구나 배포 플랫폼 관리 도구처럼 스키마가 길고 가끔 쓰는 것들이 먼저 걸렸어요. 반대로 파일 읽기처럼 작고 잦은 도구는 그대로 두는 게 맞았고요.

플랜씨 계산기 화면을 손볼 때 이 패널을 열어 두고 작업했는데, 세션에 실제로 필요한 도구가 몇 개 안 된다는 게 눈에 보이더라고요. 라이프케어로그처럼 혼자 여러 서비스를 굴리면 세션마다 붙는 도구 묶음이 제각각이라 이런 표가 더 도움이 돼요.

빈도 데이터가 없다면

테스트해 보면 처음엔 호출 빈도 축이 비어 있을 거예요. 로그가 없으면 "지난주에 한 번이라도 썼나"를 체크박스로 직접 표시하는 걸로 시작해도 돼요. 정밀한 계측보다 4칸 중 어디에 놓이는지가 먼저예요.

정리하면 이래요. 스키마 크기는 문자 수로, 빈도는 체크박스로라도, 기준선은 슬라이더로. 화면에 올리는 순간 "뭘 내릴까"가 취향 문제에서 표 읽기 문제로 바뀌어요.