Loading ToolBench
The canary for your MCP server: probe it, drill it with YAML tests, lint its config. In CI, not in a GUI.
This is a test fixture server, not a production tool. Tool names are generic verbs without clear intent (add, echo, fail, stats). The 'mystery' tool has no description at all. Two tools ('dup_one', 'dup_two') have identical descriptions, violating the clarity principle. Input schemas exist but parameters lack descriptions entirely, this is a hard failure per the rubric: 'Every parameter needs a description.' The server is intentionally poorly-described to serve as a test target for the mcpcanary linter itself, not as a production example.
Adds two numbers and returns the sum.
Does a thing.
Does a thing.
Echoes back whatever it receives.
Always returns an error result (for testing isError paths).
Returns structured JSON about a fictional dataset.
All parameters lack descriptions. Rubric requires 'Every parameter needs a description explaining what it controls.' Parameters 'a', 'b', 'message', 'x' have null descriptions.
Tool 'mystery' has no description at all. Rubric: 'Every tool must have a non-empty description. Without one, LLMs cannot determine when or why to select the tool.'
Tools 'dup_one' and 'dup_two' have identical descriptions ('Does a thing.'). Rubric: 'When multiple tools operate on the same resource, their names must make the distinction obvious.' Identical descriptions violate clarity.
Tool names are generic and lack action verbs. 'add', 'echo', 'stats' do not follow verb_noun convention. Rubric: 'Start tool names with a verb that reflects the action: get_, create_, update_, delete_, search_, list_, send_.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2025-06-18+ | v2 |
No output schemas documented. Rubric: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.'