Loading ToolBench
A Next.js application for managing MCP (Model Context Protocol) servers and tools, providing analytics, discovery, and execution capabilities
pluggedin-app demonstrates solid definition quality with well-structured tool schemas and consistent descriptions. All 5 tools have explicit type schemas with proper input validation. Tool names follow verb_noun convention clearly (list_, open_, get_, ask_). Descriptions are generally actionable (ranging 95-170 chars, within the 10-1024 target). Parameter descriptions are present and explain purpose. However, there are notable gaps: no output schemas documented for any tool, no error handling guidance, no pagination support documented despite tools returning potentially large result sets, and missing parameter constraints (e.g., no enum for hub selection despite 'hub' being optional across multiple tools). The 'pluggedin_open_hub' tool has weak description clarity around state management. Response field structure is not documented, forcing LLMs to infer what fields will be returned.
Ask a question answered from the documents in a Plugged.in Hub, with the sources it drew on. Use this instead of listing and reading documents when the user asks something the Hub's contents would answer.
Fetch one document from a Plugged.in Hub by the id returned from pluggedin_list_documents.
List the documents stored in a Plugged.in Hub. Returns each document with an id to pass to pluggedin_get_document.
List the Plugged.in Hubs this connection may reach. Returns each Hub with a handle to pass to other tools. Call this first when the user has more than one Hub.
Select the Hub for subsequent calls, by name or by a handle from pluggedin_list_hubs. Only Hubs granted when the connection was authorized can be opened.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract relevant fields without knowing what fields are returned. This violates pattern:tool and pattern:response-shaper.
No pagination guidance despite list_hubs, list_documents, and ask_knowledge_base returning potentially large result sets. Tools accepting optional 'hub' parameter lack enum constraints or discovery guidance. No documented limits on result size.
pluggedin_open_hub description is ambiguous about state management. 'Select the Hub for subsequent calls' doesn't clarify whether this is stateful (session-level) or request-local, or how it interacts with the optional hub parameter in other tools. Per MCP spec 2026-07-28, protocol is stateless, description should clarify behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 73 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | 1.27.1+ | v1 |
No error handling guidance. Tools do not document error conditions, recovery paths, or how the LLM should handle failures (e.g., if a hub is not found, if a document does not exist, if the knowledge base query returns no results).
Tool descriptions lack 'When to use this tool' context. No guidance on when to call list_documents vs ask_knowledge_base, or how pluggedin_open_hub affects subsequent calls vs the optional hub parameter. This forces LLMs to guess tool selection logic.
Parameter descriptions lack format/constraint details. The 'hub' parameter (string) appears in multiple tools with description 'Hub name, or a handle from pluggedin_list_hubs' but no guidance on format, length, or how to disambiguate when both name and handle are valid. The 'query' parameter in ask_knowledge_base lacks length/format guidance.