Loading ToolBench
MCP server that provides weather data and exchange rate information through x402 payment-enabled HTTP endpoints
This MCP server exhibits significant quality gaps across multiple dimensions. Only 2 tools are defined. Tool naming is partially acceptable but lacks clarity on parameter distinctions. Descriptions exist but are minimal (26-104 chars, below the 194-char baseline). The server demonstrates basic tool registration but falls short of production-grade tool engineering.
Provides information about the exchange rate, for example how much is 10 USD in EUR
Provides information about the weather
No output schemas documented. LLMs cannot infer response structure. Both tools return {content: [{type: 'text', text: JSON.stringify(...)}]} but downstream agents don't know what fields to extract from the stringified JSON.
get-weather-data description (26 chars) is too short, fails minimum threshold of 50 chars and far below 194-char baseline. Provides no context for WHEN or WHY to call this tool, or what data it returns.
exchange-rate 'question' parameter lacks constraint documentation. Zod schema has min/max (0-1000) but description does not mention character limits or expected format. LLMs cannot read JSON Schema, they rely on description text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
get-weather-data accepts no parameters but is a weather tool. Should accept location (required), date_range (optional), units (enum: celsius|fahrenheit). Current design forces the tool to guess what weather data the agent wants.
Error handling is minimal. Both tools have try-catch blocks that log to console.error and re-throw. No recovery guidance, no error categorization, no actionable messages for the LLM. A timeout or 4xx error gives the agent nothing to act on.
No pagination support. Both tools call external APIs that could return large datasets. Without limit/offset parameters and total count in responses, large results will blow context windows.
exchange-rate returns JSON.stringify(res.data) as a text blob. No parsing or field extraction. LLMs must parse unstructured JSON strings, which is error-prone and wastes tokens.
No idempotency hints. Both tools appear to be read-only (correct) but do not declare idempotentHint or any toolAnnotations. Schema registration via Zod is present but no risk classification or safety annotations.