A demonstration MCP server with user management tools
Two tools with basic schemas and minimal descriptions. getUserInfo and updateUserEmail both have Zod schemas (userId: string.min(1), newEmail: string.email()) visible in tools.js, but descriptions are extremely short (10-20 chars) and lack context for LLM selection. No output schema documented. No error recovery guidance. No parameter descriptions beyond type constraints. Naming is acceptable (verb_noun pattern) but descriptions fall well below the 50-200 char baseline for A+ tools. Error handling throws generic 'User not found' without recovery hints.
Fetch user info by ID
Update a user's email
Descriptions are critically short (10-20 chars). 'Fetch user info by ID' and 'Update a user's email' lack context for when/why to use each tool, prerequisites, or what the LLM should expect. Baseline for A+ tools is 50-200 chars.
No output schema documented. LLMs cannot plan downstream calls or extract required fields. Both tools return { user } but structure of user object is not declared.
Parameter descriptions missing. 'userId' parameter has no description in tool registration (only Zod constraint z.string().min(1)). 'newEmail' has no description. LLMs cannot infer that userId is a system identifier or that newEmail must be valid.
Error handling is non-actionable. Both tools throw 'User not found' with no recovery guidance. Should suggest 'Try search_users() or list available user IDs' to guide the LLM's next step.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2025-06-18+ | v2 |
updateUserEmail modifies state but description does not explicitly state this. LLMs need to know which calls are safe to retry and which have irreversible consequences.