Loading ToolBench
A Cookiecutter template for creating MCP servers with Python, FastAPI, and mbxai integration
This is a cookiecutter template, not a finished MCP server implementation. Only one tool (get_weather) is visible and partially defined. The tool has a basic description and schema, but lacks critical production-readiness features. The template itself provides scaffolding but does not demonstrate best practices for parameter descriptions, error handling, or output documentation. The weather tool uses a mock implementation with minimal validation. Parameter descriptions exist but are extremely terse (e.g., 'The location to get weather for' is only 27 chars, below baseline of 72 chars average). No error handling guidance, no output schema documentation, and no field-level descriptions for response objects.
Get weather information for a location.
Parameter descriptions are extremely brief and lack actionable detail. 'The location to get weather for' (27 chars) provides minimal guidance; should be 50-100 chars explaining format (city name, coordinates, zip code), geographic scope, and constraints.
Output schema is not documented. The response dict contains 'location', 'temperature', 'units', 'condition', 'humidity' but the tool definition provides no schema for downstream tools or LLMs to understand the structure. LLMs cannot safely chain outputs without knowing field types and names.
No error handling or validation guidance. The tool accepts any string for 'location' and 'units', there is no validation that units is 'celsius' or 'fahrenheit', no guidance on what happens if the location is invalid, and no recovery instructions for the LLM.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Mock implementation provides no real-world test data. A real weather tool should document API response fields, rate limits, and actual error modes (e.g., 'Location not found', 'API rate limit exceeded'). Mock responses hide these critical details.
Tool description lacks WHEN and WHY context. 'Get weather information for a location' states WHAT but not WHEN to call this instead of similar tools, any prerequisites, or what format the response takes. This violates the prompt-engineering principle: describe What, When, and Why.
Parameter 'units' uses a string default but lacks enum constraint. The description mentions 'celsius or fahrenheit' in free text rather than declaring an enum. This invites LLM hallucination (e.g., 'kelvin', 'rankine'). Should be enum: ['celsius', 'fahrenheit'].