Loading ToolBench
MCP Server with greeting, calculator, time, geocode, weather, and image generation tools
Server has 4 tools with explicit registrations, Zod schemas, and descriptions in Korean. All tools are READ_ONLY and have basic input/output schemas defined. However, there are significant gaps in naming patterns, parameter clarity, and error handling guidance. Tool names are generic verbs ('greet', 'calculator', 'time', 'geocode') without clear action-oriented patterns. Descriptions are present but brief (34-48 chars), falling below the 50-200 char baseline for LLM optimization. Parameter descriptions exist but lack detailed constraints (no min/max for numbers, no format specs for strings). Output schemas are defined with Zod but are overly structured with nested 'content' arrays rather than directly returning typed results. Error cases (e.g., division by zero, missing timezone params) are handled inline with text responses but lack actionable recovery guidance. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only.
두 개의 숫자와 연산자를 입력받아 사칙연산 결과를 반환합니다.
도시 이름이나 주소를 입력받아서 위도와 경도 좌표를 반환합니다.
이름과 언어를 입력하면 인사말을 반환합니다.
현재 시간을 가져오거나 시간대를 변환합니다.
Tool names lack action-verb clarity. 'greet', 'calculator', 'time', 'geocode' are generic and do not follow verb_noun pattern (e.g., 'get_greeting', 'compute_arithmetic', 'get_time', 'get_coordinates'). LLMs rely on verb-first names to infer action; these names are ambiguous and do not convey intent.
Descriptions are too brief (34 - 48 chars, below 50-char minimum). Missing WHAT/WHEN/WHY context. E.g., 'greet' says '이름과 언어를 입력하면 인사말을 반환합니다' (name and language input returns greeting) but does not explain when to use vs. alternatives, what use case it serves, or prerequisites.
Parameters lack detailed constraint documentation. 'timezone' in time tool has no format spec (e.g., IANA zone string expected). 'address' in geocode has no validation hint. 'num1', 'num2' in calculator lack min/max bounds. LLMs cannot infer these from names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Error handling provides no recovery guidance. 'calculator' returns '오류: 0으로 나눌 수 없습니다' (error: cannot divide by zero) as text, but does not tell LLM what to do next (retry? ask user? suggest alternative). 'time' similarly returns bare error messages without actionable guidance.
Output schemas are over-nested. All tools return {content: [{type: 'text', text: '...'}], structuredContent: {...}} which is verbose and wastes tokens. Direct response structures (e.g., {greeting: string} for greet, {result: number, expression: string} for calculator) would be clearer and cheaper.
No tool annotations. All 4 tools are read-only and idempotent, but no readOnlyHint or idempotentHint annotations are present. LLMs cannot determine safety classification without explicit hints.
'time' tool has undocumented parameter dependencies. 'sourceTimezone' and 'targetTimezone' are marked optional but are required when action='convert'. Error message is returned at runtime, not documented in parameter descriptions. This forces LLMs to discover the constraint via trial-and-error.