Loading ToolBench
Dynamic OpenAPI-to-MCP Bridge Engine — an MCP server that ingests OpenAPI 3.x specs and exposes validated tools to LLMs.
Only 1 tool visible in source (health). The server is designed to dynamically register OpenAPI operations as tools, but the actual tool definitions are generated at runtime from OpenAPI specs, not statically visible in code. This violates the scoring principle: 'If you cannot see the actual tool definition in the source, cap that tool's overall at 50.' The health tool has a minimal description (18 chars, below 20-char threshold) and a trivial schema. No parameter descriptions visible. No output schema documented. Error handling is absent. The dynamic tool generation pattern is not inspectable for quality.
Health check for the OpenAPI bridge server.
Tool definitions are generated dynamically at runtime from OpenAPI specs; static code analysis cannot verify schema quality, parameter descriptions, or output documentation for the actual tools exposed to LLMs.
Health tool description is 18 characters ('Health check for the OpenAPI bridge server.'), below the 20-char minimum.
Health tool has no parameter descriptions. The 'echo' parameter lacks any explanation of its purpose, format, or constraints. LLMs cannot infer parameter meaning from names alone.
No output schema documented for any tool. LLMs need to know what fields to expect in responses to plan downstream calls and extract data correctly.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | <=2025-11-25 | v2 |
No error handling guidance. Tool handlers return raw HTTP responses without categorizing errors as retryable, user-fixable, or fatal. LLMs receive no recovery hints.