Loading ToolBench
MCP aggregator server — connects multiple MCP servers and exposes them as one, with context-aware tool filtering. Use standalone or as an OpenClaw plugin.
The server exposes exactly one tool: find_tools. The tool has a name and a basic description, but critical quality issues severely limit its usefulness. The input schema is present but minimal, it defines a single 'need' parameter of type string with no constraints, enums, validation rules, or format guidance. The description is generic and does not explain WHEN to use this tool vs alternatives, what structure the response takes, or how results are ranked 'by relevance' (no metric defined). The tool's primary role is as a discovery/aggregation mechanism, not a direct capability, this is a meta-tool that returns references to other tools rather than executing domain logic. The implementation shows sophisticated context analysis and schema compression (src/core/context-analyzer.ts, schema-compressor.ts), but none of this complexity is surfaced in the tool's contract, the LLM has no visibility into what 'context-aware filtering' means or how it affects results. No pagination support, no limit enforcement, no response structure documented. The tool lacks the typical guardrails (error recovery guidance, field naming consistency, output validation) that would make it production-grade.
Search and discover tools from external MCP servers. Call this when you need capabilities beyond your built-in tools. Examples: creating GitHub issues, searching Notion, managing databases, file operations. Returns a list of matching tools ranked by relevance.
Input schema is minimal and lacks constraints. The 'need' parameter accepts any string with no enum, pattern, length limits, or validation rules. LLMs may pass empty, nonsensical, or overly complex queries without feedback.
Tool description does not specify output structure or response format. Users/LLMs cannot know what fields to expect in results, no mention of tool metadata, relevance scores, server names, parameter schemas, or pagination. This makes downstream composition unpredictable.
No error handling guidance. If a search returns no results, if a remote MCP server is unavailable, or if 'context-aware filtering' fails, the LLM has no instructions on what to do next. Should it retry with a simpler query? Call a different tool? Give up?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 37 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 10 | - | v1 |
Description claims results are 'ranked by relevance' but provides no explanation of the ranking algorithm or how to interpret relevance in the response. What does relevance mean? How is it computed? Is the first result always the best match?
Parameter 'need' lacks a description field per JSON Schema. While there is a 'description' key in the input schema object at the top level, individual property descriptions appear absent or insufficient. This violates the baseline that 100% of A+ tool params must have descriptions.
No pagination or result limits documented. If a 'need' query matches 500 tools across multiple servers, does the tool return all of them, truncate at some limit, or paginate? Returning unbounded results risks blowing the context window.