요약: MCP 서버를 붙였는데 에이전트가 도구를 엉뚱하게 쓰는 문제는 대부분 모델 문제가 아니라 계약 문제다. 도구 이름, 파라미터 설명, 권한 범위, 실패 응답, 평가 테스트가 부족하면 좋은 모델도 불안정하게 동작한다. Cloudflare Agents 문서가 강조하듯 MCP는 외부 서비스를 AI 시스템에 연결하는 표준이고, evals는 그 연결이 실제로 맞게 작동하는지 확인하는 안전장치다.
검색 의도: MCP evals, Model Context Protocol, AI agent tool calling, MCP 서버 테스트
많은 팀이 MCP를 처음 붙일 때 기존 REST API를 그대로 도구로 노출한다. createUser, updateUser, deleteUser, listUsers, getUser 같은 엔드포인트를 거의 그대로 MCP tool로 만든다. 이렇게 하면 구현은 빠르지만 에이전트 입장에서는 선택지가 너무 많아진다. 작은 context window와 제한된 reasoning budget 안에서 어떤 도구를 써야 할지 헷갈린다.
Cloudflare Agents MCP 문서도 비슷한 기준을 제시한다. MCP 서버를 전체 API schema의 wrapper로 만들지 말고, 특정 사용자 목표와 신뢰할 수 있는 결과에 맞게 설계하라는 것이다. 적은 수의 잘 설계된 도구가 많은 granular tool보다 더 안정적일 수 있다.
핵심은 도구를 API 단위가 아니라 업무 단위로 설계하는 것이다. 예를 들어 고객 지원 에이전트라면 getUser, listPayments, getTickets보다 summarizeCustomerContext가 나을 수 있다. 내부에서 여러 API를 읽더라도 에이전트에게는 “고객 상태 요약”이라는 안정적인 도구 하나만 보이는 편이 좋다.
MCP 서버가 정상 응답을 준다고 해서 에이전트가 올바르게 쓰는 것은 아니다. 일반적인 API 테스트는 “이 입력에 이 출력이 나오는가”를 확인한다. MCP evals는 한 단계 더 들어간다. “이 사용자 요청에서 에이전트가 적절한 도구를 선택하고, 올바른 파라미터를 넣고, 결과를 바르게 해석하는가”를 확인한다.
예를 들어 사용자가 “지난달 결제 실패한 고객에게 안내 메일 초안을 만들어줘”라고 말했을 때, 에이전트는 고객 조회, 결제 실패 조회, 메일 초안 생성 순서를 밟아야 한다. 여기서 잘못된 고객 범위를 조회하거나, 이번 달 데이터를 가져오거나, 실제 메일 발송 도구를 호출하면 문제가 된다.
evals는 이런 실패를 배포 전에 잡는다. 도구 설명을 바꿨거나, 권한 scope를 줄였거나, 모델 버전을 바꿨거나, 서버 응답 형식이 달라졌을 때 회귀 테스트처럼 돌릴 수 있다. 에이전트 품질은 감으로 운영하면 안 된다. 테스트 케이스가 있어야 개선이 가능하다.
첫째, 도구 이름은 행동과 목표가 보여야 한다. query 같은 이름은 너무 넓다. find_recent_failed_payments처럼 대상과 조건이 드러나는 이름이 낫다. 모델은 이름에서 많은 단서를 얻는다.
둘째, 파라미터 설명에 제약을 넣어야 한다. date라고만 쓰지 말고 YYYY-MM-DD format, inclusive start date, must not be in the future처럼 적는다. 선택값이 있다면 enum으로 제한한다. 자유 텍스트를 남발하면 모델 출력도 흔들린다.
셋째, 도구가 하지 않는 일도 설명해야 한다. 예를 들어 draft_refund_email은 메일 초안을 만들 뿐 실제 발송하지 않는다고 명시한다. 반대로 실제 쓰기 작업을 하는 도구는 “사용자 승인 없이는 호출하지 말 것” 같은 정책을 description에 넣고, 서버에서도 강제해야 한다.
넷째, 출력 형식은 typed shape로 고정한다. 에이전트가 후속 reasoning에 쓰기 쉬운 구조가 필요하다. 문자열 하나로 긴 설명을 반환하는 것보다 status, items, warnings, next_actions처럼 필드를 나누는 편이 안정적이다.
처음부터 거창한 평가 시스템을 만들 필요는 없다. 20개 케이스로 시작해도 충분하다. 중요한 것은 실제 사용자 요청을 반영하는 것이다.
케이스는 네 종류로 나눈다.
각 케이스에는 기대 행동을 적는다. “도구 A를 호출해야 함”, “도구 B를 호출하면 안 됨”, “실제 발송 도구 호출 전 승인 질문을 해야 함”, “결과가 0건이면 빈 결과를 설명해야 함”처럼 관찰 가능한 기준이 필요하다.
정답을 자연어로만 적으면 채점이 어려워진다. 가능하면 JSON으로 기대 도구, 기대 파라미터, 금지 도구, 필수 응답 문구를 적는다. 그러면 자동 채점 비율을 높일 수 있다.
MCP의 remote connection은 OAuth와 scoped permission이 중요하다. Cloudflare 문서도 여러 focused MCP server를 나누고 권한을 좁히면 과도한 접근을 줄이고 감사하기 쉬워진다고 설명한다. evals 역시 scope별로 나눠야 한다.
읽기 전용 에이전트, 초안 생성 에이전트, 실제 변경 가능한 에이전트는 테스트가 다르다. 읽기 전용 에이전트가 쓰기 도구를 호출하려 한다면 실패해야 한다. 초안 생성 에이전트가 실제 전송까지 해버리면 더 큰 문제다.
권장 구조는 서버를 역할별로 나누는 것이다. support-read-mcp, billing-read-mcp, content-draft-mcp, admin-action-mcp처럼 분리하면 사고 범위가 줄어든다. 모든 도구를 하나의 MCP 서버에 몰아넣고 scope만 복잡하게 나누면 운영자가 이해하기 어렵다.
도구 호출은 항상 성공하지 않는다. 권한이 없거나, 데이터가 없거나, 입력이 잘못됐거나, 외부 API가 실패할 수 있다. 실패 응답이 애매하면 에이전트는 같은 도구를 반복 호출하거나, 잘못된 결론을 낸다.
좋은 실패 응답은 세 가지를 포함한다.
예를 들어 CUSTOMER_NOT_FOUND와 “해당 이메일의 고객을 찾을 수 없습니다”, “사용자에게 이메일을 다시 확인해 달라고 요청하세요”를 함께 반환한다. 이렇게 하면 에이전트는 실패를 사용자에게 자연스럽게 설명할 수 있다.
MCP 서버의 품질은 모델이 얼마나 똑똑한지보다 도구 계약이 얼마나 명확한지에 좌우된다. evals를 붙이면 에이전트 도구 호출은 운에 맡기는 기능이 아니라 테스트 가능한 인터페이스가 된다.
