Loading ToolBench
Load an OpenAPI document at startup and expose it as a Model Context Protocol (MCP) server over stdio, SSE, or Streamable HTTP.
oas2mcp exposes a single dynamic tool 'dynamic_openapi_operations' that proxies OpenAPI specs as MCP tools. Critical issues: (1) Tool name lacks action verb, 'dynamic_openapi_operations' is a noun phrase, not verb_noun (e.g., 'call_api_operation'). (2) Input schema is empty object {} with description stating 'Schema is dynamically generated per operation', this is NOT a valid schema visible in code; the actual per-operation schemas are generated at runtime and not inspectable statically. (3) Tool description is 280 chars but generic, does not explain WHEN to use this tool, what prerequisites exist, or how to invoke specific operations. (4) No parameter descriptions visible in the static schema. (5) No output schema documented. (6) No error handling guidance (e.g., what happens if upstream API returns 500, or if OpenAPI spec is malformed). The tool is a meta-tool that dynamically generates other tools, which is architecturally sound, but the MCP registration itself lacks the rigor required for production agent use.
Each OpenAPI operation defined in the loaded document is exposed as a separate MCP tool. Tool names are derived from operationId or synthesized from HTTP method and path. Each tool accepts parameters matching the OpenAPI operation's parameters (path, query, header) and optional JSON request body, and proxies the call as an HTTP request to the upstream API.
Input schema is empty object {} with no visible parameter definitions. Dynamic schemas generated at runtime are not inspectable by MCP clients at registration time.
Tool name 'dynamic_openapi_operations' is a noun phrase, not verb_noun. Should start with action verb (e.g., 'call_api_operation', 'invoke_openapi_endpoint'). LLMs rely on verb-first naming to infer intent.
No output schema documented. Clients cannot predict what fields the tool returns or plan downstream tool calls.
Tool description lacks WHEN/WHY guidance. Does not explain prerequisites (e.g., 'OpenAPI spec must be loaded at startup'), how to reference specific operations, or error recovery paths.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | <=2025-11-25 | v2 |
No error handling guidance. Tool description does not explain what happens if upstream API fails, returns non-JSON, or if OpenAPI spec is invalid. Per pattern, errors must guide recovery.