MCP 서버를 몇 개 연결했더니, 일을 시작하기도 전에 컨텍스트가 줄었다는 질문이 자주 보인다. 도구를 실행하지 않았는데도 수천 토큰이 잡혀 있고, 서버가 늘수록 대화에 쓸 자리가 줄었다는 이야기다.

원인은 MCP 연결 자체보다 도구 설명을 모델에게 언제, 얼마나 보여주는가에 있다. 어떤 AI 앱은 연결된 도구를 처음부터 모두 보여주고, 어떤 앱은 필요한 도구만 나중에 찾는다. 이 차이를 알면 MCP를 끌지, 도구 수를 줄일지, 도구 검색을 켤지 판단하기 쉬워진다.

많은 MCP 도구 중 필요한 도구 세 개만 검색해 작업 컨텍스트에 넣는 흐름.

그림처럼 도구 검색을 사이에 두면 전체 도구의 자세한 설명 대신, 현재 작업에 필요한 도구만 골라 컨텍스트에 넣는다.

도구는 실행 전에 설명서부터 들어간다

MCP 도구는 버튼 이름 하나가 아니다. 최신 MCP 도구 규격은 도구마다 이름, 설명, 입력 스키마, 선택적인 출력 스키마와 동작 정보를 정의한다. 입력 스키마는 어떤 값을 받아야 하는지 적은 형식 설명서다.

날씨 조회 도구 하나만 놓고 보면 짧다. 하지만 GitHub, 브라우저, 데이터베이스, 디자인 도구를 함께 연결하면 설명서가 수십 개로 늘어난다. 각 도구의 매개변수와 설명이 길수록 모델이 먼저 읽어야 할 내용도 커진다.

흐름은 보통 이렇다.

MCP 서버가 도구 목록과 스키마를 제공한다.
AI 앱이 그중 일부 또는 전부를 모델 입력에 넣는다.
모델이 요청에 맞는 도구를 고른다.
AI 앱이 도구를 실행하고 결과를 다시 모델에 보여준다.

여기서 중요한 경계가 있다. MCP 규격은 서버가 tools/list 요청에 도구 목록을 돌려주는 방법을 정한다. 하지만 그 목록을 모델에게 어떤 방식으로 보여줄지는 AI 앱의 구현에 맡긴다. 규격 문서도 사용자 화면이나 노출 방식을 하나로 강제하지 않는다.

컨텍스트 사용량은 클라이언트의 불러오기 방식에 따라 달라진다. 도구를 한꺼번에 싣는 앱과 필요한 순간에 찾는 앱이 같은 양의 토큰을 쓰지는 않는다.

부담은 도구 설명과 실행 결과에서 생긴다

도구가 컨텍스트를 차지하는 지점은 두 군데다.

첫째는 실행 전 도구 설명이다. Anthropic의 MCP 코드 실행 글은 연결한 서버와 도구가 많아질수록 정의를 처음부터 모두 넣는 방식에서 속도와 비용 문제가 커진다고 설명한다. 모델은 실제 요청과 무관한 도구 설명도 함께 보게 된다.

둘째는 실행 뒤 결과다. 문서 전체, 긴 로그, 수천 행의 자료가 도구 결과로 돌아오면 그 내용도 다음 판단을 위한 컨텍스트에 들어간다. 도구 수를 줄여도 결과를 통째로 돌려주면 컨텍스트는 다시 커진다.

그래서 문제를 “MCP 서버가 많다”로만 보면 해결이 어긋난다. 원인을 찾으려면 다음 두 질문을 따로 봐야 한다.

  • 지금 요청에 필요하지 않은 도구 설명까지 먼저 들어오는가?
  • 도구가 돌려준 긴 결과를 모델이 직접 다시 읽고 옮기는가?

앞의 질문은 도구를 고르고 불러오는 시점을 점검한다. 뒤의 질문은 실행 결과가 얼마나 줄었는지 본다.

필요한 도구만 켜는 방법이 가장 단순하다

도구가 몇 개뿐이라면 복잡한 장치부터 붙일 필요가 없다. 이번 작업에 쓰는 서버와 도구만 켜는 방법이 가장 단순하다.

GitHub MCP Server의 도구별 설정은 전체 도구 묶음 대신 자주 쓰는 도구만 고르게 한다. GitHub가 확인한 환경에서는 기본 도구 묶음을 모두 불러올 때보다 자주 쓰는 도구 3~10개만 불러올 때 컨텍스트 사용량이 크게 줄었다.

이 방식은 예측하기 쉽다. 코드 읽기 작업에는 조회 도구만 두고, issue 작성이나 merge처럼 상태를 바꾸는 도구는 필요할 때 별도로 연다. 컨텍스트뿐 아니라 권한 범위도 함께 줄어든다.

다만 서버를 매번 켜고 끄는 일이 번거롭다면 다음 방법이 필요하다.

도구 검색은 설명서를 나중에 불러온다

도구 검색은 처음에는 서버나 도구 묶음의 짧은 소개만 보여준다. 모델이 현재 요청에 필요한 도구를 찾으면 그때 자세한 스키마를 불러온다.

OpenAI의 Tool search는 defer_loading으로 미룬 함수나 MCP 서버 도구를 실행 중에 찾고 불러온다. Cursor의 동적 컨텍스트 탐색은 MCP 도구 설명을 파일로 동기화한 뒤, 에이전트가 필요한 설명만 검색하게 한다. 구현은 다르지만 원리는 같다.

모든 설명을 먼저 싣기
도구 A + 도구 B + 도구 C + ... + 사용자 요청

필요할 때 찾기
도구 묶음의 짧은 소개 + 사용자 요청
                         └─ 필요해진 도구 C의 설명만 불러오기

도구 검색에도 비용이 든다. 검색 호출이 한 단계 늘고, 이름과 설명이 모호하면 엉뚱한 도구를 고른다. 클라이언트의 지원 여부도 제품 문서나 설정에서 확인해야 한다.

도구가 아주 많으면 코드로 묶는다

API가 크고 여러 도구를 이어서 호출해야 한다면 프로그램 방식의 도구 호출을 살펴볼 차례다. 모델이 필요한 API를 찾고 여러 호출과 자료 정리를 코드로 묶는 방식이다. Cloudflare는 이를 Code Mode라고 부른다.

Cloudflare의 Code Mode는 2,500개가 넘는 API 엔드포인트를 각각 도구로 노출하지 않는다. search()와 execute() 두 도구만 모델에 보여주고, 필요한 API를 찾은 뒤 안전한 실행 환경에서 코드를 돌린다. Anthropic의 고급 도구 사용 설명도 도구 검색과 프로그램 방식 호출을 도구 정의와 중간 결과가 커지는 문제의 해법으로 나눈다.

이 방법은 긴 자료를 코드 안에서 먼저 거르고, 모델에는 필요한 결과만 돌려준다. 실행 환경을 안전하게 격리하고 외부 요청과 자격 증명 접근도 통제해야 한다. 도구가 열 개도 안 되는 작은 연결이라면 구축 비용이 토큰 절감 효과보다 커질 가능성이 있다.

토큰 절약과 권한 통제는 다른 문제다

필요한 도구만 불러오면 모델이 보는 설명은 줄어든다. 그렇다고 도구가 안전해지는 것은 아니다.

검색으로 나중에 불러온 도구도 메일을 보내고, 데이터를 바꾸고, 배포를 실행한다. 최신 MCP 규격은 도구를 모델이 고르더라도 사용자에게 호출을 거부할 선택권을 주라고 권고한다. 도구 검색은 컨텍스트 문제를 줄이고, 승인·권한·실행 기록은 상태 변경의 위험을 줄인다.

둘을 나누면 확인 순서가 선명해진다.

  1. 지금 작업에 필요한 서버와 도구만 노출한다.
  2. 도구가 많으면 클라이언트의 도구 검색이나 늦은 불러오기를 확인한다.
  3. 긴 결과는 도구나 안전한 코드 실행 환경에서 먼저 줄인다.
  4. 쓰기, 전송, 삭제, 배포 도구는 별도 승인과 실행 기록을 둔다.

Skill에 작업 절차를 적어도 도구 설명이 저절로 줄어들지는 않는다. 외부 서비스의 현재 자료를 읽는 연결과 도구 스키마를 싣는 방식은 MCP 서버와 클라이언트에서 따로 정해야 한다.

연결 개수보다 불러오는 방식을 본다

MCP 서버가 많다고 무조건 느려지는 것은 아니다. 서버가 내보내는 도구 수, 스키마 길이, 클라이언트의 불러오기 방식, 결과 크기가 함께 영향을 준다.

처음에는 연결 개수를 세기보다 다음 세 가지를 보면 된다.

  • 쓰지 않는 도구 설명이 처음부터 모델 입력에 들어오는가?
  • 필요한 도구만 나중에 찾는 기능을 클라이언트가 지원하는가?
  • 긴 실행 결과를 모델에게 통째로 넘기고 있는가?

도구가 적으면 필요한 것만 켜는 것으로 충분하다. 도구가 많으면 검색으로 늦게 불러온다. 여러 호출과 큰 자료를 함께 다뤄야 할 때만 코드 실행을 검토한다.

MCP의 기본 역할부터 다시 보고 싶다면 MCP는 AI가 현재 상태를 가져오는 통로다를 함께 읽어도 좋다. 컨텍스트 창과 세션의 차이는 LLM 세션을 기억처럼 믿으면 작업이 흔들린다에서 이어진다.

확인한 공식·원 자료

아래 자료는 2026년 8월 20일에 확인했다.