MCP에서 “툴”이란 무엇이며, 왜 생각보다 더 중요한가
Source: Dev.to
Tools
MCP가 시스템이라면, 도구는 그 시스템을 유용하게 만드는 요소입니다.
Simple Definition
도구는 모델이 선택해서 수행할 수 있는 구조화된 행동입니다.
👉 모델이 무언가를 하고 싶을 때, 도구를 사용합니다.
Important Clarification
도구는 단순히 함수가 아닙니다.
함수에 다음과 같은 요소가 추가된 형태입니다:
- 명확한 이름
- 명확한 목적
- 정의된 입력
이 구조 덕분에 모델이 도구를 이해하고 사용할 수 있습니다.
What a Tool Looks Like
get_user_orders(user_id, limit)이 도구는 모델에게 다음을 알려줍니다:
- 무엇을 하는가 → 사용자 주문을 가져옴
- 무엇이 필요한가 →
user_id,limit
How the Model Uses a Tool
사용자 질문: “내 최근 3개 주문을 보여줘”
-
모델이 사용 가능한 도구를 확인
get_user_orderscancel_ordersearch_products
-
모델이 결정
“이건 주문 관련 요청이니 →get_user_orders를 사용하자” -
모델이 도구 호출을 생성
{ "tool": "get_user_orders", "arguments": { "user_id": "123", "limit": 3 } } -
시스템이 실행 – MCP 서버가 로직을 수행하고 데이터를 반환합니다.
-
모델이 응답 – 결과를 사용자 친화적인 답변으로 변환합니다.
Key Insight
모델은 코드를 보지 못합니다. 모델이 보는 것은:
- 도구 이름
- 설명
- 입력 구조
👉 이것을 기반으로 판단합니다.
Why Tool Design Matters
불명확한 도구는 시스템을 망가뜨립니다.
Bad Tool
process_data(data)문제점
- 무엇을 하는가?
- 언제 사용해야 하는가?
- “data”가 의미하는 바는?
👉 모델이 혼란스러워합니다.
Good Tools
get_user_orders(user_id, limit)
cancel_order(order_id)
search_products(query)각 도구가 명확한 목적을 가지고 있어 모델이 쉽게 적절한 도구를 선택할 수 있습니다.
Golden Rules for Designing Tools
-
한 도구 = 한 행동
여러 책임을 하나에 합치지 마세요. -
명확한 이름 사용
선호:get_user_orders,create_order
피할 것:handle_data,process_request -
입력을 명시적으로 정의
잘못된 예
{ "data": "string" }올바른 예
{ "user_id": "string", "limit": "number" } -
편리함보다 명료함을 설계
백엔드가 복잡한 작업을 지원하더라도 도구는 단순하고 이해하기 쉬워야 합니다.
A Better Way to Think About Tools
도구를 모델이 사용할 수 있는 행동 집합이라고 생각하세요.
도구가 없으면 모델은 해당 행동을 수행할 수 없습니다.
Common Mistakes
- 도구를 너무 많이 만들기 → 선택이 어려워짐
- 도구를 지나치게 일반화하기 → 사용법이 불분명
- 하나의 도구에 과도한 기능을 넣기 → 혼란
Why This Concept Is So Important
도구 설계는 직접적으로 다음에 영향을 미칩니다:
- 모델의 수행 능력
- 결정의 정확성
- 시스템의 확장성
What’s Next
이제 도구에 대해 이해했으니, 다음 단계는 이 도구들이 실제로 어디에 존재하고 누가 실행하는지를 살펴보는 것입니다. 우리는 MCP 서버—결정을 실제 행동으로 전환하는 구성 요소—를 자세히 분석할 것입니다.