Loading ToolBench
Official MCP v2 server exposing Resolve's closed support knowledge base with hybrid-RAG retrieval capabilities
Two tools with clear verb-noun naming (search_*, get_*) and complete input schemas. Both have descriptions and parameter annotations. However, descriptions are terse (under 100 chars), output schemas are not documented in the visible code, and error handling guidance is absent. Tool annotations are present (read_only_hint, open_world_hint) which is a positive signal. No parameter validation examples or recovery guidance in descriptions.
Fetch one exact support passage by its stable chunk ID.
Hybrid-search Resolve documentation using dense, BM25, and RRF retrieval.
Output schemas not documented. SearchResults and DocumentLookup types are imported but their structure is not visible in the provided code. LLMs cannot plan downstream operations without knowing what fields to expect.
Descriptions lack recovery guidance and prerequisites. 'Hybrid-search Resolve documentation...' does not explain when to use search vs get, what happens on no results, or how to handle chunk_id mismatches.
No error handling guidance. Descriptions do not explain what happens if query is too broad, chunk_id is invalid, or knowledge base is unavailable. LLMs have no recovery path.
search_support_knowledge limit parameter lacks guidance on result quality vs quantity tradeoff. Description should explain why limit=5 is default and when to increase it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
No pagination or result count documentation. If search returns 5 results, does that mean 5 total exist or 5 of many? Without total_count or next_cursor, LLMs cannot determine if they need to refine the query.