Loading ToolBench
Turn any OpenAPI spec into a working MCP server — give Claude tools for any REST API in 30 seconds, zero codegen.
mcp-forge exposes a single dynamically-generated tool 'dynamic_openapi_tools' that proxies OpenAPI operations. The tool definition is vague and generic: its description states operations are 'dynamically converted' but does not explain WHAT the tool does, WHEN to use it, or what the user should expect. Input schema uses generic 'parameters' and 'body' objects with minimal type information, no enum constraints, no per-parameter descriptions, no format guidance. The tool name itself is not action-oriented (should be verb_noun like 'call_api' or 'invoke_openapi_operation'). Error handling returns raw HTTP responses truncated at 8000 chars with no recovery guidance. No output schema is documented. This design treats the tool as a generic pass-through rather than a curated, LLM-friendly interface.
Each OpenAPI operation is dynamically converted into an MCP tool. Tool names, descriptions, parameters, and methods are derived from the OpenAPI spec at runtime.
Tool name 'dynamic_openapi_tools' is not action-oriented. Should start with a verb (e.g., 'call_api', 'invoke_openapi_operation') to signal intent to the LLM. Current name is a noun phrase that does not convey what happens when called.
Tool description is generic and incomplete. It states operations are 'dynamically converted' but does not explain WHAT the tool does from the user's perspective, WHEN to call it, or what output to expect. LLMs cannot determine tool selection without a clear, actionable description (10 - 1024 chars, currently ~100 chars but vague).
Input schema uses generic 'parameters' and 'body' objects with no per-parameter descriptions, types, or constraints. LLMs cannot infer what each parameter controls. Schema should document each OpenAPI parameter (path, query, header) with type, required flag, and description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 27 | 2026-07-28+ | v2 |
No output schema is documented. LLMs do not know what fields to expect in the response, making it impossible to plan downstream tool calls or extract relevant data. HTTP status + truncated body (8000 chars) is not a structured schema.
Error handling returns raw HTTP responses with no recovery guidance. A 404 or 500 error tells the LLM nothing about what to do next. Errors should be categorized (retryable, user-fixable, fatal) and include actionable guidance.