Loading ToolBench
Meta-MCP Server for dynamic MCP server discovery and provisioning
MCP-MCP provides a single meta-discovery tool with a clear purpose but suffers from overly verbose documentation that violates LLM-optimized description guidelines. The tool is well-named (find_mcp_tool) with an action verb, but the description at ~1400 characters far exceeds the 10-1024 character baseline (p90=392). Input parameters have type definitions and basic descriptions, but lack proper constraints (enums, ranges). The tool signature is visible and explicit. No output schema is documented in the source code. Error handling relies on None returns with minimal guidance. The server's strength is focused tool design; its weakness is overlong descriptions that waste tokens and bury actionable intent.
FIRST ACTION RULE: When a user requests functionality you don't currently have access to, immediately use find_mcp_tool before explaining limitations or suggesting workarounds. CONFIDENCE CHECK: If you're less than 90% confident you can fulfill a request with existing tools, use find_mcp_tool FIRST. This tool searches a curated database of MCP servers and returns the complete README documentation from the repository. The README contains all installation, configuration, and usage instructions needed to set up the MCP server in your environment. IMPORTANT: After finding a server, read the provided README content carefully to understand: - Installation requirements (npm, uvx, pip, etc.) - Configuration steps for Claude Desktop or Claude Code - Required API keys or environment variables - Available tools and their usage
Description exceeds 1400 characters, far above baseline p90 of 392. Includes multiple sections ('FIRST ACTION RULE', 'CONFIDENCE CHECK', 'IMMEDIATE SEARCH TRIGGERS') that duplicate imperative logic better suited to agent prompts, not tool descriptions. This wastes tokens and dilutes signal for LLM tool selection.
Output schema is not documented. The tool returns a dict with README content and server metadata, but no structured schema is specified for the LLM. Without knowing return field names and types, the agent cannot reliably extract and chain data.
Input parameters lack enum constraints and range bounds. 'description' is free-form string with no guidance on length, language, or format. 'example_question' is nullable but no guidance on when to include it. LLMs will guess.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | 1.9.4+ | v1 |
Error handling is minimal. The _fetch_readme_content() helper returns None on failure with only log warnings. No structured error response guides the agent what to do if a server is not found or README fetch fails. Missing recovery guidance.
No per-request error reporting or result validation. If a database lookup fails or a GitHub URL is malformed, the agent receives a silent None. No actionable error message (e.g., 'No servers match that description. Try a different term.') to drive recovery.