A template for creating MCP-compliant FastAPI services.
This is a template/example MCP server with minimal real functionality. It defines exactly ONE tool ('new_endpoint') with adequate but bare-minimum schema and description. The naming is acceptable but generic, the description is present but short (59 chars), and the input schema is properly typed but lacks detailed parameter documentation. No error handling guidance, no output schema documentation, and no complex patterns demonstrated. This is appropriate for a template, it is NOT a fully-featured production server and should not be scored as one.
A template endpoint that accepts a name and returns a welcome message.
Tool name 'new_endpoint' is generic and non-idiomatic. Does not start with a clear action verb (create_, send_, get_). Recommend 'create_greeting' or 'generate_welcome_message' to signal intent.
Tool description is only 59 characters, below the recommended 10 - 1024 range baseline (p10=34, p90=392). While technically adequate, it lacks context on WHEN or WHY to use this tool. Expand to explain the use case and any prerequisites.
Input parameter 'name' has a description but no additional constraints (min/max length, character restrictions). For string parameters, specify length limits and character set expectations to prevent LLM hallucination of invalid inputs.
Output schema is visible in schemas.py (NewEndpointResponse with 'message' field) but NOT documented in the tool description or inline. LLMs should know what fields and types to expect in the response. Document the response structure in the tool description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
No error handling guidance. What happens if 'name' is an empty string, null, or contains special characters? How should the LLM handle failures? Add error cases and recovery steps to the tool description.