MCP 서버 여러 개 붙여봤는데, 결국 중요한 건 도구 설명이었다

MCP를 붙인다고 바로 똑똑해지진 않았다

처음엔 단순하게 생각했다. 필요한 도구를 MCP 서버로 열어두면 에이전트가 알아서 잘 쓰겠지 싶었다. 실제로 연결 자체는 어렵지 않았다. 문제는 그다음이었다. 도구 수가 늘수록 오히려 이상한 선택을 하거나, 비슷한 기능을 헷갈리거나, 쓸데없이 긴 경로로 돌아가는 경우가 많았다. 해봤더니 연결보다 설명이 더 중요했다.

특히 이름만 그럴듯하고 설명이 두루뭉술한 도구가 문제였다. “search”, “get_data”, “run_task” 같은 식이면 사람도 헷갈리는데 모델은 더 헷갈린다. 어느 도구가 언제 적합한지, 입력은 어떤 형식인지, 실패하면 뭘 기대해야 하는지까지 써줘야 선택이 안정됐다.

좋은 도구 설명은 프롬프트보다 오래 간다

이상하게 들릴 수 있는데, 시스템 프롬프트를 길게 다듬는 것보다 도구 설명을 손보는 편이 효과가 더 오래갔다. 이유는 단순하다. 모델이 매 호출마다 직접 참고하는 정보이기 때문이다. 내가 써보면서 가장 효과 있었던 건 세 가지였다. 언제 쓰는지 한 줄로 못 박기, 쓰면 안 되는 상황 적어주기, 예시 입력을 짧게라도 넣기. 이것만 해도 잘못된 호출이 꽤 줄었다.

반대로 욕심내서 설명을 너무 길게 쓰면 또 별로였다. 핵심이 묻힌다. 짧지만 구체적으로, 모호한 추상어 대신 실제 행동을 써주는 쪽이 낫더라. 예를 들어 “웹 검색 도구”보다 “최신 공개 웹페이지를 찾을 때 사용, 로그인 필요한 페이지엔 부적합” 같은 문장이 훨씬 잘 먹혔다.

도구 스키마는 기능 명세서이자 안전장치다

MCP에서 입력 스키마를 제대로 잡는 것도 중요했다. 문자열 하나로 다 받게 만들면 편해 보이지만, 실제론 실수가 더 많아진다. 필드를 나누고, enum을 두고, 필수값을 명확히 하면 모델 행동이 꽤 차분해진다. 이건 단순히 정확도 문제만이 아니다. 위험한 실행을 줄이는 안전장치 역할도 한다.

물론 너무 빡빡하면 유연성이 떨어진다. 그래서 나는 자주 쓰는 경로만 구조화하고, 실험용 도구는 범위를 조금 넓게 두는 편이다. 결국 여기서도 균형이 필요하다. MCP가 만능 규격이라기보다, 좋은 습관을 강제로 드러내는 틀에 가깝다고 느꼈다.

결국 모델보다 인터페이스 설계가 남는다

새 모델이 나올 때마다 성능 차이는 조금씩 줄어들고 있다. 그럴수록 오래 남는 건 도구 인터페이스 쪽이다. 솔직히 모델 바꾸는 건 하루면 하는데, 엉성한 도구 설명 때문에 생긴 혼선은 몇 주를 간다. 그래서 요즘은 MCP 서버를 늘리기 전에 먼저 묻는다. 이 도구를 사람 동료에게 줘도 이해될 정도로 써놨나. 거기서 막히면 모델도 같이 막힌다.

---

📎 참고 자료

• Model Context Protocol introduction
• Model Context Protocol specification
• MCP tools concepts