애플리케이션 코드가 호출할 작업을 이미 알고 있다면 API나 SDK를 사용하세요. 모델이 런타임에 기능을 탐색하고 선택해야 한다면 MCP를 사용합니다. 대부분의 프로덕션 MCP 도구는 내부에서 기존 API를 호출하므로 두 인터페이스는 대개 서로 보완합니다.
MCP는 탐색과 모델용 계약을 추가합니다. 백엔드 API, 인가, 데이터 모델 또는 MCP 서버의 인증 경계를 대신하지 않습니다.
차이는 작업을 누가 선택하는가입니다
개발자가 이미 엔드포인트를 선택하고 필드를 매핑했으므로 고정 코드는 POST /refunds를 호출할 수 있습니다. 고객 지원 사례를 조사하는 에이전트는 근거를 읽은 뒤 get_invoice, explain_charge, request_refund, escalate_case 중에서 선택해야 할 수 있습니다. MCP는 이런 작업과 스키마의 현재 목록을 모델에 제공합니다.
MCP 도구 명세는 도구 탐색과 호출을 프로토콜의 일부로 만듭니다. OpenAPI는 HTTP API를 설명할 수 있지만 어떤 엔드포인트를 에이전트 작업으로 만들지는 결정하지 않습니다.
API, SDK, MCP 비교
| 질문 | API 또는 SDK | MCP 서버 |
|---|---|---|
| 주 호출자 | 알려진 경로를 실행하는 애플리케이션 코드 | 실행 중 기능을 선택하는 모델 |
| 탐색 | 개발 중 사용하는 문서, 타입, OpenAPI | 런타임의 tools/list, 리소스, 협상된 기능 |
| 계약 형태 | 엔드포인트 또는 메서드의 입력과 출력 | 도구 의도, 입력 및 선택적 출력 스키마 |
| 인증 | API별 방식 | MCP 전송 인가와 별도 업스트림 인증 |
| 인가 | 백엔드가 강제 | 여전히 백엔드가 강제 |
| 적합한 용도 | 결정론적 워크플로와 내부 서비스 호출 | 동적 도구 선택과 이식 가능한 에이전트 클라이언트 |
| 주요 실패 | 통합 코드가 API를 잘못 호출 | 모델이 모호하거나 지나치게 넓은 도구를 선택 |
이 결정에서 GraphQL은 API에 속합니다. 스키마 인트로스펙션은 개발자나 클라이언트의 쿼리 구성을 돕지만 제한 없는 그래프는 좋은 에이전트 도구 모음이 되기 어렵습니다.
직접 API 호출이 더 명확한 경우
다음과 같은 경우 API를 직접 사용하세요.
- 워크플로의 항상 같은 지점에서 호출합니다.
- 코드에 필수 값이 이미 있습니다.
- 지연에 민감하고 프로토콜 단계를 추가해도 판단에 도움이 되지 않습니다.
- 통합에 MCP가 노출하지 않는 공급자별 기능이 필요합니다.
- 작은 타입 지정 SDK가 필요한 계약을 이미 제공합니다.
예를 들어 결제 핸들러는 검토된 애플리케이션 코드를 통해 결제 API를 호출해야 합니다. 사용자가 결정론적인 결제 양식을 제출한 뒤 모델이 청구 생성 여부를 선택해서는 안 됩니다.
MCP가 필요한 경우
다음과 같은 경우 MCP를 사용하세요.
- 모델이 여러 기능 중 하나를 선택해야 합니다.
- 여러 호환 에이전트 클라이언트에서 도구가 작동해야 합니다.
- 세션 중 도구 목록이나 사용 가능한 리소스가 바뀔 수 있습니다.
- 사용자가 표준 에이전트 흐름을 통해 자신의 계정을 연결해야 합니다.
- 구조화된 콘텐츠, 리소스 링크, 서버 제공 프롬프트가 클라이언트에 유용합니다.
REST-to-MCP 튜토리얼은 작업 하나에서 시작해 그 뒤에 API를 감쌉니다. 엔드포인트마다 도구 하나를 만드는 흔한 변환을 피합니다.
MCP는 보안 경계가 아닙니다
API 엔드포인트를 tools/list에서 숨겨도 그 뒤의 자격 증명은 폐기되지 않습니다. MCP 서버는 클라이언트를 인증하고 대리 사용자를 인가하며 대상 API용 업스트림 자격 증명을 사용해야 합니다. 그다음 백엔드가 리소스를 다시 인가합니다.
MCP 인가 명세는 토큰 전달도 금지합니다. MCP 서버용으로 발급된 토큰을 다운스트림 서비스에 전달해서는 안 됩니다.
기계적인 래퍼를 피하세요
모든 REST 엔드포인트에 MCP 도구를 하나씩 생성하면 선택지가 겹치고 내부 구현 세부 정보가 노출되는 경우가 많습니다. 사용자 작업에서 시작하세요.
User task: "Where is order 1842?"
Weak toolset:
get_order_row
get_shipment_row
translate_status_code
Better tool:
get_order_status
서버는 내부에서 여러 API를 호출하고 가장 작은 유용한 결과를 반환할 수 있습니다. 그런 판단이 에이전트의 역할이 아니라면 모델이 내부 조인을 조정하게 하지 마세요.
항상 같은 단계를 감사하세요
워크플로 하나의 모든 MCP 호출을 나열하세요. 애플리케이션 코드가 항상 같은 도구와 같은 인자 매핑을 선택한다면 MCP가 다른 구체적인 이점을 제공하지 않는 한 타입 지정 API 또는 SDK 호출로 교체합니다.
아래 프롬프트는 불필요한 래퍼를 찾고 모델이 실제로 선택하는 곳에 MCP를 유지합니다.