Loading ToolBench
A generic MCP server that takes any OpenAPI/Swagger specification and exposes it as MCP tools, allowing AI assistants to search, explore, and execute any REST API.
The OpenAPI MCP Bridge provides 4 tools with mixed definition quality. All tools have descriptions and input schemas are present, but several critical patterns are missing or incomplete. Descriptions are present but vary in quality; some lack specific guidance on when to use tools vs. alternatives. Parameter descriptions exist but lack constraint documentation (enums, ranges, patterns). Output schemas are not formally documented in code, responses are returned as dicts without type annotations or schema declarations. Error handling is basic with some guidance but lacks categorization (retryable vs. user-fixable). The execute_endpoint and batch_execute tools represent irreversible operations but lack comprehensive pre-execution safeguards beyond a simple boolean flag. The server uses STDIO transport (hard cap at 50), but definition quality is analyzed independently and reaches 58 due to partial pattern coverage.
Execute multiple API endpoints in parallel or sequentially. Always requires user confirmation before execution since batch operations are inherently risky.
Execute an API endpoint. For destructive operations (DELETE, PUT, PATCH), set confirmed=true after user approval.
List all registered OpenAPI/Swagger APIs available for querying. Returns a list of APIs with their name, base_url, description, authentication type, and number of endpoints.
Search for API endpoints by natural language description. Returns matching endpoints with full details including parameters, request body schema, and response schema, along with similarity scores.
Output schemas not formally documented. Tools return dicts with untyped fields, forcing LLMs to parse responses without knowing field types, structure, or what to expect for chaining downstream calls.
Parameter constraints not documented in descriptions. 'method' param in execute_endpoint lists valid values in description text ('GET, POST, PUT, DELETE, PATCH') rather than as an enum constraint. 'limit' and 'offset' lack min/max bounds. 'confirmed' boolean lacks explanation of when confirmation is truly required vs. optional.
Irreversible operations (execute_endpoint DELETE/PUT/PATCH, batch_execute) use a simple boolean 'confirmed' flag without dry-run capability. No preview of what will be modified before confirmation. Pattern:confirmation-request recommends showing what changes before asking for approval.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 12 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Error responses lack actionable recovery guidance. When API not found, response returns error and available_apis list, but does not explicitly guide next action (e.g., 'Call list_apis() to discover available APIs'). Error categorization (retryable vs. fatal) is absent.
Tool descriptions lack dependency hints and clear prerequisites. search_endpoints description does not state 'Call list_apis() first to discover available APIs'. execute_endpoint does not warn about API availability checks.
Parameters named generically without type suffixes. 'api' parameter is a string but unclear if it expects a system name, display name, or ID. No guidance on what to pass if only a partial name is known. Pattern recommends 'api_name' or 'api_id' for clarity.
batch_execute 'requests' parameter is documented as 'List of request configs' but structure and required fields are not specified. LLMs cannot determine valid structure without explicit schema of request object (path, method, params, body, headers).
Response truncation ('limit' param in execute_endpoint, 'offset' param) assumes pagination is always needed. No documentation of what happens when results fit in limit, or how to detect 'more results available'. Pagination pattern incomplete.