MCP 도구 오버헤드 측정: 26개면 호출당 $0.03
목차
에이전트에 MCP 서버 하나를 연결하면 실제 작업을 시작하기도 전에 호출당 비용이 붙는다. GitHub 서버의 도구 26개는 실제 사용 여부와 관계없이 Claude Opus 4.8 호출마다 $0.0302를 추가한다. 계량 내역을 보기 전에는 이 구조가 드러나지 않는다. 비용 규모는 연결한 도구 수보다 사용하는 모델에 더 크게 좌우되며, 대부분은 줄일 수 있다. 모델군 5개, 실제 MCP 서버 5개, 도구 0개부터 40개까지 늘린 합성 테스트, caching과 경량화로 비용을 줄이는 방법까지 전체 경로를 측정했다.
TL;DR
- 도구 정의는 API를 호출할 때마다 input token으로 다시 과금된다. Claude Opus 4.8에서 소형 도구 하나는 401 token으로 측정됐다.
- 같은 도구 세트도 Claude가 GPT-5.6보다 2.7배 많은 token을 사용했다. 도구당 측정치는 각각 173과 64였다.
- 실제 GitHub MCP 서버의 도구 26개는 호출당 Opus 4.8에서 $0.0302, Gemini 3.6 Flash에서 $0.0029로 10배 차이 난다.
- 명시적 caching을 적용하면 매번 따라붙는 block의 비용을 10분의 1로 줄일 수 있다. 단, 최소 크기에 못 미치는 도구 세트는 cache할 수 없고, 도구 하나만 바꿔도 block 전체가 다시 과금된다.
MCP 서버는 어떻게 input token으로 바뀌는가?
세 단계를 거치며, 비용은 마지막 단계에서만 발생한다. 다만 이 단계가 호출할 때마다 반복된다. 먼저 범위를 짚고 가자. MCP 서버가 제공하는 primitive는 tools, resources, prompts 세 가지다. 이 중 상시 비용이 드는 것은 tools뿐이다. API 요청마다 모든 schema를 tools parameter에 담아야 하기 때문이다. Resources와 prompts에는 전용 API field가 없다. 해당 content를 실제로 대화에 가져올 때만 token 비용이 발생한다. 1단계에서는 MCP protocol을 사용한다. 에이전트 client가 JSON-RPC를 통해 서버에 tools/list를 요청하고 schema를 받는다. session당 한 번 실행되며 model에는 아무 요청도 보내지 않는다. 2단계에서는 client가 해당 schema를 API의 tools parameter 형식으로 변환하면서 annotations, outputSchema 같은 MCP 전용 field를 제거한다. 이 단계도 무료다. 3단계에서는 provider가 요청마다 schema를 숨겨진 prompt text로 rendering한다. API는 stateless이므로 model이 어떤 도구가 있는지 기억할 수 없기 때문이다. 이 rendering된 text에는 도구 사용 여부와 관계없이 호출할 때마다 전체 input 요율이 적용된다.

가장 단순한 예를 보자. user message가 “Reply OK”뿐인 요청은 Opus 4.8에서 prompt token 11개를 사용한다. 여기에 parameter 2개와 한 줄짜리 description을 가진 평범한 get_weather 도구 하나를 추가하면 같은 요청이 412 token으로 늘어난다. 이 도구 하나가 포함될 때마다 호출당 401 token, $0.002가 추가되는 셈이다. 실제 전송한 크기와도 차이가 크다. 도구 JSON text는 약 130 token에 불과하지만, provider가 rendering한 결과는 거의 3배였다.
모델별 도구 하나의 비용은 얼마인가?
대부분의 팀이 예상하는 것보다 모델에 따른 차이가 훨씬 크다. parameter 3개와 한 줄 description으로 구성한 동일한 합성 도구 세트를 0개부터 40개까지 늘려 5개 모델군에 전송하고 과금량의 차이를 확인했다.
| 모델 | 고정 오버헤드 (tools 사용) | 도구당 증가량 | 동일한 도구 40개 |
|---|---|---|---|
| Claude Opus 4.8 | 290 | 173 | 7,210 |
| GLM 5.2 | 96 | 120 | 4,896 |
| Kimi K3 | 37 | 99 | 3,997 |
| Gemini 3.6 Flash | ≈0 | 72 | 2,871 |
| GPT-5.6 Terra | 98 | 64 | 2,658 |
같은 도구인데도 최대 2.7배 차이 났다. 이 그룹에서는 Claude가 가장 장황한 tool harness를 rendering했고, GPT-5.6이 가장 간결했다. 전송한 JSON과의 관계도 모델마다 다르다. Claude의 과금량은 wire payload의 byte 수를 4로 나눈 단순 추정치보다 약 1.36배 많았다. 반면 GPT-5.6과 Gemini는 그 추정치의 절반 정도였다. Tool block의 token 수는 모델군 간에 그대로 적용할 수 없다. schema 기준이 아니라 모델별로 예산을 잡아야 한다.
실제 MCP 서버의 호출당 비용은 얼마인가?
공식 MCP repository에 있는 실제 서버 5개를 수정하지 않고 standard field mapping으로 변환한 뒤, 호출마다 따라붙는 오버헤드를 측정한 결과다.
| MCP 서버 (도구 수) | Opus 4.8 | GPT-5.6 Terra | Gemini 3.6 Flash | Kimi K3 | GLM 5.2 |
|---|---|---|---|---|---|
| GitHub (26) | 6,043 tok / $0.0302 | 2,076 / $0.0052 | 1,931 / $0.0029 | 3,152 / $0.0095 | 4,077 / $0.0022 |
| Filesystem (14) | 2,785 / $0.0139 | 1,254 / $0.0031 | 1,200 / $0.0018 | 1,574 / $0.0047 | 1,772 / $0.0010 |
| Everything (13) | 1,942 / $0.0097 | 798 / $0.0020 | 663 / $0.0010 | 970 / $0.0029 | 1,176 / $0.0006 |
| Memory (9) | 1,670 / $0.0083 | 554 / $0.0014 | 491 / $0.0007 | 815 / $0.0024 | 1,057 / $0.0006 |
| Sequential-thinking (1) | 1,764 / $0.0088 | 912 / $0.0023 | 815 / $0.0012 | 870 / $0.0026 | 1,015 / $0.0006 |
마지막 행에서 두 가지를 알 수 있다. Sequential-thinking이 제공하는 도구는 하나뿐이지만, 5개 모델군 중 4개에서 도구 9개인 Memory보다 비용이 더 많이 든다. 하나뿐인 description이 매우 길기 때문이다. 도구 수가 아니라 rendering된 크기를 봐야 한다. 에이전트 개발자에게 더 의외인 결과는 첫 번째 행이다. 호출 10회로 구성된 에이전트 episode 내내 GitHub 도구 세트를 포함하면 실제 작업을 시작하기도 전에 Opus 4.8에서는 $0.30, Gemini에서는 $0.03가 든다. 정확히 10배 차이다. GLM 5.2는 Gemini보다 2배 넘는 token을 과금하면서도 금액은 더 낮다. 저렴한 list rate가 장황한 renderer의 영향을 상쇄하기 때문이다. Token과 실제 금액은 따로 예산을 잡아야 한다.
에이전트는 도구 세트 중 얼마나 사용하는가?
호출당 실제로 사용하는 비율은 매우 낮다. 그래서 이 비용이 더 낭비처럼 느껴진다. 에이전트 suite의 tooling scenario에서는 일반적인 episode의 호출 3회 모두에 도구 8개가 포함되지만, 각 호출에서 실행하는 도구는 최대 하나였다. 도구 하나를 쓰기 위해 호출마다 schema 8개의 비용을 내는 구조다. Opus 4.8의 측정 요율을 적용하면 도구 8개의 block은 호출당 약 1,674 token이다. Episode 하나에서 schema를 전달하는 데만 약 5,000 token이 든다. Tool-loop scenario는 조건이 나은 편이다. 도구가 3개뿐이고 거의 모든 호출에서 사용된다. 그래도 loop의 호출 4회에서 5회 모두에 같은 block을 다시 전송한다. 기록에서 확인한 일반적인 패턴은 명확하다. 호출당 도구 사용량이 하나를 넘는 경우는 드물다. 따라서 도구 세트의 호출당 비용은 에이전트가 실제로 수행한 작업이 아니라 연결한 도구에 비례한다.
Caching으로 도구 비용을 상쇄할 수 있는가?
적합한 모델에서는 대부분 가능하지만, 측정 과정에서 세 가지 함정을 확인했다. Claude Opus 4.8에서는 tool block 자체를 cache 가능한 prefix로 지정할 수 있다. 마지막 도구에 cache_control을 표시하자 도구 20개짜리 block이 한 번 기록됐다. 3,682 token에 1.25배의 write premium이 적용됐다. 이후 모든 호출에서는 0.1배 요율로 다시 읽어 실질적인 반복 비용이 90% 줄었다. Kimi K3의 automatic caching은 별도 설정 없이 더 높은 성능을 보였다. 두 번째 호출에서 block의 2,112 token 중 2,048 token, 즉 97%가 cache에서 왔다. 기존과 같은 256-token block 단위였다. GPT-5.6의 명시적 breakpoint도 같은 구조로 과금된다. 해당 모델군의 출시 첫날 측정 결과, write는 1.25배, read는 0.1배였다. Gemini의 implicit cache에서는 지금까지 측정한 다른 결과와 마찬가지로 tool block을 미리 채운 probe 3회 모두 hit가 없었다. 여기서 할인은 계획에 반영할 수 있는 요소가 아니라 생기면 좋은 rebate 정도로 봐야 한다.
첫 번째 함정은 최소 크기다. Claude에서 도구 2개짜리 block은 약 655 token으로 cache 최소 크기인 1,024 token에 못 미친다. 명시적으로 표시해도 작은 도구 세트는 전혀 cache할 수 없다. 모델별 최소 크기에 따라 이 최적화를 적용할 수 있는지가 결정된다. 두 번째는 변경 가능성이다. Tool block은 prompt의 맨 앞에 있으므로 도구 목록을 변경하면 그 뒤에 있는 cache까지 모두 무효화된다. 비용도 직접 측정했다. Claude Opus 5에서 cache된 도구 20개짜리 세트에 도구 하나를 추가하자 4,082-token block 전체가 write premium으로 다시 기록됐다. Session 중에는 도구 목록을 고정해야 한다. 그렇지 않으면 변경할 때마다 write 비용을 다시 내야 한다. 세 번째 함정인 고정 조건을 완화하기 위해 Anthropic은 mid-conversation tool changes beta를 만들었다. Opus 5용으로 문서화된 이 기능은 turn 사이에 도구가 바뀌어도 cache를 무효화하지 않는다. 도구를 많이 사용하는 에이전트라면 주시할 기능이다.
Tool block 자체를 줄이는 방법은?
설명보다 parameter부터 줄여야 한다. 도구 20개짜리 block에서 description을 짧은 단일 절로 줄이자 10%가 절감됐다. 도구별 parameter를 3개에서 1개로 줄이면 34%가 절감됐다. 둘 다 적용하면 3,768 token에서 2,128 token으로 44% 줄었다. Token을 가장 많이 차지하는 부분은 parameter schema, 즉 name, type, 중첩된 description이다. Description만 다듬고 schema는 계속 늘리는 일반적인 접근과 반대다.
더 효과적인 방법은 사용하지 않을 도구를 연결하지 않는 것이다. MCP 서버를 하나 추가할 때마다 해당 block 전체가 모든 호출에 포함된다. 설정 한 줄을 더 추가했을 뿐인데 비용이 2배가 될 수도 있다. Client가 filtering을 지원한다면 서버 도구 중 일부만 등록해 반복 비용을 거의 비례해서 줄일 수 있다. GitHub 서버의 도구 26개 중 5개만 유지하면 서버의 평균 도구 크기를 기준으로 Opus 4.8의 $0.0302가 약 $0.007로 줄어든다. 여러 모델군을 함께 사용한다면 앞서 확인한 2.7배 차이도 고려해야 한다. 예산을 다시 산정하지 않고 동일한 에이전트를 Gemini에서 Claude로 옮기면 도구 전달에 드는 token이 거의 3배가 된다.
FAQ
MCP 자체에서 token 비용이 발생하는가?
아니다. MCP protocol, discovery, JSON-RPC, tool invocation plumbing은 model을 거치지 않으므로 과금되지 않는다. 비용은 client가 서버 schema를 API의 tools parameter로 전달할 때 발생한다. Provider가 이를 호출마다 과금 대상 prompt text로 다시 rendering하기 때문이다. MCP가 비용에 미치는 영향은 규모다. 도구 26개를 설정 한 줄로 연결할 수 있게 됐고, 그 뒤부터 schema 26개가 모든 호출에 따라붙는다.
사용하지 않는 도구도 비용이 드는가?
그렇다. 사용한 도구와 비용이 완전히 같다. Model은 어떤 도구를 실행할 수 있는지 판단하기 위해 호출마다 모든 schema를 읽어야 한다. 에이전트 suite 기록에서는 호출당 실행된 도구가 최대 하나였지만, 매번 전체 세트가 과금됐다. 연결만 하고 사용하지 않는 서버에는 전달 비용만 발생한다. Caching으로 할인할 수는 있지만, 비용 자체를 없애려면 도구를 줄이거나 연결을 해제해야 한다.
MCP resources와 prompts도 tools처럼 token 비용이 드는가?
아니다. Tools에만 호출당 전달 비용이 발생한다. 요청마다 모든 schema를 tools parameter로 다시 보내기 때문이다. Resource는 client가 읽고 content를 대화에 삽입할 때만 과금된다. 이때부터는 가져온 일반 문서와 동일한 input이며, 동일한 계층화 원칙을 적용해야 한다. 자주 바뀌는 resource content는 cache breakpoint 뒤에 배치해야 한다. Prompt template도 실행할 때 생성된 text에 대해서만 과금된다. 연결된 서버에서 사용하지 않은 resources와 prompts는 비용이 들지 않는다. MCP integration 이후 청구액이 늘었다면 tools부터 확인해야 한다.
도구 목록을 바꾸면 prompt cache가 무효화되는가?
전체가 무효화된다. Tool block은 prompt의 맨 앞에 rendering되므로 변경하면 해당 block과 그 뒤에 cache된 모든 내용이 다시 기록된다. 도구 하나를 추가했을 때 4,082-token block에 1.25배 premium이 적용돼 다시 과금되는 것을 측정했다. Session별로 도구 목록을 고정하고, 목록 변경은 한 번에 묶어서 처리해야 한다. Anthropic의 mid-conversation tool changes beta도 주시할 필요가 있다. Opus 5에서 바로 이 비용을 없애도록 설계된 기능이다.
2026-07-31에 Synthorai gateway를 통해 측정했다. 5개 모델군을 대상으로 합성 도구 단계별 테스트(도구 0-40개, n=2)와 실제 MCP 서버 도구 세트 5개를 사용했다. Schema는 공식 서버에서 JSON-RPC tools/list를 통해 실시간으로 가져왔다. Caching probe에는 salted prefix와 호출별 cache itemization을 적용했다. 에이전트 사용률은 에이전트 비용 연구에 사용한 suite 기록에서 가져왔다. GPT-5.6 caching multiplier는 출시 첫날 작성한 비용 가이드의 측정치를 인용했다. 금액은 gateway meter에서 확인한 과금 비용의 차이다. Gateway는 input list rate를 적용한다. 요율과 rendering 동작은 바뀔 수 있으므로 실제 사용 기록으로 확인해야 한다.