The Swiss Army knife for MCP (Model Context Protocol) — create, test, inspect, and wrap MCP servers with ease.
Three tools with minimal definitions. All have basic schemas with required parameters and type declarations, but descriptions are extremely terse (10-30 chars, well below the 50-200 char baseline for LLM-optimized tools). Parameter descriptions are present but generic. No output schemas documented. No error handling guidance. Tools lack context about when to use them or what they return. This is a scaffolding/demo server, not production-grade.
Add two numbers together
Say hello to someone
Get the current timestamp
Descriptions are critically short (10-30 chars). Baseline is 50-200 chars for LLM-optimized tools. 'Say hello to someone' and 'Add two numbers together' lack context about when to use these tools, what they return, or dependencies.
No output schemas documented. LLMs cannot plan downstream calls or extract return values without knowing the response structure. E.g., does 'hello' return {greeting: string} or {message: string, timestamp: number}?
Parameter descriptions are generic. 'Name to greet' is minimal; should explain format (first name only? full name? email?), constraints (max length?), and examples. 'First number' and 'Second number' lack type hints (integer vs float?) and range constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Tool names lack action verbs. 'hello' and 'timestamp' are nouns, not verb_noun patterns. Should be 'greet_user' and 'get_current_timestamp' to signal intent clearly to LLMs.
No error handling guidance. If 'add' receives non-numeric input or 'hello' receives an empty name, what happens? LLMs need recovery hints, not stack traces.