Loading ToolBench
Lightweight MCP proxy and heavy backend for Claude Skills with vector search capabilities. Auto-downloads backend, performs semantic search over a curated library of proven skills with step-by-step guidance.
Three well-named tools with clear, actionable descriptions that guide LLM behavior effectively. All tools have documented input schemas with proper types and descriptions. Naming follows verb_noun pattern (find_helpful_skills, read_skill_document, list_skills). Descriptions are comprehensive and explain WHEN to use each tool. However, output schemas are not explicitly documented in the source, parameter descriptions could be more detailed about constraints and edge cases, and error handling guidance is absent. Tool naming and descriptions are production-quality; schema documentation and error recovery guidance need improvement.
Always call this tool FIRST whenever the question requires any domain-specific knowledge beyond common sense or simple recall. Use it at task start, regardless of the task and whether you are sure about the task, It performs semantic search over a curated library of proven skills and returns ranked candidates with step-by-step guidance and best practices. Do this before any searches, coding, or any other actions as this will inform you about the best approach to take.
Returns the full inventory of loaded skills (names, descriptions, sources, document counts) for exploration or debugging. For task-driven work, prefer calling 'find_helpful_skills' first to locate the most relevant option before reading documents.
Use after finding a relevant skill to retrieve specific documents (scripts, references, assets). Supports pattern matching (e.g., 'scripts/*.py') to fetch multiple files. Returns text content or URLs and never executes code. Prefer pulling only the files you need to complete the current step.
Output schemas not documented. Source code shows input schemas clearly but does not define return types or fields. LLMs cannot plan downstream operations without knowing what fields to expect from tool responses.
No error handling guidance. Tool descriptions do not indicate what errors can occur, how to recover, or what the agent should do if a skill is not found or a document does not exist. Agents cannot self-correct.
Parameter constraints incomplete. The 'top_k' parameter declares min/max but 'task_description' lacks length limits. The 'document_path' parameter uses examples ('scripts/*.py') but no explicit pattern constraint or length limit. Per-parameter constraints should be machine-readable (regex, minLength/maxLength in schema).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 73 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | 1.0.0+ | v1 |
Pagination not addressed. 'find_helpful_skills' returns 'ranked candidates' but no pagination mechanism is documented. If the skill library grows, returning all results could exhaust context. No limit, offset, or cursor guidance.
Field naming consistency unclear. Tool descriptions reference 'skill_name', 'documents', 'scripts', 'references', 'assets' but response field structure is not documented. Downstream tool calls (e.g., read_skill_document) depend on exact field names from find_helpful_skills, mismatches force agent discovery detours.