Loading ToolBench
An MCP server for loading and searching OpenAPI/Swagger specifications.
mcp-swagger has 3 tools with complete schemas and reasonable descriptions, but suffers from moderate issues in parameter documentation, output schema clarity, and error guidance. Naming is acceptable (verb_noun pattern), but descriptions lack LLM-optimization depth. Parameter descriptions exist but are generic; several parameters lack actionable constraints. Output schemas are not documented, LLMs cannot infer what results they will receive. Error handling is minimal, no recovery guidance or actionable error messages. Tool composition is adequate (each does one thing), but the server lacks idempotency hints and missing-resource enrichment.
List loaded specifications and the active spec.
Load an OpenAPI/Swagger specification from a documentation URL.
Intelligently search for API endpoints within the loaded specification.
Output schemas are not documented. LLMs cannot predict what fields will be returned from load_spec, search_endpoints, or list_specs. Callers must guess structure, risking extraction errors and hallucinated field names.
Parameter descriptions lack actionable constraints. 'spec' in search_endpoints accepts string, array of strings, or undefined, but the description does not explain how each option affects behavior. 'scope' has enum values [primary, fallback, all] but no description of what each means or when to use them. LLMs will guess wrong.
No error recovery guidance. If load_spec fails due to invalid URL or unreachable endpoint, the tool returns raw error messages. No guidance on what to do next, retry, try a different URL, check format? Error responses should be actionable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Tool description for search_endpoints is vague. 'Intelligently search' is marketing language, not an actionable specification. What algorithm is used? What fields are searched (path, summary, tags)? When would you use this instead of list_specs and manual filtering?
No pagination guidance in search_endpoints. If search results are large, what happens? Are results capped? Can the LLM request page 2? Unbounded result sets risk context window overflow.
load_spec is marked WRITE but 'setActive' boolean parameter has no description explaining what happens when true vs false. Does it override a previous active spec? Does it clear a list? LLMs cannot predict side effects.
list_specs description is 55 chars ('List loaded specifications and the active spec.'), which is minimal. Does not explain when to call it, is it discovery before search? Before load? LLMs benefit from guidance on tool sequencing.