Knarr is a peer-to-peer exchange protocol implementation, not an MCP server. The three tools ('echo', 'add_numbers', 'error_tool') exist only in a test fixture file (tests/fixtures/mock_mcp_server.py) used for testing the protocol implementation itself. These are toy/mock tools with minimal descriptions, no parameter annotations, and no real-world utility. The definitions lack the rigor required for production agents. Tool descriptions are extremely brief (13-27 chars), well below the 194-char baseline for production tools. Parameters lack documentation entirely. No error recovery guidance. This is a protocol test suite, not a production agent tool server.
Adds two numbers
Echoes input text
A tool that returns an error
Mock test tools, not production definitions. All three tools are defined in tests/fixtures/mock_mcp_server.py, a test fixture file. They are not part of the actual Knarr protocol implementation and should not be evaluated as a real MCP server.
Descriptions are trivial and non-actionable. 'Echoes input text' (13 chars), 'Adds two numbers' (16 chars), 'A tool that returns an error' (27 chars) are far below the 194-char production baseline. No guidance on WHEN to use, WHAT to expect, or next steps.
No parameter descriptions. Schema shows properties 'text', 'a', 'b' with no documentation of format, constraints, or purpose. LLMs cannot reason about how to invoke these tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 28 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | 2025-03-26+ | v1 |
error_tool has empty input schema (no properties, no required fields). Unclear what it does or what inputs trigger different error states. Non-functional definition.
No output schemas documented. Clients cannot predict what these tools return or how to parse results.
No error handling guidance. If these tools fail, there is no mechanism to guide the LLM toward recovery (retry, ask user, or abort).