Loading ToolBench
This is a test fixture library, not a production MCP server. All 5 tools are test fixtures defined in unit test files (McpServerToolCallingTest.class.php), not in the main codebase. The tools lack parameter descriptions, input schemas are minimal or absent, and there is no evidence of production tool definitions. The framework itself (McpServer.class.php) provides the transport and protocol plumbing, but no real tools are implemented. Tool naming ('fixture') violates the verb_noun convention. Descriptions are generic test labels, not LLM-optimized guidance. Per the hard scoring rules, tools without visible schemas and with non-substantive descriptions cannot score above the threshold for poor definitions.
Test fixture tool that returns 'Hello World'
Test fixture tool that accepts input parameter and returns greeting
Test fixture tool that uses Value injection to access user context
Test fixture tool that uses named Value injection to access user context
Test fixture tool that returns a Result with text and annotations
All 5 tools are test fixtures in unit tests, not production tools. No real MCP server implementation is present, only framework code.
Tool naming violates verb_noun convention. All five tools are named 'fixture', which is a generic test label, not an action verb. LLMs cannot infer intent from 'fixture'.
Descriptions are non-substantive test labels (e.g., 'Test fixture tool that returns Hello World'). They do not explain WHAT the tool does, WHEN to use it, or WHAT it returns in production context. Descriptions under 20 meaningful characters cannot guide LLM selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 28 | <=2025-11-25 | v2 |
Input schemas are missing or incomplete. Tool 1 has empty {}, tool 2 has minimal schema with no type constraints, tools 3 - 5 have no visible schemas.
Parameter descriptions are absent. Tool 2's 'input' parameter has a minimal description ('User input to include in greeting') but lacks format, length, or example constraints. Tools 3 - 5 use dependency injection (#[Value], #[Param]) with no documentation of what these resolve to.
No documentation of output schemas. Test assertions show responses contain JSON-RPC 2.0 structures with 'content', 'type', 'text', and 'annotations' fields, but there is no formalized schema for LLMs to understand the return type.
Error handling in test code shows generic error messages (e.g., 'No access', 'test_fixture') without recovery guidance. An LLM receiving 'No access' does not know whether to retry, ask the user, or give up.