MCP 도구 스키마를 검색형 호출로 압축한 Orca 브리지

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

기본 MCP 패턴은 모델이 실제로 사용할 도구를 고르기 전에 연결된 모든 서버의 전체 tool schema를 매 turn context에 넣어 input tokens, latency와 context pressure를 키웁니다. 글은 search와 execute 두 operation만 모델에게 제공하고, 자연어 intent 검색 결과를 최대 1,800 bytes의 compact card로 제한한 뒤 action ID를 실제 schema와 서버에서 재검증하는 bridge를 제안합니다. 217,316 bytes의 schema를 5,062 bytes로 줄인 stress fixture에서 크기는 97.7% 감소했고 token 규모는 약 54k에서 약 1.3k로 낮아졌으며 올바른 tool 호출과 arguments는 유지됐습니다. 다만 discovery 단계가 추가되고 큰 tool result에는 적용되지 않으며, 하나의 fixture가 모든 catalog의 절감률을 보장하지 않는다는 한계가 있습니다.

합의점 vs 논쟁점

논쟁점

검색 단계를 추가해 schema를 숨기는 구조가 전체 호출 latency와 운영 복잡도에 어떤 영향을 주는지는 이 stress fixture만으로 판단하기 어렵습니다. 글은 schema 처리 전 비용을 크게 줄였지만 discovery 요청 자체의 비용이나 검색 품질 수치를 따로 제시하지 않았습니다. 따라서 실제 환경에서는 schema 절감량과 함께 검색 실패율, 추가 왕복 시간, 잘못된 action ID 선택을 측정해야 합니다.

실용적 조언

자신의 MCP schema 부담은 같은 one-line prompt를 MCP 서버가 연결된 상태와 연결되지 않은 상태에서 각각 두 번 호출해 usage 필드의 input tokens 차이를 비교하면 됩니다. 차이가 크면 모델이 도구를 선택하기 전부터 많은 schema를 읽고 있을 가능성이 있습니다. 이후 검색 결과를 1,800 bytes 안팎의 compact card로 제한하고 선택 뒤 실제 schema를 server-side validation에만 연결하는 방식과 비교할 수 있습니다.

섹션별 상세

기본 MCP 연결 방식은 모델이 실제로 필요한 도구를 알기 전에 연결된 모든 서버의 전체 tool schema를 매 turn 읽게 만듭니다. 글의 stress fixture에서는 schema 크기가 217,316 bytes, 약 54k tokens였고, 도구 하나를 호출하기 위해 이 정보가 context에 남았습니다. 이 구조는 매 호출의 input tokens뿐 아니라 첫 유효 token까지의 latency와 사용하지 않는 명세가 차지하는 context pressure를 함께 키웁니다.

제안된 bridge는 도구 catalog 전체를 모델에게 노출하지 않고 search와 execute라는 두 operation만 제공합니다. 모델이 "create a support ticket"처럼 자연어 intent를 검색하면 최대 1,800 bytes의 compact card 몇 개를 받고, 선택한 action ID로 실행을 요청하며 bridge가 뒤에서 실제 schema를 다시 연결하고 server-side validation을 수행합니다. 따라서 검색 결과만 context에 들어가고 전체 schema는 선택 이후 호출 검증에 사용됩니다.

동일한 stress fixture에서 217,316 bytes의 schema가 5,062 bytes짜리 card로 줄어 97.7% 감소했고, token 규모도 약 54k에서 약 1.3k로 낮아졌습니다. 글은 모델이 올바른 tool과 arguments를 계속 호출해 실행 정확도는 유지됐다고 기록합니다. 다만 discovery 단계가 한 번 추가되고, 큰 tool output의 context 비용은 줄이지 않으며, 하나의 oversized fixture만으로 모든 catalog의 절감률을 보장하지는 않는다고 선을 그었습니다.

용어 해설

Model Context Protocol(MCP): — MCP는 여러 서버의 도구를 언어 모델이 호출하도록 연결하는 프로토콜입니다. 기본 방식에서는 연결된 도구의 전체 schema가 매 호출마다 모델 context에 들어갑니다. 이 글에서는 schema를 검색과 실행 사이에 분리하는 대상 기술로 다뤄집니다.
도구 스키마(Tool Schema): — 도구 schema는 모델이 호출할 수 있는 함수의 이름, 입력 인자, 자료형과 제약 조건을 담은 구조화된 명세입니다. 모델은 이 정보를 읽어야 올바른 도구와 arguments를 구성할 수 있습니다. 글의 방식은 전체 schema를 숨기고 선택 뒤 서버에서 실제 schema와 대조합니다.
컨텍스트 압박(Context Pressure): — Context pressure는 작업과 직접 관련 없는 토큰이 모델의 context를 차지해 유효한 입력 공간을 줄이는 현상입니다. 연결된 도구가 많으면 사용하지 않을 schema도 매 turn마다 함께 처리됩니다. 이 글에서는 schema를 작은 검색 카드로 바꿔 이 부담을 낮춥니다.
입력 토큰(Input Tokens): — 입력 토큰은 모델 요청에 포함되어 처리되는 텍스트 단위입니다. MCP 도구의 전체 schema가 매 호출에 들어가면 캐싱이 비용 일부를 완화해도 처리 지연과 context 점유는 남습니다. 글에서는 서버 연결 유무에 따른 usage 필드의 차이로 schema 부담을 측정합니다.

언급된 도구

Orca중립

MCP 도구 schema를 search와 execute 흐름으로 분리하는 agent runtime과 bridge를 제공합니다.