FastAPI + MCP coding test project - a FastAPI server with MCP tool invocation endpoints for user management
Server implements 5 CRUD tools with complete input schemas and basic descriptions. All tools have proper JSON Schema definitions with type constraints (minLength, maxLength, gt). Descriptions are present but minimal (10-40 chars), lacking context on WHEN to use each tool and what happens on error. No output schemas documented. Parameter descriptions exist but are generic ('User name', 'User ID'). Missing error recovery guidance and idempotency hints for destructive operations. Naming follows verb_noun convention correctly (create_user, get_user, etc.). No tool annotations (readOnlyHint, destructiveHint) despite clear risk stratification.
Create a new user with name and email
Delete a user by ID
Retrieve a user by ID
List all users
Update an existing user by ID
Descriptions are too brief (10-40 chars) and lack context. 'Create a new user with name and email' does not explain when to use this vs update_user, what happens on duplicate email, or that this is a write operation with side effects.
No output schema documented. LLMs cannot plan downstream calls or extract required fields (e.g., user_id returned by create_user for chaining to update_user).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). Agents cannot distinguish safe from dangerous operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
No error recovery guidance. HTTPException responses (404, 400, 422) lack actionable next steps. E.g., 'User not found' should suggest 'Try list_users() to find the correct ID.'
list_users has no pagination (limit, offset, page_size). Returning all users without bounds risks context window exhaustion and token waste.