Loading ToolBench
MCP server for querying Knife4j / Swagger multi-module API docs
Four tools with clear verb-noun naming (list_, find_, get_, refresh_). Descriptions are present and moderately detailed (100-200 chars), explaining WHAT and WHEN. Input schemas visible with typed parameters and descriptions. However, output schemas are not documented in the source code provided, and parameter descriptions lack format constraints (e.g., regex patterns, min/max for 'limit'). Error handling guidance is minimal. The 'includeRaw' parameter in get_api_detail hints at response structure but no formal schema is declared. Composition is sound, tools chain logically (find_api → get_api_detail). No security issues detected (read-only operations, no secrets in params).
Find candidate APIs by path, keyword, tag, module, or method. After locating a candidate, call get_api_detail with its module, path, and method to read the full indexed API documentation instead of fetching Swagger/OpenAPI spec URLs directly.
Preferred tool for API documentation. Use module + exact path + HTTP method to read recursively expanded request and response schemas. Set includeRaw=false for a compact, agent-friendly response; omit it for the backward-compatible full response. Do not fetch spec URLs directly.
List aggregated Knife4j / Swagger modules and their loading status. Use this for module discovery and diagnostics, not for reading API details or fetching spec URLs directly.
Force a reload of swagger-resources and all module specs while keeping partial failures isolated. Use this when upstream docs changed or when a previous lookup returned stale results.
Output schemas not documented. No formal declaration of what list_specs, find_api, get_api_detail, and refresh_specs return. LLMs cannot plan downstream calls or extract fields without knowing response structure.
Parameter constraints missing. 'limit' in find_api has no min/max bounds stated in description (should be 1-100 per description text). 'offset' lacks guidance. LLMs may pass invalid values.
Error handling guidance absent. No recovery hints in descriptions. E.g., if get_api_detail fails with 'module not found', should the LLM call find_api or list_specs first? Not stated.
Pagination not explicitly documented. find_api accepts 'limit' and 'offset' but no mention of total count or next_cursor in response. LLMs cannot determine if more results exist.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2025-06-18+ | v2 |
Tool composition clarity: get_api_detail requires exact 'path' and 'method' from find_api results. If find_api returns abbreviated paths, chaining breaks. No explicit guarantee that find_api output contains the exact fields get_api_detail needs.