요약: 이 글은 Model Context Protocol (MCP) 맥락에서 AI 에이전트를 위한 효과적인 도구를 만드는 방법을 다룹니다. 도구 프로토타입 구축 및 테스트, 포괄적 평가 실행, 에이전트와 협력하여 도구 성능 개선하는 기법들을 설명합니다. 또한 올바른 도구 선택, 네임스페이싱, 의미 있는 컨텍스트 반환, 토큰 효율성 최적화, 도구 설명 프롬프트 엔지니어링 등 고품질 도구 작성의 핵심 원칙을 공유합니다.
Model Context Protocol (MCP)는 LLM 에이전트가 수백 개의 도구를 활용해 실제 과제를 해결할 수 있도록 empower합니다. 하지만 어떻게 하면 그 도구들을 최대한 효과적으로 만들 수 있을까요? 이 포스트에서는 다양한 에이전트형 AI 시스템에서 성능을 개선하기 위해 우리가 발견한 가장 효과적인 기법들을 설명합니다.
우선 다음과 같은 작업 방법부터 다룹니다:
- 도구의 프로토타입 구축 및 테스트
- 에이전트로 도구의 포괄적 평가 생성 및 실행
- Claude Code 같은 에이전트와 협력하여 도구 성능 자동 개선
마지막으로 도구 작성 과정에서 식별한 고품질 도구 작성을 위한 핵심 원칙들을 정리합니다:
- 올바른 도구 선택 (그리고 구현하지 않을 도구 결정)
- 기능 경계를 명확히 하기 위한 도구 네임스페이싱
- 도구에서 에이전트로 의미 있는 컨텍스트 반환
- 토큰 효율성을 위한 도구 응답 최적화
- 도구 설명 및 사양 프롬프트 엔지니어링
평가를 구축하면 도구의 성능을 체계적으로 측정할 수 있습니다. Claude Code를 사용하여 이 평가에 대해 도구를 자동으로 최적화할 수 있습니다.
도구란 무엇인가?
컴퓨팅에서 결정론적 시스템은 동일한 입력이 주어지면 매번 같은 출력을 생성하지만, 에이전트와 같은 비결정론적 시스템은 동일한 시작 조건에서도 다양한 응답을 생성할 수 있습니다.
전통적으로 소프트웨어를 작성할 때는 결정론적 시스템 간의 계약을 수립합니다. 예를 들어 getWeather("NYC")와 같은 함수 호출은 호출될 때마다 항상 뉴욕시의 날씨를 정확히 동일한 방식으로 가져옵니다.
도구는 결정론적 시스템과 비결정론적 에이전트 간의 계약을 반영하는 새로운 종류의 소프트웨어입니다. 사용자가 “오늘 우산을 가져가야 할까?”라고 물으면 에이전트는 날씨 도구를 호출하거나, 일반적인 지식에서 답을 찾거나, 심지어 위치에 대한 명확화 질문을 먼저 할 수도 있습니다.
가끔 에이전트는 환각(hallucination)을 일으키거나 도구 사용법을 이해하지 못할 수도 있습니다. 이는 에이전트를 위해 소프트웨어를 작성할 때 접근 방식을 근본적으로 재고해야 한다는 것을 의미합니다. 즉, 다른 개발자나 시스템을 위해 함수와 API를 작성하는 방식으로 도구와 MCP 서버를 작성하는 것이 아니라, 에이전트를 위해 설계해야 합니다.
우리의 목표는 도구를 사용해 다양한 성공 전략을 추구함으로써, 에이전트가 다양한 과제를 해결할 수 있는 범위를 확장하는 것입니다. 다행히 우리의 경험상 에이전트에게 가장 “인체공학적(ergonomic)”인 도구들이 인간에게도 놀라울 정도로 직관적으로 이해하기 쉽습니다.
도구 작성법
이 섹션에서는 에이전트와 협력하여 도구를 작성하고 개선하는 방법을 설명합니다.
도구의 빠른 프로토타입을 세우고 로컬에서 테스트하는 것으로 시작하세요. 다음으로 후속 변경 사항을 측정하기 위해 포괄적인 평가를 실행합니다. 에이전트와 함께 작업하면 에이전트가 실제 과제에서 강력한 성능을 달성할 때까지 평가 및 도구 개선 과정을 반복할 수 있습니다.
프로토타입 구축
직접 손을 대보지 않으면 어떤 도구가 에이전트에게 인체공학적이고 어떤 도구가 아닌지 예측하기 어려울 수 있습니다. 도구의 빠른 프로토타입을 세우는 것으로 시작하세요.
Claude Code를 사용하여 도구를 작성하는 경우(한 번에 작성할 수도 있음), 도구가 의존하는 소프트웨어 라이브러리, API 또는 SDK(MCP SDK 포함 가능)에 대한 문서를 Claude에 제공하는 것이 도움이 됩니다. LLM 친화적인 문서는 공식 문서 사이트의 평범한 llms.txt 파일에서 흔히 찾을 수 있습니다(우리 API의 문서가 그 예입니다).
로컬 MCP 서버나 데스크톱 확장(DXT)으로 도구를 래핑하면 Claude Code나 Claude 데스크톱 앱에 연결하여 도구를 테스트할 수 있습니다.
로컬 MCP 서버를 Claude Code에 연결하려면 claude mcp add 를 실행하세요. 로컬 MCP 서버나 DXT를 Claude 데스크톱 앱에 연결하려면 각각 설정 > 개발자 또는 설정 > 확장으로 이동하세요.
도구는 프로그래매틱 테스트를 위해 Anthropic API 호출에 직접 전달될 수도 있습니다.
직접 도구를 테스트하여 거친 부분을 식별하세요. 사용자로부터 피드백을 수집하여 도구가 가능하게 할 유스케이스와 프롬프트에 대한 직관을 구축하세요.
평가 실행
다음으로 평가를 실행하여 Claude가 도구를 얼마나 잘 사용하는지 측정해야 합니다. 실제 사용을 바탕으로 많은 평가 과제를 생성하는 것으로 시작하세요. 결과를 분석하고 도구를 개선하는 방법을 결정하는 데 에이전트와 협력하는 것을 권장합니다. 이 과정을 end-to-end로 살펴보려면 도구 평가 쿡북을 참조하세요.
[내부 Slack 도구의 홀드아웃 테스트 세트 성능]
평가 과제 생성
초기 프로토타입으로 Claude Code는 도구를 빠르게 탐색하고 수십 개의 프롬프트-응답 쌍을 생성할 수 있습니다. 프롬프트는 실제 사용에서 영감을 받아야 하며, 실제 데이터 소스와 서비스(예: 내부 지식 베이스와 마이크로서비스)를 바탕으로 해야 합니다.
도구를 충분한 복잡성으로 스트레스 테스트하지 않는 지나치게 단순하거나 표면적인 “샌드박스” 환경은 피하는 것을 권장합니다. 강력한 평가 과제는 여러 도구 호출(수십 개일 수도 있음)을 요구할 수 있습니다.
강력한 과제의 예시는 다음과 같습니다:
- 내일 Acme Corp 프로젝트에 대해 Jane과 미팅을 일정하세요. 마지막 프로젝트 계획 회의의 노트를 첨부하고 회의실을 예약하세요.
- 고객 ID 9182가 단일 구매 시도에서 세 번 청구되었다고 보고했습니다. 관련 로그 항목을 모두 찾고 동일한 문제로 영향을 받은 다른 고객이 있는지 확인하세요.
- 고객 Sarah Chen이 취소 요청을 제출했습니다. 유지 오퍼(retention offer)를 준비하세요. 다음을 결정하세요: (1) 왜 떠나는지, (2) 어떤 유지 오퍼가 가장 매력적인지, (3) 오퍼를 제시하기 전에 알아야 할 위험 요소.
약한 과제의 예시는 다음과 같습니다:
- jane@acme.corp과 내일 미팅을 일정하세요.
- payment_logs에서 purchase_complete 및 customer_id=9182를 검색하세요.
- 고객 ID 45892의 취소 요청을 찾으세요.
각 평가 프롬프트는 검증 가능한 응답이나 결과와 짝을 이루어야 합니다. 검증기는 ground truth와 샘플 응답 간의 정확한 문자열 비교만큼 간단하거나, Claude에게 응답을 판단하도록 하는 것만큼 고급스러울 수 있습니다. 서식, 문장 부호, 유효한 대안 표현 같은 사소한 차이로 인해 올바른 응답을 거부하는 지나치게 엄격한 검증기는 피하세요.
각 프롬프트-응답 쌍에 대해 평가 중 에이전트가 각 도구의 목적을 성공적으로 파악했는지 측정하기 위해, 과제를 해결하는 동안 에이전트가 호출할 것으로 예상하는 도구를 선택적으로 지정할 수도 있습니다. 하지만 과제를 올바르게 해결하는 데 여러 유효한 경로가 있을 수 있으므로 전략을 지나치게 세부적으로 지정하거나 오버피팅하는 것은 피하세요.
평가 실행
평가는 직접 LLM API 호출로 프로그래매틱하게 실행하는 것을 권장합니다. 간단한 에이전트 루프(교대로 LLM API 호출과 도구 호출을 감싸는 while 루프)를 사용하세요: 각 평가 과제마다 하나의 루프입니다.
각 평가 에이전트에게는 단일 과제 프롬프트와 도구를 제공해야 합니다. 평가 에이전트의 시스템 프롬프트에서는 구조화된 응답 블록(검증용)뿐만 아니라 추론 및 피드백 블록도 출력하도록 지시하는 것을 권장합니다. 도구 호출 및 응답 블록 전에 이들을 출력하도록 지시하면 사고 연결(CoT) 동작을 트리거하여 LLM의 유효 지능을 높일 수 있습니다.
Claude로 평가를 실행하는 경우 “즉시 사용 가능한” 유사한 기능을 위해 인터리브드 사고(interleaved thinking)를 켤 수 있습니다. 이는 에이전트가 특정 도구를 호출하거나 하지 않는 이유를 조사하고 도구 설명 및 사양의 특정 개선 영역을 강조하는 데 도움이 됩니다.
최상위 정확도 외에도 개별 도구 호출 및 과제의 총 런타임, 총 도구 호출 수, 총 토큰 소비량, 도구 오류와 같은 다른 메트릭도 수집하는 것을 권장합니다. 도구 호출을 추적하면 에이전트가 추구하는 일반적인 워크플로우를 파악하고 도구 통합의 기회를 제공할 수 있습니다.
[내부 Asana 도구의 홀드아웃 테스트 세트 성능]
결과 분석
에이전트는 모순되는 도구 설명부터 비효율적인 도구 구현, 혼란스러운 도구 스키마에 이르기까지 모든 것에서 문제를 발견하고 피드백을 제공하는 도움이 되는 파트너입니다. 하지만 에이전트가 피드백과 응답에서 생략하는 것이 포함하는 것보다 더 중요할 수 있다는 점을 명심하세요. LLM은 항상 의도한 대로 말하는 것은 아닙니다.
에이전트가 막혀거나 혼란스러워하는 곳을 관찰하세요. 평가 에이전트의 추론 및 피드백(또는 CoT)을 읽어 거친 부분을 식별하세요. 에이전트의 CoT에서 명시적으로 설명되지 않은 동작을 포착하기 위해 원시 트랜스크립트(도구 호출 및 도구 응답 포함)를 검토하세요.
행간을 읽으세요. 평가 에이전트가 정답과 전략을 반드시 알고 있는 것은 아니라는 점을 기억하세요.
도구 호출 메트릭을 분석하세요. 불필요한 반복 도구 호출은 페이지네이션이나 토큰 제한 매개변수의 적절한 조정이 필요함을 시사할 수 있습니다. 유효하지 않은 매개변수에 대한 도구 오류가 많으면 도구에 더 명확한 설명이나 더 나은 예시가 필요할 수 있습니다.
Claude의 웹 검색 도구를 출시할 때, Claude가 불필요하게 도구의 쿼리 매개변수에 2025를 추가하여 검색 결과에 편향을 주고 성능을 저하시키는 것을 발견했습니다(도구 설명을 개선하여 Claude를 올바른 방향으로 유도했습니다).
에이전트와 협력
에이전트가 결과를 분석하고 도구를 개선하도록 할 수도 있습니다. 평가 에이전트의 트랜스크립트를 연결하고 Claude Code에 붙여넣기만 하면 됩니다. Claude는 트랜스크립트를 분석하고 한 번에 많은 도구를 리팩터링하는 데 능숙합니다. 예를 들어, 새 변경 사항이 있을 때 도구 구현 및 설명이 자체 일관성을 유지하도록 합니다.
실제로 이 포스트의 대부분의 조언은 Claude Code로 내부 도구 구현을 반복적으로 최적화하면서 나온 것입니다. 우리의 평가는 실제 프로젝트, 문서, 메시지를 포함하여 내부 워크플로우의 복잡성을 거울처럼 반영하는 내부 작업 공간 위에 생성되었습니다.
우리는 “학습” 평가에 오버피팅하지 않도록 홀드아웃 테스트 세트에 의존했습니다. 이 테스트 세트는 “전문가” 도구 구현에서 달성한 성능을 넘어서 추가적인 성능 개선을 추출할 수 있음을 보여주었습니다(이 도구가 연구원이 수동으로 작성했든 Claude 자체가 생성했든 상관없이).
다음 섹션에서는 이 과정에서 배운 점 중 일부를 공유합니다.
효과적인 도구 작성을 위한 원칙
이 섹션에서는 학습 내용을 효과적인 도구 작성을 위한 몇 가지 가이드 원칙으로 정리합니다.
에이전트를 위한 올바른 도구 선택
더 많은 도구가 항상 더 나은 결과로 이어지는 것은 아닙니다. 우리가 관찰한 일반적인 오류는 기존 소프트웨어 기능이나 API 엔드포인트를 단순히 래핑하는 도구들입니다. 에이전트에게 적절한지 여부와 상관없이 말입니다.
이는 에이전트가 전통적인 소프트웨어와는 다른 “affordances(가능한 작용)”를 가지고 있기 때문입니다. 즉, 해당 도구로 수행할 수 있는 잠재적 작업에 대해 다르게 인식합니다.
LLM 에이전트는 “컨텍스트”(즉, 한 번에 처리할 수 있는 정보의 양에 제한이 있음)가 제한되어 있는 반면, 컴퓨터 메모리는 저렴하고 풍부합니다.
주소록에서 연락처를 검색하는 과제를 고려해보세요. 전통적인 소프트웨어 프로그램은 연락처 목록을 한 번에 하나씩 효율적으로 저장하고 처리하며, 다음으로 넘어가기 전에 각각을 확인할 수 있습니다. 하지만 LLM 에이전트가 모든 연락처를 반환하는 도구를 사용한 다음 토큰별로 각각을 읽어야 한다면, 무관한 정보에 제한된 컨텍스트 공간을 낭비하는 것입니다(주소록의 각 페이지를 위에서 아래로 읽는 방식으로 연락처를 검색하는 상상을 해보세요. 즉, 무차별 대입 검색입니다).
더 나은 더 자연스러운 접근 방식(에이전트와 인간 모두에게)은 먼저 관련 페이지로 건너뛰는 것입니다(아마도 알파벳순으로 찾을 수 있습니다).
평가 과제에 일치하는 특정 고영향 워크플로우를 타겟팅하는 몇 가지 사려 깊은 도구를 구축하고 거기에서 확장하는 것을 권장합니다. 주소록의 경우 list_contacts 도구 대신 search_contacts나 message_contact 도구를 구현하도록 선택할 수 있습니다.
도구는 기능을 통합하여 잠재적으로 여러 개별 작업(또는 API 호출)을 내부적으로 처리할 수 있습니다. 예를 들어, 도구는 관련 메타데이터로 도구 응답을 풍부하게 하거나 단일 도구 호출에서 자주 연결되는 다단계 작업을 처리할 수 있습니다.
다음은 예시입니다:
list_users,list_events,create_event도구를 구현하는 대신, 가용 시간을 찾고 이벤트를 예약하는schedule_event도구를 구현하는 것을 고려하세요.read_logs도구를 구현하는 대신, 관련 로그 줄과 주변 컨텍스트만 반환하는search_logs도구를 구현하는 것을 고려하세요.get_customer_by_id,list_transactions,list_notes도구를 구현하는 대신, 고객의 최신 및 관련 정보를 모두 한 번에 컴파일하는get_customer_context도구를 구현하세요.
구축하는 각 도구가 명확하고 뚜렷한 목적을 가지고 있는지 확인하세요. 도구는 동일한 기본 리소스에 접근할 수 있는 인간과 마찬가지 방식으로 에이전트가 과제를 세분화하고 해결할 수 있도록 해야 하며, 동시에 그렇지 않았다면 소비되었을 컨텍스트를 줄여야 합니다.
너무 많은 도구나 중복되는 도구는 에이전트가 효율적인 전략을 추구하는 것을 분산시킬 수도 있습니다. 구축할 도구(또는 구축하지 않을 도구)를 신중하고 선택적으로 계획하는 것이 큰 보상을 가져올 수 있습니다.
도구 네임스페이싱
AI 에이전트는 수십 개의 MCP 서버와 수백 개의 다른 도구(다른 개발자의 도구 포함)에 접근할 수 있습니다. 도구가 기능에서 중복되거나 목적이 모호하면 에이전트가 어떤 것을 사용해야 할지 혼란스러울 수 있습니다.
네임스페이싱(공통 접두사 아래 관련 도구 그룹화)은 많은 도구 간의 경계를 명확히 하는 데 도움이 될 수 있습니다. MCP 클라이언트는 때로 기본적으로 이 작업을 수행합니다.
예를 들어, 서비스별로 도구를 네임스페이싱(예: asana_search, jira_search)하고 리소스별로(예: asana_projects_search, asana_users_search) 도구를 네임스페이싱하면 에이전트가 적절한 시기에 올바른 도구를 선택하는 데 도움이 될 수 있습니다.
우리는 접두사 기반과 접미사 기반 네임스페이싱 선택이 도구 사용 평가에 사소하지 않은 영향을 미친다는 것을 발견했습니다. 효과는 LLM마다 다르므로 자체 평가에 따라 명명 체계를 선택하는 것을 권장합니다.
에이전트가 잘못된 도구를 호출하거나, 잘못된 매개변수로 올바른 도구를 호출하거나, 너무 적은 도구를 호출하거나, 도구 응답을 잘못 처리할 수 있습니다. 이름이 과제의 자연스러운 세분화를 반영하는 도구를 선택적으로 구현함으로써, 동시에 에이전트의 컨텍스트에 로드되는 도구 및 도구 설명의 수를 줄이고 에이전트 연산을 에이전트의 컨텍스트에서 도구 호출 자체로 오프로드합니다. 이는 에이전트가 실수를 할 전반적인 위험을 줄입니다.
도구에서 의미 있는 컨텍스트 반환
비슷한 맥락에서 도구 구현은 에이전트로 높은 신호 정보만 반환하도록 주의해야 합니다. 도구는 유연성보다 컨텍스트 관련성을 우선시하고 저수준 기술 식별자(예: uuid, 256px_image_url, mime_type)를 피해야 합니다.
name, image_url, file_type 같은 필드가 에이전트의 다운스트림 작업과 응답을 더 직접적으로 안내할 가능성이 훨씬 높습니다.
에이전트는 암호화된 식별자보다 자연어 이름, 용어 또는 식별자와 훨씬 더 성공적으로 싸웁니다. 우리는 임의의 영숫자 UUID를 더 의미 있고 해석 가능한 언어(또는 0-인덱스 ID 체계)로 확인하기만 해도 환각을 줄여 검색 과제에서 Claude의 정밀도를 상당히 개선한다는 것을 발견했습니다.
어떤 경우에는 다운스트림 도구 호출을 트리거하기 위해서라도(예: search_user(name='jane') → send_message(id=12345)), 에이전트가 자연어 및 기술 식별자 출력 모두와 상호작용해야 할 수도 있습니다.
도구에 간단한 response_format 열거형 매개변수를 노출하여 에이전트가 “간결” 또는 “상세” 응답을 반환하도록 제어할 수 있음으로써 둘 다 활성화할 수 있습니다(아래 이미지). GraphQL처럼 원하는 정보 조각을 정확히 선택할 수 있는 것처럼 더 많은 형식을 추가하여 유연성을 높일 수도 있습니다.
다음은 도구 응답 상세 수준을 제어하는 예시 ResponseFormat 열거형입니다:
“typescript
enum ResponseFormat {
DETAILED = "detailed",
CONCISE = "concise"
}
`
상세 도구 응답의 예시(206 토큰):
`json
{
"thread_ts": "1234567890.123456",
"channel_id": "C0123456789",
"user_id": "U0123456789",
"content": "This is a thread message",
"timestamp": "2025-01-27T10:00:00Z"
}
`
간결 도구 응답의 예시(72 토큰):
`json
{
"content": "This is a thread message",
"timestamp": "2025-01-27T10:00:00Z"
}
`
Slack 스레드와 스레드 답변은 스레드 답변을 가져오는 데 필요한 고유 thread_ts로 식별됩니다. thread_ts 및 기타 ID(channel_id, user_id)는 추가 도구 호출에 필요한 이들을 활성화하기 위해 "상세" 도구 응답에서 검색할 수 있습니다.
"간결" 도구 응답은 스레드 콘텐츠만 반환하고 ID를 제외합니다. 이 예시에서는 "간결" 도구 응답으로 약 1/3의 토큰을 사용합니다.
도구 응답 구조조차(XML, JSON, Markdown 등)도 평가 성능에 영향을 미칠 수 있습니다. 정답은 없습니다. 이는 LLM이 다음 토큰 예측으로 훈련되고 훈련 데이터와 일치하는 형식에서 더 잘 수행하는 경향이 있기 때문입니다. 최적의 응답 구조는 과제와 에이전트에 따라 크게 다릅니다. 자체 평가를 기반으로 최상의 응답 구조를 선택하는 것을 권장합니다.
토큰 효율성을 위한 도구 응답 최적화
컨텍스트의 질을 최적화하는 것이 중요합니다. 하지만 도구 응답에서 에이전트로 반환되는 컨텍스트의 양을 최적화하는 것도 중요합니다.
많은 컨텍스트를 사용할 수 있는 모든 도구 응답에 대해 페이지네이션, 범위 선택, 필터링 및/또는 잘라내기와 합리적인 기본 매개변수 값의 일부 조합을 구현하는 것을 제안합니다.
Claude Code의 경우 기본적으로 도구 응답을 25,000 토큰으로 제한합니다. 에이전트의 유효 컨텍스트 길이가 시간이 지남에 따라 증가할 것으로 예상하지만, 컨텍스트 효율적인 도구의 필요성은 남을 것입니다.
응답을 잘라내는 경우, 유용한 지시사항으로 에이전트를 유도하는 것이 중요합니다. 지식 검색 과제에서 단일 넓은 검색 대신 많은 작고 타겟팅된 검색을 수행하는 것과 같은 더 토큰 효율적인 전략을 추구하도록 에이전트를 직접 장려할 수 있습니다.
마찬가지로 도구 호출이 오류를 발생시키는 경우(예: 입력 유효성 검사 중), 불투명한 오류 코드나 트레이스백 대신 명확하고 실행 가능한 개선 사항을 명확하게 전달하도록 오류 응답을 프롬프트 엔지니어링할 수 있습니다.
잘린 도구 응답의 예시:
`json
{
"error": "Response truncated at 25,000 tokens. Use filters or pagination to retrieve specific data.",
"partial_results": [...]
}
`
도움이 되지 않는 오류 응답의 예시:
`json
{
"error": "Invalid parameter"
}
`
도움이 되는 오류 응답의 예시:
`json
{
"error": "Invalid 'date' parameter. Expected format: YYYY-MM-DD (e.g., '2025-01-27'). Received: '01/27/2025'. Please use ISO 8601 format."
}
`
도구 잘라내기 및 오류 응답은 에이전트를 더 토큰 효율적인 도구 사용 동작(필터나 페이지네이션 사용)으로 유도하거나 올바르게 형식화된 도구 입력의 예시를 제공할 수 있습니다.
도구 설명 프롬프트 엔지니어링
이제 도구를 개선하는 가장 효과적인 방법 중 하나로 도구 설명 및 사양 프롬프트 엔지니어링에 도달했습니다. 이들은 에이전트의 컨텍스트에 로드되므로 집합적으로 에이전트를 효과적인 도구 호출 동작으로 유도할 수 있습니다.
도구 설명과 사양을 작성할 때 팀의 새 직원에게 도구를 어떻게 설명할지 생각해보세요. 암묵적으로 가져올 수 있는 컨텍스트(특수화된 쿼리 형식, 틈새 용어 정의, 기본 리소스 간의 관계)를 고려하고 명시적으로 만드세요.
명확하게 설명(그리고 엄격한 데이터 모델로 강제)하고 입력 및 출력을 명시하여 모호함을 피하세요. 특히 입력 매개변수는 명확하게 명명되어야 합니다: user라는 이름의 매개변수 대신 user_id`라는 매개변수를 시도하세요.
평가를 사용하면 프롬프트 엔지니어링의 영향을 더 큰 확신으로 측정할 수 있습니다. 도구 설명에 대한 작은 개선이라도 드라마틱한 개선을 가져올 수 있습니다.
우리는 도구 설명을 정밀하게 수정한 후 Claude Sonnet 3.5가 SWE-bench Verified 평가에서 최첨단 성능을 달성했으며, 오류율을 드라마틱하게 줄이고 과제 완료를 개선했습니다.
개발자 가이드에서 도구 정의에 대한 다른 모범 사례를 찾을 수 있습니다.
Claude용 도구를 구축하는 경우 도구가 Claude의 시스템 프롬프트에 동적으로 로드되는 방법에 대해서도 읽어보시는 것을 권장합니다.
마지막으로 MCP 서버용 도구를 작성하는 경우, 도구 주석은 어떤 도구가 개방형 세계 접근이 필요하거나 파괴적인 변경을 만드는지 공개하는 데 도움이 됩니다.
전망
에이전트를 위한 효과적인 도구를 구축하려면 예측 가능한 결정론적 패턴에서 비결정론적 패턴으로 소프트웨어 개발 관행을 재지향해야 합니다.
이 포스트에서 설명한 반복적 평가 기반 프로세스를 통해, 우리는 도구가 성공하는 데 있어 일관된 패턴을 식별했습니다:
효과적인 도구는 의도적이고 명확하게 정의되어 있고, 에이전트 컨텍스트를 신중하게 사용하며, 다양한 워크플로우에서 결합될 수 있고, 에이전트가 직관적으로 실제 과제를 해결할 수 있도록 합니다.
미래에는 에이전트가 세계와 상호작용하는 구체적인 메커니즘이 발전할 것으로 예상합니다(MCP 프로토콜 업데이트부터 기본 LLM 자체의 업그레이드까지). 에이전트용 도구를 개선하는 체계적이고 평가 기반 접근 방식을 통해, 에이전트가 더 유능해짐에 따라 사용하는 도구도 그와 함께 발전할 수 있도록 보장할 수 있습니다.
감사의 말씀
Ken Aizawa가 작성했으며 연구(Barry Zhang, Zachary Witten, Daniel Jiang, Sami Al-Sheikh, Matt Bell, Maggie Vo), MCP(Theodora Chu, John Welsh, David Soria Parra, Adam Jones), 제품 엔지니어링(Santiago Seira), 마케팅(Molly Vorwerck), 디자인(Drew Roper), 응용 AI(Christian Ryan, Alexander Bricken)의 동료들로부터 귀중한 기여를 받았습니다.
1 기본 LLM 자체를 훈련하는 것 외에.
더 알고 싶으신가요? 코스를 탐색하세요.
핵심 포인트
- 도구 프로토타입 구축 → 포괄적 평가 → 에이전트와 협력하여 반복 개선의 순환적 접근 방식이 중요
- 더 많은 도구보다 적절한 도구 선택이 핵심: 고영향 워크플로우 타겟팅, 도구 기능 통합, 모호함 피하기
- 도구 설명 및 사양의 프롬프트 엔지니어링이 가장 효과적인 개선 방법 중 하나
- 토큰 효율성 최적화: 상세/간결 응답 옵션 제공, 페이지네이션, 필터링, 적절한 잘라내기
- 네임스페이싱과 의미 있는 컨텍스트 반환이 에이전트의 도구 사용 정확도를 크게 개선
출처: Writing effective tools for AI agents—using AI agents \ Anthropic
