Loading ToolBench
Multi-server MCP project with string tools, calendar assistant, calculator, and search/weather capabilities
This server has significant quality gaps across naming, descriptions, schemas, and error handling. Of 9 tools, most lack proper parameter descriptions and none have documented output schemas. Tool names are moderately clear but descriptions are often too brief (under 20 chars for some). No error handling guidance, no input validation messages, and no output structure documentation. The codebase shows FastMCP usage but lacks production-grade tool definition patterns. Schema registration appears present via FastMCP decorators, but parameter-level documentation is minimal.
Append a new note to the note file.
Counts the number of words in a sentence.
Fetch current weather for a city
Get anniversary information for this week
Get events scheduled for a specific day
Fetch search results from Yahoo using Serper.dev and httpx
Multiply two integers
Parameter descriptions missing or minimal. Tools like 'mul(a, b)', 'count_words(text)', and 'get_events(day)' lack context about acceptable values, formats, ranges, or constraints. LLMs cannot infer parameter intent from names alone.
No documented output schemas. All 9 tools return data but none document what fields the LLM should expect in the response. This forces LLMs to guess at structure and prevents downstream tool composition.
Descriptions are too brief or generic. 'Reverses the given string' (30 chars), 'Multiply two integers' (21 chars), and similar descriptions lack context on when to use the tool or what makes it distinct from alternatives.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Read and return all notes from the note file.
Reverses the given string.
No error handling or recovery guidance. Tools like 'fetch_weather' and 'google_serper_search_results' call external APIs but provide no guidance on failure modes (invalid city, API key missing, rate limit, timeout). LLMs receive raw errors with no recovery path.
No input validation or constraint documentation. Parameter types exist in FastMCP decorators but no min/max ranges, enums, regex patterns, or format constraints are visible. LLMs may pass invalid values without feedback.
Tool names lack clarity for disambiguation. 'get_events' could mean calendar events, system events, or notifications. 'read_notes' vs 'add_note' do not indicate whether notes are persistent, shared, or scoped. Names are not specific enough to guide LLM selection in a dense tool list.
API response dumping without filtering. 'google_serper_search_results' and 'fetch_weather' return raw HTTP response text (response.text). No stripping of metadata, pagination internals, or irrelevant fields. This wastes tokens and dilutes signal.
Secrets exposed via environment variables without per-request validation. SERPER_API_KEY and WEATHER_API_KEY are injected at startup. No rate limiting, API key rotation hint, or error message if keys are missing/invalid. Agents cannot know if a failure is auth or data.