도구 목록을 에이전트가 읽기 쉽게 만드는 것

에이전트는 당신의 문서를 절대 보지 않습니다. 보는 것은 도구 이름 목록, 한 줄 설명, 그리고 매개변수의 JSON 스키마뿐입니다. 브리핑은 그게 전부입니다. 거기서 올바른 도구가 분명하지 않으면 에이전트는 잘못된 것을 고르거나, 굳이 물을 필요가 없던 질문을 사용자에게 던집니다.

우리는 카탈로그에서 읽을 수 있는 모든 도구 표면을 평가하고 점수를 매깁니다. 수천 건을 읽다 보면 실패에 무리가 생깁니다.

1. 서로 겹치는 도구

같은 요청에 둘 다 답할 수 있을 법한 도구 두 개가 가장 비싼 실수입니다. 에이전트에게 판단 근거가 없기 때문입니다. search_docs와 find_document가 있다면, 둘 중 하나는 다른 쪽이 하지 않는 일이 무엇인지 말해야 합니다.

2. 의미 없는 매개변수

타입이 string인 query라는 이름의 매개변수는 에이전트에게 아무것도 알려주지 않습니다. 안에 무엇이 들어가나요 — 키워드, 질문, 아니면 식별자? 대소문자를 구분하나요? 비워두면 어떻게 되나요? 그 자리는 README가 아니라 스키마입니다.

3. 모호한 도구에 예시가 없음

대부분의 도구에는 예시가 필요 없습니다. 하지만 자유 형식 객체나 필터 표현식, 도메인 고유 식별자를 받는 도구에는 반드시 필요합니다. 우리 평가에서 "사용 예시 없음"은 가장 자주 나오는 약점 중 하나이며, 거의 언제나 서버 전체가 아니라 특정 도구 하나를 가리킵니다.

4. 말하지 않는 제약

요청 한도, 최대 결과 수, 실행 타임아웃, 호출에 비용이 드는지 여부. 한도를 모르는 에이전트는 반드시 부딪힙니다. 가장 높은 점수를 받는 서버는 이런 내용을 설명에 분명히 적어 둔 쪽입니다.

짧게 정리하면

• 서로 다른 일을 암시하는 서로 다른 이름.
• 모든 매개변수를 "무엇을 넣는가"의 언어로 설명할 것.
• 사람이라면 물어볼 도구에는 예시를 붙일 것.
• 제약은 에이전트가 실제로 읽는 곳에 적을 것.

이 중 어느 것도 도구를 더 만들라고 요구하지 않습니다. 대부분은 더 적은 도구를, 더 잘 설명하라고 요구합니다.