Minimal stdio MCP server with echo, read_file (allowlisted), and counter tools
Three tools with clear names and basic descriptions. All have input schemas with type definitions. However, parameter descriptions are sparse or missing (counter's 'action' enum lacks description; amount description is minimal). Output schemas are not documented. Error handling is present but minimal, read_file returns isError flags but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Naming follows verb_noun convention (echo, read_file, counter) but descriptions are brief (avg ~100 chars, below the 194-char baseline for A+ tools). Schemas are present but incomplete, no documented return types or field descriptions.
Read or change a number that persists for the life of the server process. Actions: "increment", "reset", "get".
Return the text you were given. Use this to check the server is alive.
Read a UTF-8 text file. Only paths inside the configured allowlist are permitted.
counter tool: 'action' enum parameter has no description. LLMs cannot infer that 'increment', 'reset', 'get' are the only valid actions without explicit text.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract structured data without knowing return field names and types.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Counter is stateful and modifies server state, but this is not declared to the client.
read_file error messages are bare strings without structured recovery guidance. 'Refused: ...' tells the LLM nothing about what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
counter description is vague about state persistence and side effects. LLMs need explicit clarity that increment/reset modify persistent state.