당신의 MCP 서버에 40개의 도구가 필요하지 않은 이유

MCP 데모는 종종 모든 것을 한꺼번에 보여줍니다. 모든 엔드포인트와 모든 데이터베이스 테이블을 보여주죠. 에이전트가 무엇이든 호출할 수 있다고 주장합니다.

10분 동안은 강력하게 느껴집니다. 하지만 곧 모델이 실패합니다. 잘못된 도구를 호출하거나, 인자(arguments)를 잘못된 형태로 전달합니다. 검색 엔드포인트에 차트를 요청하거나, 파괴적인 작업을 재시도하기도 합니다.

문제는 MCP가 아닙니다. MCP를 백엔드를 위한 마법 같은 어댑터로 취급하는 것이 문제입니다.

MCP 서버는 단순히 에이전트가 접근할 수 있도록 만든 API가 아닙니다. 그것은 매우 문자 그대로 작동하며 주의력이 산만한 사용자를 위한 제품 인터페이스입니다. 그 사용자는 바로 언어 모델입니다.

모델에게 40개의 유사한 도구를 주면, 힘을 주는 것이 아니라 '거의 맞을 뻔한' 40가지의 오류 가능성을 주는 것입니다.

API 라우트를 그대로 복제하는 것을 멈추세요. 인간은 문서를 읽고 맥락을 이해할 수 있지만, 모델은 이름과 설명을 패턴 매칭합니다.

사용자 의도(intent)를 중심으로 MCP 레이어를 구축하세요.

모든 라우트를 복제하는 대신, 명확한 경계로 그룹화하세요:

  • 시장 요약을 위한 도구 하나
  • 출시 캘린더를 위한 도구 하나
  • 특정 데이터 스냅샷을 위한 도구 하나
  • 과거 지표를 위한 도구 하나

API 라우트는 이렇게 말합니다: "이 요청을 보내면 서버가 응답할 것입니다." MCP 도구는 이렇게 말해야 합니다: "정확히 이 작업을 위해, 이 정확한 입력값들을 사용하여 나를 호출하세요. 그러면 이 특정한 결과를 기대할 수 있습니다."

좋은 도구 설명은 마케팅 문구가 아니라 라우팅 로직이어야 합니다.

나쁨: name: get_data description: API에서 데이터를 가져옵니다.

좋음: name: lookup_release_calendar description: 특정 통화와 날짜 범위에 대해 예정된 경제 이벤트를 반환합니다. 향후 거시 경제 이벤트에 관한 질문에 답하기 전에 이 도구를 사용하세요.

더 나은 에이전트를 위해 다음 규칙을 따르세요:

  1. 지루한 이름을 사용하세요. 개발자는 fetch나 query와 같이 간결한 이름을 선호합니다. 하지만 모델은 search_docs나 check_deployment_status와 같이 구체적인 이름이 필요합니다. 모호한 이름은 비용이 많이 듭니다.

  2. 응답 형태를 제어하세요. 거대한 중첩 객체를 반환하지 마세요. 작업을 지원하는 데 필요한 최소한의 형태만 반환하세요. 모델이 너무 많은 데이터를 보면 잘못된 필드를 사용하거나 세부 사항을 환각(hallucinate)할 수 있습니다.

  3. 실패를 고려하여 설계하세요. 프로덕션 수준의 품질은 에러를 어떻게 처리하느냐에서 나옵니다. 단순히 500 에러나 빈 배열을 반환하지 마세요. 모델에게 왜 실패했는지 알려주세요. 일치하는 레코드가 없다면, 모델이 사용자에게 더 넓은 날짜 범위를 제안하도록 안내하세요.

최고의 에이전트 도구는 가장 강력한 도구가 아닙니다. 모델이 오해할 수 없는 도구입니다.

Source: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1

Optional learning community: https://t.me/GyaanSetuAi