Loading ToolBench
A Model Context Protocol (MCP) search server that searches for and discovers existing MCP servers from the official GitHub repository
Single tool with a descriptive name and basic schema. Tool 'search_mcp_servers' starts with a verb (search_) which is correct per pattern:tool. Description is 168 characters, within the 10-1024 baseline range. Input schema includes two parameters with descriptions and type information. However, several significant quality gaps limit the overall score: (1) Output schema is completely undocumented, the tool returns search results but the response structure is not defined anywhere in the visible code; (2) Parameter descriptions lack constraint details (e.g., what categories are actually valid? what constitutes a valid query?); (3) No pagination documented despite tool likely returning lists of servers; (4) No error handling guidance, what happens if GitHub is unreachable? What should the agent do?; (5) Tool lacks idempotency notes despite being read-only. Per HARD SCORING RULES, since output schema is not documented in source, schema score cannot exceed 50 for this tool.
Search for existing MCP servers from the official GitHub repository. Args: query: Search query to find relevant MCP servers (searches name, description, and category) category: Filter by category (all, development, database, productivity, automation, cloud, security, etc.) Returns: Search results with matching MCP servers and their details
Output schema completely undocumented, tool returns 'Search results with matching MCP servers and their details' but the actual response structure (list format, field names, nested objects) is not specified. LLMs cannot plan downstream operations or extract specific fields without knowing what the response looks like.
Parameter 'category' accepts a string with description listing examples ('all, development, database, productivity, automation, cloud, security, etc.') but does not declare these as an enum. Free-form strings invite hallucinated category values. LLMs cannot distinguish between examples and exhaustive options.
No pagination support documented. Tool description implies it may return multiple servers but provides no limit, offset, or cursor parameters. Without pagination, large result sets could blow context window, violating pattern:paginated-result baseline expectations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
No error handling or recovery guidance. Tool fetches from GitHub with a 30-second timeout but no documented behavior when GitHub is unreachable, rate-limited, or slow. LLM has no guidance on retry strategy or fallback actions per pattern:recovery-guide.
Parameter 'query' description lacks constraint details. No minimum/maximum length specified, no guidance on whether partial matches are supported, no examples of valid vs invalid queries. Baseline for param annotations is 72 chars; this is ~80 chars but vague on boundaries.
Tool description states it is read-only but does not explicitly document this with an idempotent hint or annotation. Without documented idempotency, LLMs may be overly cautious about retrying on transient failures.