Loading ToolBench
A simple MCP server for running integration tests through automation.
This server has critical definition gaps. Both tools lack input parameter schemas entirely, no JSON Schema visible in the source. Tool descriptions are minimal (16-28 chars, well below the 34-char p10 baseline). No parameter descriptions exist. The codebase shows Express route handlers with no formal tool registration, schema validation, or structured output documentation. Controllers accept generic req/res objects with no type safety or input validation. This is a basic HTTP API, not a production-grade MCP server.
Logic for retrieving test results
Logic for running integration tests
No input schemas visible for either tool. runTest and getTestResults have no JSON Schema definitions, parameter types, or constraints.
Tool descriptions are trivial (16-28 chars). 'Logic for running integration tests' and 'Logic for retrieving test results' do not explain WHAT the tool does, WHEN to use it, or WHAT it returns. LLMs cannot determine tool selection from these.
No parameter documentation. runTest likely accepts test identifiers or filters; getTestResults likely accepts filters or pagination. Neither is documented. LLMs cannot infer parameter meaning from names alone.
No output schema documentation. Controllers return generic { message: '...' } and { results: '...' } responses. LLMs do not know what fields to expect or how to chain downstream calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 18 | 2026-07-28+ | v2 |
No error handling or recovery guidance. Controllers do not validate input, handle failures, or return actionable error messages. A failed test run returns nothing; LLM has no guidance on retry or next steps.