MCP 대 API: 진정한 차이점과 각각을 사용할 때

“MCP 대 API”라는 표현은 두 경쟁 기술 간의 선택처럼 들릴 수 있습니다. 하지만 이 둘은 동일한 스택 내에 위치합니다. API는 시스템이 수행할 수 있는 기능을 노출합니다. 그런 다음 MCP 서버는 해당 기능이 API, 데이터베이스, 로컬 파일 또는 다른 소스에서 비롯된 것이든 상관없이, AI 애플리케이션이 선택한 기능을 사용할 수 있도록 제공합니다.

따라서 이번 비교의 핵심은 MCP가 API를 대체할지 여부나 두 기술이 본질적으로 어떻게 다른지가 아닙니다. 각 계층이 무엇을 제공하며, 어디에서 복잡성을 유발하는지, 그리고 하나만 선택하는 것보다 둘을 함께 사용하는 것이 더 합리적인 경우가 언제인지에 대한 것입니다.

MCP 대 API: 한눈에 보기

MCP란 무엇인가?

MCP( Model Context Protocol)는 AI 애플리케이션이 외부 도구, 데이터 및 서비스를 탐색하고 활용할 수 있는 공유된 방법을 제공하는 개방형 표준입니다.

MCP의 작동 원리

MCP 클라이언트는 가능한 모든 동작을 하드코딩하는 대신, 연결된 서버에 어떤 기능을 제공하는지 문의할 수 있습니다. 서버는 이름, 설명, 입력 스키마가 포함된 도구 목록을 반환합니다. 그러면 AI 모델은 사용자의 요청에 어떤 도구가 적합한지 결정할 수 있습니다.

런타임 탐색은 MCP의 주요 장점 중 하나입니다. 클라이언트는 서비스마다 서로 다른 통합 패턴을 익힐 필요 없이, 서버가 제공하는 기능을 확인하고 필요할 때 해당 기능을 호출할 수 있는 하나의 표준화된 방식을 활용하게 됩니다.

Anthropic은 2024년 11월에 MCP를 공개했으며, 2025년 12월에 이를 리눅스 재단 산하의 Agentic AI 재단에 기증했습니다.

MCP가 가장 적합한 용도

MCP는 AI 어시스턴트나 에이전트가 여러 도구에 접근해야 하고, 실행 시점에 어떤 도구를 사용할지 결정해야 할 때 가장 적합합니다.

API란 무엇인가?

API(애플리케이션 프로그래밍 인터페이스)는 공개된 계약입니다. 제공자는 일련의 연산, 각 요청의 모양, 그리고 반환되는 결과에 대해 약속합니다. 개발자의 코드는 해당 계약을 한 번만 읽어들이고, 매번 동일한 방식으로 호출합니다.

API의 작동 원리

개발자는 일반적으로 API 문서를 읽고, 엔드포인트를 선택하며, 필요한 매개변수를 정의한 뒤, 요청을 수행하는 코드를 작성합니다.

예시로, 애플리케이션은 작업을 생성하기 위해 하나의 엔드포인트를 호출하고, 고객 기록을 가져오기 위해 또 다른 엔드포인트를 호출할 수 있습니다. 해당 로직이 소프트웨어에 이미 구현되어 있으므로, 애플리케이션은 어떤 엔드포인트를 사용해야 할지 이미 알고 있습니다.

참고할 점: “API”는 호환되지 않는 여러 스타일을 포괄합니다. REST는 리소스와 HTTP 동사를 중심으로 작업을 구성합니다. GraphQL은 단일 엔드포인트를 노출하고 호출자가 원하는 필드를 지정할 수 있게 합니다. gRPC는 지연 시간이 중요한 서비스 간 호출을 위해 HTTP/2를 통해 바이너리 페이로드를 사용합니다.

공통된 설명 표준에 가장 가까운 것은 OpenAPI인데, 많은 제공자가 이를 공개하지만 그렇지 않은 곳도 많습니다. API가 실제로 갖추고 있는 것은 대략 20년 동안 축적된 도구들입니다. 즉, 게이트웨이, 계약 테스트, 분산 추적, 버전 관리 규칙, 그리고 대부분의 엔지니어링 팀이 이미 운영 중인 속도 제한 인프라 등이 있습니다. MCP는 아직 이에 상응하는 시스템을 구축 중인 단계입니다.

어떤 API가 가장 적합할까?

API는 애플리케이션이 알려진 서비스에 대해 예측 가능한 액세스가 필요하고, 개발자가 어떤 메서드가 언제 호출되는지 직접 제어하고자 할 때 효과적입니다.

MCP 대 API: 주요 차이점은 무엇인가?

API와 MCP는 모두 액션을 노출하지만, 연결을 처리하는 방식은 다릅니다. API는 알려진 연산으로 시작합니다. MCP는 “무엇을 사용할 수 있는가?”라는 질문으로 시작합니다. 이로부터 세 가지 차이점이 도출되는데, 이 중 어느 것도 어떤 인터페이스가 더 우월한지에 관한 것이 아닙니다. 이는 어떤 인터페이스가 어떤 호출자를 처리하는지에 관한 것입니다.

API는 알려진 연산으로 시작합니다

API를 사용할 경우, 애플리케이션은 어떤 엔드포인트가 필요한지 이미 알고 있습니다. 개발자는 요청을 정의하고, 매개변수를 설정하며, 응답에 따라 어떤 처리가 이루어질지 코드로 작성합니다.

따라서 API는 고정된 워크플로우에 매우 적합합니다. 결제가 처리되면 시스템에서 청구서를 생성합니다. 호출 경로는 한 번 작성되고 테스트된 후 매번 재사용됩니다.

MCP를 사용하면 모든 가능성이 열려 있습니다. 연결된 클라이언트는 서버가 제공하는 도구를 확인한 후, 이를 AI 시스템에서 사용할 수 있도록 합니다. 다음 단계는 미리 정의된 단일 흐름에 의존하는 것이 아니라 사용자의 요청에 따라 결정됩니다.

인터페이스 계층의 작동 방식이 다릅니다

API는 다양한 모양으로 존재합니다. 어떤 제공자는 REST를 사용하고, 다른 곳은 GraphQL을 사용하며, 또 다른 곳은 SDK에 의존합니다. 인증, 오류 처리, 페이지 분할, 요청 형식 등은 서비스마다 모두 다릅니다.

MCP는 AI 클라이언트에 서버에 연결하고 서버가 제공하는 정보를 읽을 수 있는 단일 프로토콜을 제공합니다. 그렇다고 해서 모든 도구가 동일해지는 것은 아닙니다. 두 서버가 유사한 동작에 서로 다른 이름을 붙이거나 다르게 설계할 수도 있습니다. 하지만 클라이언트는 각 서버마다 다른 프로토콜을 사용할 필요가 없습니다.

tool 컨텍스트에 따라 모델의 선택 방식이 달라집니다

API 설명은 개발자와 그들의 코드를 위해 존재합니다. 애플리케이션은 요청이 시작되기 전에 어떤 메서드를 호출해야 할지 알고 있습니다.

MCP를 사용하면 tool 이름, 설명 및 입력 스키마가 모델의 작업 컨텍스트로 전달됩니다. 모델은 해당 정보를 읽어 요청에 적합한 액션을 결정하고, 아규먼트를 채웁니다.

이러한 차이가 가시적으로 나타나는 곳 중 하나는 에이전트 워크플로우로, 시스템이 고정된 순서를 따르기보다는 요청에 따라 다음 조치를 선택해야 할 수 있습니다.

MCP와 API 중 무엇을 선택해야 할까?

기능을 어떻게 노출해야 하는지에 따라 MCP와 API 중 하나를 선택하십시오. 애플리케이션이 호출할 서비스나 연산을 이미 알고 있는 경우 API가 효과적입니다. AI 애플리케이션이 런타임 시점에 서로 다른 시스템에 걸쳐 기능을 탐색하고 사용할 표준 방식이 필요한 경우에는 MCP가 유용합니다.

다음과 같은 경우에는 API를 선택하십시오.

다음과 같은 경우에는 MCP를 선택하세요

API의 한계

API는 모든 통합이 맞춤형으로 구축되기 때문에 한계가 있습니다. 개발자가 코딩하지 않은 기능을 사용자가 요청할 때 대응할 수 없고, 다중 서비스 워크플로우에서는 모든 오케스트레이션 작업을 사용자가 직접 처리해야 하며, 제공자마다 문서 품질이 일관되지 않습니다.

MCP의 한계

MCP의 주요 한계로는 디버깅의 복잡성, 서버 동작과 동기화되지 않을 수 있는 tool 설명, 범용 서버 레지스트리의 부재, 그리고 기업용으로 표준화되지 않은 인증 정보 패턴 등이 있습니다.

이 중 어느 것도 영구적인 것은 아닙니다. 사양은 빠르게 변화하고 있으며, 관련 도구들도 이를 따라잡고 있습니다. 하지만 현재 MCP를 프로덕션 배포를 위해 평가 중이라면, 출시 시점에 이러한 제약 사항들이 사라질 것이라고 가정하기보다는 이를 고려하여 아키텍처를 설계해야 합니다.

MCP tool 호출 대 직접 API 요청

API 요청은 코드가 사전에 정의한 고정된 매개변수를 사용하여 알려진 엔드포인트로 직접 전송됩니다. MCP 도구 호출은 동일한 작업을 JSON-RPC 엔벨로프로 감싸며, AI 모델은 서버의 도구 카탈로그를 읽은 후 런타임에 이 엔벨로프를 선택합니다. 그런 다음 MCP 서버는 모델을 대신하여 기본 API 호출을 실행합니다.

각 계층별로 “ClickUp에서 작업 생성하기” 과정을 살펴보겠습니다.

API를 통해

애플리케이션은 이미 목록 ID, 담당자, 정확한 엔드포인트를 알고 있습니다. 이를 직접 호출합니다.

응답에는 생성된 작업 오브젝트가 포함되어 돌아옵니다. 모델은 전혀 사용되지 않았습니다. 개발자는 로직을 작성하고, 엔드포인트를 선택하며, 결과를 처리했습니다.

출처: MCP

AI 클라이언트가 ClickUp MCP 서버에 연결하여 어떤 도구가 있는지 묻습니다:

모델은 스키마를 읽고, create_task가 사용자의 요청에 부합하는지 판단한 후, 구조화된 아규먼트를 반환합니다:

동일한 작업이 생성됩니다. MCP 서버는 여전히 내부적으로 ClickUp REST API를 호출하여 해당 작업을 실행합니다.

실제로 무엇이 달라졌는가

결과는 동일합니다. 달라진 점은 누가 결정을 내렸느냐는 것입니다.

API를 사용할 때는 요청이 시작되기 전에 코드가 엔드포인트를 알고 있었습니다. 반면 MCP에서는 모델이 런타임에 도구 카탈로그를 읽어들이고, 사용자가 평이한 언어로 요청한 내용에 따라 40개 이상의 사용 가능한 도구 중에서 create_task를 선택합니다.

두 접근 방식 중 어느 쪽이 절대적으로 더 낫다고 할 수는 없습니다. API는 더 빠르고, 비용이 저렴하며, 결정론적입니다. MCP는 유연하고, 탐색이 용이하며, 자연어로 추론하는 호출자를 위해 설계되었습니다.

MCP는 스테이트풀인가, 스테이트리스인가?

2026년 7월 28일자 사양에 따르면 , MCP의 프로토콜 핵심은 무상태입니다. 과거 비교에서 주로 근거로 삼았던 차이점(REST는 무상태이고, MCP는 세션을 유지한다는 점)은 이제 더 이상 사용되지 않는 전송 방식을 설명하는 것에 불과합니다.

기존의 “initialize” 핸드셰이크와 “Mcp-Session-Id” 헤더는 사라졌습니다. 각 요청은 자체 프로토콜 버전, 클라이언트 식별자 및 기능을 포함합니다. 모든 호출은 일반 라운드 로빈(round-robin) 로드 밸런서 뒤에 있는 임의의 서버 인스턴스로 전달될 수 있습니다. 스티키 라우팅도, 공유 세션 저장소도 없습니다.

또한 이 사양은 메서드 및 도구 이름을 HTTP 헤더에 포함시킵니다. 이제 게이트웨이, 속도 제한기, 웹 애플리케이션 방화벽(WAF)은 JSON 본문을 먼저 파싱하지 않고도 MCP 트래픽을 라우팅하거나 측정할 수 있습니다.

여전히 여러 번의 교환이 필요한 경우, MCP는 두 가지 패턴을 제공합니다. Multi-Round-Trip Requests는 단일 호출 내에서 가벼운 왕복 통신을 처리합니다. Tasks 확장은 장시간 실행되는 작업을 처리합니다. 서버는 지속 가능한 작업 핸들을 반환하며, 실행 도중 추가 정보가 필요한 경우 클라이언트가 누락된 입력을 제공할 때까지 “input_required” 상태로 일시 중지됩니다. 레거시 상태 유지(stateful) 동작은 전환 기간에 있으며, Roots, Sampling, Logging(서버가 클라이언트에게 정보를 다시 요청할 수 있게 해주는 세 가지 구형 기능)은 별도로 사용 중단 예정이며, 제거되기까지 최소 12개월의 유예 기간이 주어집니다.

따라서 상태 유무는 더 이상 구분 기준이 아닙니다. 여전히 남아 있는 차이점은 전송 계층 위에 있습니다. API는 어떤 함수가 호출될지 결정하기 위해 개발자가 작성한 로직에 의존하는 반면, MCP는 AI 모델이 이를 스스로 발견하고 대부분 직접 선택하도록 합니다.

MCP와 기능 호출의 차이점은 무엇인가?

함수 호출은 모델의 기능 중 하나입니다. MCP는 이를 지원하는 검색 및 전송 표준입니다. 함수 호출을 통해 모델은 사용자가 직접 코드에 정의한 함수를 호출하기 위해 구조화된 요청을 전송할 수 있습니다. MCP는 이러한 정의의 출처, 클라이언트가 런타임에 서버에서 이를 가져오는 방식, 그리고 인증이 작동하는 방식을 표준화합니다. 모델은 함수 호출을 사용하여 MCP가 제공하는 tools를 활용합니다.

함수 호출(도구 사용이라고도 함) 기능은 OpenAI, Anthropic, Google의 모델 API에 내장되어 있습니다. 사용자는 일련의 기능을 정의하고 해당 스키마를 모델에 전달하면, 모델은 관련성이 있다고 판단되는 기능이 있을 때 구조화된 아규먼트를 반환합니다. 어떤 기능을 제공할지 선택하고, 실행 코드를 작성하며, 응답을 처리하는 것은 여전히 사용자의 몫입니다. 모델은 어떤 기능을 호출할지 결정합니다. 나머지는 사용자의 코드가 처리합니다.

MCP는 한 단계 더 높은 수준에서 작동합니다. 이 방식은 AI 클라이언트가 여러 서버에 어떤 기능이 존재하는지 파악하는 방법을 표준화하며, 사용자 측에서 하드코딩할 필요가 없습니다. 서버는 자체 tools를 알리고, 클라이언트는 런타임에 이를 읽습니다. 그런 다음 모델은 함수 호출을 통해 선택한 기능을 실행합니다.

간단히 말해, 기능 호출은 모델이 “이 아규먼트를 사용하여 이 도구를 호출하고 싶다”고 말하는 방식입니다. MCP는 모델에게 호출할 수 있는 tools가 무엇인지 알려주는 역할을 합니다.

대부분의 MCP 호환 클라이언트는 이 두 가지를 함께 실행합니다. 이들은 MCP 서버에서 도구 스키마를 가져와 모델용 기능 정의로 형식화한 다음, 모델의 구조화된 출력을 MCP를 통해 다시 전달하여 실행합니다. 이 두 가지는 동일한 스택 내의 계층이므로, 일반적으로 단일 요청에 대해 순차적으로 작동하는 모습을 볼 수 있습니다.

MCP는 API보다 느리거나 비용이 더 많이 드나요?

네, MCP는 직접적인 API 호출보다 속도가 느리고 비용도 더 많이 듭니다. MCP는 요청 루프 내에 AI 모델을 포함시키기 때문에 추가적인 지연 시간과 토큰 비용이 발생합니다. 직접적인 API는 요청을 엔드포인트로 바로 전송하지만, MCP는 LLM이 도구를 동적으로 선택, 실행 및 해석해야 합니다.

MCP가 더 느린 이유

MCP가 더 비싼 이유

MCP는 API보다 보안성이 떨어질까?

본질적으로는 아닙니다. MCP는 인증, 권한 부여, 범위 지정된 권한, 입력 유효성 검사 등 다른 API와 동일한 보안 요구 사항을 따릅니다. 차이점은 어떤 메서드가 호출될지 결정하는 주체가 누구냐는 점입니다.

두 가지 위험 요소를 언급할 필요가 있습니다:

도구 중독(Tool poisoning). 악의적인 MCP 서버가 도구 응답 내에 숨겨진 명령어를 반환합니다. 모델은 해당 응답을 신뢰할 수 있는 컨텍스트로 간주하고 내장된 명령어를 따릅니다. OWASP는 이를 MCP에 연결된 에이전트에 대한 간접 프롬프트 주입으로 분류합니다. 이 공격이 성공하는 이유는 도구 설명은 연결 시점에 한 번만 검토되지만, 도구 응답은 실행 시점에 이에 상응하는 검증 없이 모델의 컨텍스트로 바로 유입되기 때문입니다.

“치명적인 3중 위협”. 이는 사이먼 윌리슨(Simon Willison)이 제시한 개념입니다. 이는 개인 데이터에 접근할 수 있고, 신뢰할 수 없는 콘텐츠를 소비하며, 외부와 통신할 수 있는 에이전트를 의미합니다. 이 세 가지 요소가 모두 결합되면 프롬프트 주입이 데이터 유출로 이어지는 경로가 됩니다. 사용자가 다양한 출처의 tools를 연결하기 때문에 MCP는 이러한 조합이 쉽게 이루어지도록 만듭니다.

실질적인 문제는 MCP가 “보안이 강화되었는가”가 아닙니다. 중요한 것은 모델이 호출할 수 있는 코드뿐만 아니라, 모델이 볼 수 있고, 선택할 수 있으며, 실행할 수 있는 범위를 제한했는지 여부입니다.

MCP 배포의 경우:

ClickUp이 MCP와 API를 모두 활용하는 방법

ClickUp은 지금까지 설명한 “둘 다 구축” 패턴의 예시입니다.

ClickUp API는 완전한 개발자용 인터페이스입니다. 팀은 이 API를 사용하여 맞춤형 연결을 구축하고, 시스템 간 데이터를 동기화하며, 모든 요청을 직접 제어하여 워크플로우를 실행합니다.

ClickUp MCP 서버는 MCP를 통해 이러한 작업 중 상당수를 노출합니다. Claude Code, Cursor, ChatGPT와 같은 AI 클라이언트는 연결하여 어떤 ClickUp 도구가 있는지 확인하고, 자연어 프롬프트를 통해 해당 도구를 호출할 수 있습니다. 여기에는 작업 생성, 작업 공간 검색, 문서 작업, 댓글 작성, 기록된 시간 등이 포함됩니다.

사용자 대면 AI 레이어는 그 위에 위치합니다. ClickUp Brain은 작업, 문서, 채팅 및 기타 일에서 맥락을 추출합니다.

또한 ClickUp 슈퍼 에이전트는 이러한 맥락을 바탕으로 스스로 결정을 내리고 다단계 워크플로우를 실행합니다. 사용자는 이들에게 작업을 할당하고, 메시지를 보내며, 작업 공간 전반에서 활동하도록 할 수 있습니다.

이로써 ClickUp은 세 가지 계층을 갖추게 되었습니다. API는 완전한 접근 권한을 원하는 개발자들을 지원합니다. MCP는 외부 AI 클라이언트가 ClickUp 도구를 찾아 사용할 수 있는 표준화된 방법을 제공합니다. Brain과 Super Agents는 제품 자체에 AI 추론 기능을 도입합니다.

물론, ClickUp을 사용하면 MCP 서버를 통해 다른 도구들과도 연결할 수 있습니다. 별도의 API 작업이 필요하지 않습니다.

전송 프로토콜 비교는 그만두고, 소비자 비교를 시작하라

MCP와 API는 경쟁 관계에 있는 표준이 아니며, 사람들이 가장 자주 언급하는 차이점들은 가장 빠르게 구식이 된 것들입니다.

남은 것은 진정한 아키텍처적 결정입니다. API는 개발자를 위한 계약입니다. MCP 서버는 모델을 위한 계약으로, 이는 프롬프트이자 토큰 비용이며 동시에 공격 표면이기도 합니다.

이에 맞춰 설계하십시오. API를 결정론적인 중추로 삼으십시오. 그런 다음 도구별로, 사람이 없는 상황에서 에이전트가 수행할 수 있는 작업을 결정하고, 오직 그 내용만 공개하십시오. 해당 카탈로그가 실제 상황에서 어떤 비용을 초래하는지 측정하고, 반증이 확인될 때까지는 모든 도구 설명과 응답이 공격자에 의해 제어된다고 가정하십시오.

API를 선택하든 MCP를 선택하든, ClickUp은 두 가지 모두를 지원합니다. 지금 바로 ClickUp을 무료로 시작해 보세요.

MCP 대 API에 관한 자주 묻는 질문

통신 프로토콜 형식은 HTTP를 통한 JSON-RPC 2.0으로, 의도적으로 눈에 띄지 않게 설계되었습니다. 값은 표준화된 기능 카탈로그, 도구 스키마, 그리고 이를 기반으로 하는 인증 모델에 있습니다. 7월 사양 기준, 각 요청은 자체 설명형이며 상태 비저장 방식이며, 메서드 및 tool 이름이 HTTP 헤더에 포함되어 있어 게이트웨이가 본문을 파싱하지 않고도 라우팅할 수 있습니다. 이제 하나의 통합 솔루션으로 Claude, ChatGPT, Cursor, Gemini, Copilot을 각각에 맞는 맞춤형 연결 코드 없이 모두 지원할 수 있습니다.

ClickUp에는 API와 MCP 서버가 모두 있나요?

네. ClickUp은 결정론적이고 코드 기반의 통합을 위한 OpenAPI 사양을 갖춘 REST API와, Claude, ChatGPT, Cursor와 같은 어시스턴트가 자연어로 작업 공간 데이터를 처리할 수 있게 해주는 별도의 MCP 서버(공개 베타)를 제공합니다. MCP 인터페이스는 API의 일부로 의도적으로 제한된 기능 집합이므로, 그 외의 기능은 여전히 REST API를 사용합니다. 이 기능은 모든 플랜에서 이용 가능합니다.

2026년 중반 기준으로 Claude 데스크탑, Claude 코드, ChatGPT(Plus, Pro, Business, Enterprise 등 유료 플랜 포함), Cursor, GitHub Copilot, VS Code(Copilot 확장 프로그램을 통해), Gemini, Windsurf, Microsoft Copilot Studio 등이 모두 MCP를 지원합니다. OpenAI, Google, Microsoft 및 여러 다른 기업들이 이 사양을 관리하는 리눅스 재단(Linux Foundation) 산하 에이전틱 AI 재단(Agentic AI Foundation)에 합류했습니다. 클라이언트 지원은 광범위하지만 고르지 않습니다. 모든 클라이언트가 모든 MCP 기능을 지원하는 것은 아닙니다(예: 리소스 및 프롬프트는 도구 호출에 비해 지원이 뒤처집니다).

네, 그리고 기존 API를 래핑하는 것이 가장 일반적인 방법입니다. 서버는 API에 인증을 수행하고, 선택한 엔드포인트 집합을 tools에 매핑한 뒤, 각 엔드포인트의 이름, 설명 및 JSON 스키마를 공개합니다. 모든 엔드포인트를 매핑하려는 유혹을 참으세요. 각 tool 설명은 매 턴마다 모델의 컨텍스트에 포함되므로, 카탈로그가 방대할수록 토큰 소모가 늘어나고 프롬프트 주입의 표면적이 넓어집니다. 에이전트가 무인 상태에서 수행하도록 허용하려는 동작만 노출시키세요.

사용 사례가 요구하는 만큼만 사용하십시오. Anthropic의 엔지니어링 팀에 따르면, 모델이 사용자의 요청을 읽기도 전에 도구 정의와 결과 처리만으로도 50,000개 이상의 토큰이 소모될 수 있다고 합니다. 커뮤니티의 지침에 따르면, 컨텍스트 관리 기법(점진적 공개, 도구 검색)이 필요해지기 전까지 서버당 최대 10~20개의 도구를 사용하는 것이 적정선입니다. 50개를 초과할 경우, 목적별로 구분된 여러 서버로 분산하십시오.

아니요, 비록 대부분의 배포 환경에는 하나씩 있기는 하지만요. MCP 서버는 HTTP API를 거치지 않고도 로컬 파일, 데이터베이스 또는 인프로세스 로직을 노출할 수 있으며, 이것이 바로 원래 stdio 전송 방식이 설계된 방식입니다. MCP에 항상 필요한 것은 도구를 실행할 수 있는 수단입니다. 기존 API를 래핑하는 것이 가장 빠른 방법인 이유는 인증, 유효성 검사 및 오류 처리가 이미 구축되어 있기 때문입니다.

Tools are callable actions (create a task, run a query) and most closely resemble API endpoints. Resources are read-only data that the model can pull into context (files, database records, live documents). 프롬프트는 “이 PR을 요약해 주세요”와 같은 워크플로우처럼 AI 클라이언트가 요청할 수 있는 재사용 가능한 지시 템플릿입니다. tools가 가장 많은 주목을 받지만, MCP를 단순한 함수 호출 목록과 구별 짓는 것은 바로 리소스와 프롬프트입니다. 이를 통해 서버는 모델의 행동뿐만 아니라 컨텍스트까지 형성할 수 있습니다.