>_toolkitbox

~/tools / Tool Definition Checker

Tool Definition Checker — OpenAI, Anthropic, Gemini의 도구·함수 정의를 검사

OpenAI, Anthropic, Gemini에 보내는 도구(함수) 정의를 각 API가 문서에 밝힌 형식에 비추어 검사합니다. 이름, 설명, 매개변수 스키마, strict mode, 입력 예시를 다룹니다. 요청이 실패하기 전에 실수를 찾아냅니다. 입력한 내용은 브라우저 밖으로 나가지 않습니다.

규칙은 2026-10-23의 문서를 기준으로 확인했습니다.

문서: OpenAI / Anthropic / Gemini API 레퍼런스

검사하지 않는 것: 모델이 도구를 지원하는지, Anthropic의 strict tool use에 관한 세부 사항, Anthropic이 직접 제공하는 도구, 문서에 명시되지 않은 규칙.

모든 처리는 브라우저 안에서 이루어집니다. 정의는 업로드되지 않습니다.

도구 사용(tool use), 또는 함수 호출(function calling)은 모델이 여러분의 코드에 함수를 실행해 달라고 요청하게 하는 기능입니다. 각 함수를 JSON 정의로 기술하는데, 대표적인 세 API가 기대하는 형태는 서로 다릅니다. OpenAI Chat Completions는 함수를 function 객체 안에 중첩하고, OpenAI Responses는 필드를 한 단계에 두며, Anthropic은 name과 input_schema를 쓰고, Gemini는 함수 선언(function declarations)을 씁니다. 이름 규칙도 다릅니다. 이 도구는 붙여넣은 정의를 읽어 어느 API용으로 쓰였는지 판별하고, 해당 업체의 문서가 말하는 내용에 비추어 검사합니다. 이름, 설명, 매개변수 스키마, strict mode, 그리고 Anthropic의 경우 각 입력 예시가 스키마와 맞는지를 확인합니다. 또한 한 API에서는 통과하는 이름이 다른 API에서는 거부될 수 있는 경우도 알려 줍니다. 규칙은 도구 아래에 표시된 날짜의 문서를 기준으로 확인했습니다.

이럴 때 사용

  • 요청에 넣기 전에 도구 정의를 점검해, 잘못된 이름이나 형태 때문에 호출이 실패하는 일을 막기
  • strict mode가 함수 스키마를 거부하는 이유 찾기
  • 도구를 한 업체에서 다른 업체로 옮길 때 무엇을 바꿔야 하는지 확인하기

사용법

  1. 도구 정의 하나, 도구 배열, 또는 tools 배열이 들어 있는 요청 본문을 붙여넣거나 예시를 불러옵니다.
  2. 각 도구가 어느 API로 인식되었는지 확인한 다음 결과 목록을 읽습니다. 수정은 문서상 거부되거나 올바르지 않다는 뜻, 확인은 살펴볼 만하다는 뜻, 참고는 정보 제공용입니다.
  3. 정의를 고친 뒤 다시 붙여넣습니다. strict mode 문제는 Structured Output Schema Checker에서 하나씩 자세히 볼 수 있습니다.

FAQ

정의가 어느 API용인지 어떻게 알아내나요?

형태를 보고 판단합니다. input_schema가 있는 정의는 Anthropic으로, type이 function이고 중첩된 function 객체가 있으면 OpenAI Chat Completions로, type이 function이면서 필드가 최상위에 있으면 OpenAI Responses로 읽습니다. functionDeclarations가 있거나 name, description, parameters를 가진 객체는 Gemini로 읽습니다. 결과에는 각 도구가 무엇으로 인식되었는지 표시됩니다.

이름 규칙은 어떻게 되나요?

OpenAI 문서는 영문자, 숫자, 밑줄, 하이픈을 64자까지 허용한다고 밝힙니다. Anthropic 문서는 영문자, 숫자, 밑줄, 하이픈을 128자까지 허용한다고 밝힙니다. Gemini 문서는 영문자, 숫자, 밑줄, 콜론, 점, 하이픈을 128자까지 허용한다고 밝힙니다. 한 API에서 유효한 이름이 다른 API에서는 거부될 수 있으며, 그런 경우 도구가 알려 줍니다.

strict가 true일 때 스키마를 한 번 더 검사하는 이유는 무엇인가요?

OpenAI는 strict mode에서 모든 객체에 additionalProperties를 false로 설정하고, 모든 속성을 required에 나열해야 하며, 선택값은 null도 허용하는 타입으로 써야 한다고 밝힙니다. 이 규칙을 어긴 스키마는 거부됩니다. 도구는 문제의 수를 세고 첫 번째 문제가 있는 위치를 보여 줍니다.

input_examples에서는 무엇을 검사하나요?

Anthropic은 각 예시가 도구의 input_schema에 대해 유효해야 하며, 유효하지 않은 예시는 400 오류를 반환한다고 밝힙니다. 도구는 모든 예시를 스키마에 비추어 검사하고 어느 예시가 실패하는지 알려 줍니다.

검사하지 않는 것은 무엇인가요?

특정 모델이 해당 도구를 지원하는지, Anthropic의 strict tool use에 관한 세부 사항, Anthropic이 직접 제공하는 도구, 그리고 문서에 명시되지 않은 모든 것입니다. API를 호출하지 않으므로 검사를 통과한 정의도 실제 요청에서는 실패할 수 있습니다.

정의가 서버로 전송되나요?

아니요. 검사는 브라우저 안에서 실행됩니다.

관련 도구