Loading ToolBench
A FastAPI-based MCP server that provides context retrieval for prompt templates
The server defines a single tool (get_context) with a descriptive name and basic schema structure. However, the implementation has significant gaps in definition quality. The tool description is moderately informative (67 chars), but parameter descriptions are minimal and lack actionable constraints. The schema is visible and includes type information, but lacks critical details like parameter constraints, output schema documentation, and error handling guidance. The server does not document what format parameters should take, whether they support defaults, or how the tool should handle edge cases. For a production-grade agent tool, this falls short of the 70+ threshold.
Retrieves formatted context for a given prompt ID with optional parameters
Parameter descriptions are minimal and lack actionable constraints. The 'prompt_id' parameter has only 'The identifier of the prompt template to retrieve', no details about valid values, format, or examples. The 'parameters' object has only 'Optional dictionary of parameters to format into the prompt template', no guidance on what keys are valid, their types, or constraints.
Output schema is not explicitly documented in the tool definition. The code returns a ContextResponse with 'context' and 'metadata' fields, but the tool schema visible in the request does not include a documented return type or response structure. LLMs cannot reliably extract output fields without explicit schema documentation.
Error handling lacks actionable recovery guidance. The code raises HTTPException for missing prompts (404) and parameter validation failures (400), but provides no recovery hints. The LLM sees 'Prompt not found' or 'Missing required parameter: ...' with no suggestion for next steps (e.g., 'Call list_prompts() to see available templates').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
No parameter enumeration or constraint documentation. Valid prompt_ids are hardcoded ('greeting', 'data_analysis'), but the schema does not declare these as an enum. LLMs may hallucinate invalid prompt_ids, triggering 404 errors. An enum constraint would prevent misuse.
No documentation of parameter dependencies. The 'parameters' dict contents depend on which prompt_id is selected (e.g., 'greeting' requires 'time', 'data_analysis' requires 'data'). This dependency is not documented in parameter descriptions, forcing LLMs to guess or trial-and-error.