An educational MCP server demonstrating the Model Context Protocol with four simple tools: greeting, dice rolling, cookie jar state management, and Caesar cipher encoding/decoding.
Four tools with clear, action-oriented names and solid descriptions (avg 156 chars, within baseline 194). All tools have complete input schemas with type definitions and parameter descriptions. Naming follows verb_noun pattern (say_hello, roll_dice, cookie_jar, secret_code). Descriptions explain WHAT and WHEN to use each tool. However, output schemas are not formally documented, responses are inferred from code comments. No error handling guidance for edge cases (e.g., what if dice roll fails?). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Parameter constraints are well-defined (enums, min/max bounds). Composition is sound, each tool has one responsibility. Missing: output schema documentation, error recovery guidance, and tool annotations.
Look inside the cookie jar, put cookies in, eat cookies, or refill it. Use this for any question about how many cookies there are.
Roll one or more dice and get the numbers plus the total. Use this any time real randomness is needed -- games, picking a winner, or deciding something by chance.
Say a warm, silly hello to a person by name. Use this when someone asks you to greet, welcome, or say hi to a specific person.
Turn normal text into a secret code, or turn a secret code back into normal text, by shifting every letter along the alphabet. Use this for encoding, decoding, Caesar ciphers, or secret messages.
Output schemas not formally documented. Responses are inferred from code comments and return statements. LLMs cannot reliably predict response structure for downstream tool chaining.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). cookie_jar has WRITE risk but no destructiveHint. Agents cannot distinguish safe vs. risky operations.
No error recovery guidance. cookie_jar returns 'Can't eat X' but does not suggest alternatives or next steps. Errors lack actionable guidance for LLM retry logic.
cookie_jar uses in-memory state (let cookiesInJar = 12) that resets on server restart. No documentation of this limitation or guidance on persistence.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | <=2025-11-25 | v2 |
Parameter 'count' in cookie_jar is optional (default=1) but semantically required for 'add' and 'eat' actions. Undocumented dependency between action enum and count parameter.