Loading ToolBench
MCP server for UseKeen package documentation search
Single tool with adequate schema and description, but significant gaps in parameter documentation and error handling. Tool name follows verb_noun pattern (search_*). Description is 156 chars, within baseline range (p10=34, p90=392). However, 'query' parameter lacks description entirely, critical omission per pattern:tool-description. No output schema documented. No error handling guidance. No tool annotations. Lacks idempotency guarantees and recovery paths.
Search documentation of packages and services to find implementation details, examples, and specifications
Missing parameter description for 'query'. Parameter 'query' has no description field, LLMs cannot infer whether it is required, what format it expects, or how it differs from package_name. Per pattern:tool-description, every parameter needs a description.
No output schema documented. Tool returns JSON via TextContent but does not specify what fields the response contains (e.g., does it return results[], error, metadata?). LLMs cannot plan downstream calls or extract data reliably without knowing the response structure.
No error handling guidance. Error responses are raw JSON with 'error' field but do not guide the LLM on recovery (e.g., 'Package not found. Try search_packages() first.' or 'Rate limited. Retry in 60 seconds.'). Per pattern:recovery-guide, errors must tell the agent what to do next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | <=2025-11-25 | v2 |
No tool annotations. Tool lacks readOnlyHint, destructiveHint, or idempotentHint annotations. The tool is read-only (risk: READ_ONLY), but this is not declared in the schema, LLMs cannot infer safety properties.
No pagination or result limits documented. Tool may return unbounded results, risking context window exhaustion. Per pattern:paginated-result, tools returning lists should accept limit/offset and return total count.