Loading ToolBench
Two tools with minimal definitions. example_tool is a trivial placeholder (10-char description). weather_api has a functional implementation but descriptions are in Korean, limiting LLM comprehension. Both tools lack parameter constraints (enums, ranges), output schemas are undocumented, and error handling is basic. No tool annotations (readOnlyHint, etc.). Naming is acceptable but descriptions fall well below the 194-char baseline for production tools. Neither tool documents what fields the LLM should expect in responses.
An example tool that processes messages
Open-Meteo API를 사용하여 도시의 실제 날씨 정보를 가져오기
Descriptions are too short and in Korean. example_tool: 'An example tool that processes messages' (10 chars, trivial). weather_api description is entirely in Korean, making it inaccessible to English-speaking LLMs. Baseline is 194 chars; both fall far short.
No output schemas documented. weather_api returns WeatherApiResponse (temperature, condition, humidity, windSpeed, feelsLike, precipitation) but this structure is not visible in the tool definition, only in the TypeScript class. LLMs cannot infer what fields to expect.
No parameter constraints. weather_api 'city' parameter accepts any string with no validation, enum, or format hint. LLMs may pass empty strings, numbers, or invalid city names. No min/max length, no pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
No tool annotations. Both tools are marked risk=READ_ONLY but lack explicit readOnlyHint in schema. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are current MCP spec patterns and should be present.
Error handling is minimal. weather_api catches errors and wraps them in generic messages ('날씨 데이터 가져오기 실패'). No recovery guidance, no categorization (retryable vs fatal), no invalid-value feedback. LLM cannot self-correct.