Loading ToolBench
A collection of MCP (Model Context Protocol) server implementations demonstrating various use cases including weather data, local notes management, and screenshot capture
This MCP samples repository contains 4 basic tools distributed across multiple server files. All tools are explicitly defined using FastMCP's @mcp.tool() decorator with visible schemas and descriptions. However, the definitions are significantly below production baseline: descriptions are minimal (10-70 chars, well below the 194-char average for A+ tools); parameter descriptions are sparse or absent; output schemas are not documented; error handling is minimal; and no security patterns are applied. The STDIO transport caps protocol readiness at 50. Overall quality places this squarely in the D/F range, appropriate for teaching examples but not production use.
Append the given content to user's local notes. Args: content: The text content to append to the file.
Capture a screenshot of the current screen and return it as an image. Use this tool when the user requests a screenshot of their activity.
Get the current weather for a given location.
Read and return the content of the local notes.
No output schemas documented. Tools return unstructured strings or Image objects with no documented return type structure. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Descriptions too short and lack actionable context. get_weather (44 chars) does not explain when to use it vs other weather tools, what format the location should be, or what the response contains. read_notes_from_file (58 chars) lacks any indication of output structure or prerequisites. Baseline for A+ tools is 194 chars; these are 23-30% of that.
Parameter descriptions missing or generic. get_weather's 'location' param has a 1-line description but no format guidance (city name? coordinates? country code?). add_notes_to_file's 'content' param repeats the tool docstring. No LLM-facing hints on what constitutes valid input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Error handling returns generic strings ('An error occurred: {e}') with no recovery guidance. LLM cannot distinguish retryable errors from fatal ones or know what corrective action to take. Baseline patterns require categorized errors with next-step hints.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Especially critical for add_notes_to_file (write operation), LLM has no formal notice that this is irreversible. read_notes_from_file should be marked read-only. Current MCP spec (2026-07-28) includes tool annotations; their absence is a compliance gap.
File I/O without permission checks or security gates. add_notes_to_file and read_notes_from_file access 'notes.txt' in the current directory with no user identification, no access control, and no audit trail. In a multi-user or multi-agent environment, any agent can read/write all notes.
capture_screenshot returns binary image data with no access control or user consent mechanism. In a shared environment, an agent could screenshot sensitive user activity without explicit permission or audit trail.
No pagination, rate limiting, or result caps. get_weather does not specify if results are paginated. In a real service, large unstructured responses would bloat context and degrade LLM reasoning. Baseline patterns enforce per-tool result limits (e.g. 20-50 items).
Tool names use verbs but lack consistent verb_noun convention. 'capture_screenshot' is strong, but 'add_notes_to_file' and 'read_notes_from_file' could be shortened to 'add_note', 'read_notes' for clarity. 'get_weather' is correct. Inconsistency reduces discoverability.