Loading ToolBench
MCP server providing greeting, calculation, time, geocoding, and weather tools
This server presents 5 tools with decent structure but notable gaps. All tools have registered schemas and descriptions visible in src/index.ts. Naming is generally adequate (verb_noun pattern: 'greet', 'calculator', 'time', 'geocode', 'get-weather'). Descriptions are present and translated (Korean), though brevity is mixed. Input schemas use Zod with types and descriptions for all parameters. Output schemas are defined (text content arrays). However, there are critical quality issues: (1) descriptions are in Korean only, limiting LLM comprehension in English contexts; (2) no error recovery guidance, e.g., 'geocode' can fail silently if Nominatim is down, no recovery suggestions; (3) parameter descriptions include example values inline ('예: "Seoul", "New York"', '예: Asia/Seoul') which LLMs may reuse literally; (4) tools that call external APIs (geocode, get-weather) lack timeout handling and retry guidance; (5) no per-tool permission scopes declared; (6) missing output field consistency across tools, all return generic 'content' array rather than domain-specific fields.
두 개의 숫자와 연산자를 입력받아 사칙연산 결과를 반환합니다.
도시 이름이나 주소를 입력받아서 위도와 경도 좌표를 반환합니다.
위도와 경도 좌표, 예보 기간을 입력받아서 해당 위치의 현재 날씨와 예보 정보를 제공합니다.
이름과 언어를 입력하면 인사말을 반환합니다.
timezone 기반으로 현재 시간을 알려줍니다.
All tool descriptions and parameter descriptions are in Korean. LLMs trained primarily on English will not understand intent, leading to incorrect tool selection or failed calls.
Example values embedded in parameter descriptions ('예: "Seoul", "New York"', '예: Asia/Seoul') violate anti-pattern guidance. LLMs frequently reuse example values literally instead of substituting real data, causing API calls with placeholder values.
External API calls (geocode → Nominatim, get-weather → undocumented service) lack timeout documentation, rate-limit guidance, and retry strategy. No recovery paths documented if APIs are unreachable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
All tools return generic text content arrays rather than domain-specific structured output. 'geocode' should return {latitude, longitude}; 'get-weather' should return structured weather fields; 'calculator' should return {result, operands}. Generic responses waste tokens and force LLMs to parse unstructured text.
No error handling guidance in tool descriptions. Division-by-zero in calculator, invalid timezone in time, empty result in geocode, all have error paths in code but LLMs have no description of failure modes or recovery actions.
Numeric parameters (latitude, longitude, forecastDays, num1, num2) lack explicit min/max constraints in descriptions. Zod may enforce some (forecastDays 1 - 16), but LLMs cannot read JSON Schema to infer bounds, descriptions must state them.
No permission scopes declared (e.g., 'read:geocoding', 'read:weather'). Cannot audit which tools require external API access or sensitive operations.