This server has severe deficiencies across all definition quality dimensions. Two tools are defined with minimal descriptions and completely missing input parameter documentation. Tool names are reasonable verbs (get_*), but descriptions are under-specified, input schemas are empty (no parameters documented), and there is no error handling or output schema documentation. The server returns TypedDict objects with basic fields, but the MCP tool definitions do not expose or document the output structure. This is well below production quality.
Get user payment info
Get user profile including name and email
All tools have empty input schemas (no parameters).
Tool descriptions are extremely brief (15 - 18 characters), below the 20-character hard floor.
No output schema documentation. LLMs cannot infer what fields get_profile and get_payment_info return. The code shows TypedDict definitions (ProfileInfo, PaymentInfo), but the MCP tool registration does not expose or describe the output structure.
No error handling or recovery guidance. If a tool fails (network error, permission denial), the server returns an unhandled exception. Agents receive no actionable guidance on whether to retry, ask the user, or abandon the plan.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No tool annotations. Both tools are read-only (they fetch data without side effects), but neither is marked with readOnlyHint. Agents cannot infer which tools are safe to call speculatively.
Hardcoded test data. Both tools return mock values ("渋谷太郎", "[email protected]", masked credit card) instead of accepting a user identifier parameter. This is a proof-of-concept, not a real implementation. In production, tools must accept parameters to identify which user's profile or payment info to fetch.