A simple template MCP server demonstrating basic tool registration with FastMCP
Single-tool server with a simple 'greet' tool. Tool has a clear action verb name, basic description, and typed input schema with a sensible default. However, the description is minimal (30 chars), lacks context about when to use it, and the output schema is entirely undocumented. Parameter description is present but terse. No error handling guidance, no idempotence declaration, no resource-chaining considerations. The implementation is straightforward but falls short of production-grade quality standards for agent-facing tools.
Greet someone by name.
Tool description too short (30 chars, baseline 194 chars avg for A+ tools). Lacks context on when/why to use this tool, expected return format, and whether it's safe to call repeatedly.
Output schema not documented. Tool returns a string but this is implicit from the Python return type hint, not visible in the JSON schema or tool metadata. LLMs cannot reliably infer return structure.
Parameter description minimal (25 chars). Baseline is 72 chars for A+ tools. Should clarify format, length constraints, and whether null/empty names are valid.
No error handling documented. Tool could fail (e.g. if name is extremely long, or contains invalid characters) but no guidance on recovery or retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Tool is too trivial for production agent use. A greet tool with no parameters other than a name provides no utility in real workflows. Consider demonstrating with a tool that has realistic error cases, input validation, or chaining dependencies.