엔지니어들은 익숙하지 않은 API에 코딩 에이전트를 사용할 때 반복적으로 어려움을 겪는데, 이는 수동적인 컨텍스트 조립 과정으로 인해 빠르게 성능이 저하됩니다. 핵심 문제는 API 계약의 전송 메커니즘으로 산문 문서를 사용하는 데 있으며, 이는 최신 정보가 아닌 상태, 반복적인 토큰 비용, 그리고 강제성 부족과 같은 문제를 야기합니다. 산문 문서는 빠르게 구식이 되는 스냅샷을 제공하며, 모든 대화에서 동일한 정보를 다시 업로드하도록 강제하고, 런타임 오류가 발생할 때까지 호출을 검증하지 못합니다.구조적인 해결책은 OpenAPI 문서를 직접 생성하여 MCP(Microservice Contract Protocol) 서버를 통해 호출 가능한 도구로 에이전트에게 API 계약을 제공하는 것을 포함합니다. 이 접근 방식은 각 API 작업을 정의된 입력 스키마를 가진 도구로 변환하여 구조화된 검색 및 사전 검증을 가능하게 합니다. 산문과 달리 MCP 도구는 에이전트의 즉각적인 오류 수정을 허용하고, 인증을 중앙 집중화하며, 모든 연결된 에이전트에 대해 계약이 한 곳에서 업데이트되도록 보장합니다. 스트리밍 작업도 사용 가능해지는데, 도구가 스트림을 열고 이벤트를 수집하는 것을 처리하기 때문입니다.로컬 개발은 스펙 파일을 통해 로컬 MCP 서버를 사용하며, 공유 환경은 버전 고정 및 사용자별 토큰을 가진 호스팅된 MCP 엔드포인트를 사용할 수 있으며, 최소한의 액세스를 위해 토큰 범위를 강조합니다. MCP는 내부 API에 대한 반복적인 통합 작업, 많은 작은 작업이 있는 환경, 청구와 같은 강제성이 높은 도메인, 그리고 빠르게 변화하는 사양을 포함하는 시나리오에서 진정으로 유리합니다. 그러나 이는 서술형 문서나 고성능 SDK를 대체하는 보편적인 솔루션은 아닙니다.MCP는 일회성 탐색, 성능이 중요한 또는 배치 클라이언트, 그리고 OpenAPI 스펙에 명시적으로 정의되지 않은 작업에는 덜 적합합니다. 잘 유지된 OpenAPI 문서는 필수적인데, 도구는 스펙 자체만큼만 정확하기 때문입니다. 이상적인 설정은 단일 OpenAPI 문서를 유지하는 것을 포함하며, 여기서 세 가지의 뚜렷한 렌더링이 파생됩니다: 인간 학습을 위한 렌더링된 문서, 프로덕션 코드를 위한 생성된 SDK, 그리고 에이전트 통합 및 탐색을 위한 MCP 서버입니다. 이 접근 방식은 다른 팀과 도구 간의 중복된 설명을 방지합니다.