Loading ToolBench
MCP server for semantic search and documentation assistance across indexed API documentation and guides. Provides tools for searching endpoints, guides, and retrieving full API specifications.
Multidocs has 5 tools with basic schemas and descriptions, but significant gaps prevent production use. Tool names are action-oriented (search_*, get_*, list_*, ask_*), which is good. However, descriptions are generic (10-50 chars for most), parameter descriptions are minimal or absent, and output schemas are completely undocumented. The ask_multicard tool introduces statefulness (session_id) which violates stateless design. No error handling guidance, no pagination support despite search tools returning top-5 results, and no validation constraints on inputs. Code review shows tools are defined via FunctionTool wrappers in app/agent/tools.py, but the MCP server registration in app/mcp/server.py is not visible in the provided source, making tool definitions partially inferred.
Ask the Multicard documentation assistant a question using the full agent.
Get the full JSON specification for a specific API endpoint.
List all available API endpoints with their summaries, optionally filtered by tag.
Search all indexed Multicard documentation for relevant information.
Search API endpoint definitions by semantic similarity.
Output schemas completely undocumented. Tools return string responses (e.g., search_docs returns formatted text chunks), but LLMs cannot parse structure or extract fields for downstream tool calls. No documented return types, field names, or data types.
Parameter descriptions missing or trivial. 'query' param in search_docs/search_endpoints has only 'Search query string', no guidance on format, length, or examples. 'tag' param in list_api_endpoints has no description at all. LLMs cannot infer valid input ranges or constraints.
ask_multicard introduces statefulness via session_id parameter, violating stateless request design. MCP protocol (2026-07-28) requires each request to be self-contained. Session management should be handled server-side or via resource URIs, not tool parameters.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | <=2025-11-25 | v2 |
No pagination or result limits documented. search_docs and search_endpoints return top-5 results, but tool descriptions do not mention this limit. No offset/limit parameters, no next_cursor, no total_count. Large result sets will blow context windows.
No error handling guidance. Tools return plain strings on failure ('No results found...'), but LLMs cannot distinguish success from failure or know what to do next. No recovery suggestions, no categorization of retryable vs fatal errors.