Loading ToolBench
Cloudflare Worker that wraps the MCPRated static catalog as MCP Streamable HTTP
8 tools with complete input schemas and descriptions. Naming is clear and action-oriented (find_, search, vet, alternatives, by_kind, top, server_detail, find_tool). Descriptions are detailed and contextual (avg ~180 chars), exceeding the 10 - 1024 char baseline. All parameters have type definitions and descriptions. However, output schemas are NOT documented, the code shows tool definitions but no return type specifications. Error handling is mentioned in code comments ('rpcError()') but not visible in tool definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Parameter constraints are well-defined (enums, min/max). No security issues detected (no secrets in params). Composition is strong: tools are single-purpose and chainable (e.g., find_server → vet → server_detail).
Find MCP servers with overlapping capabilities to a given one. Useful for fallback when a primary choice is unavailable, or for comparison.
List entries by classifier kind. server | client | framework | tool | ambiguous. The default catalog ranking shows kind=server; use this to inspect classifier output for the other kinds.
Find MCP servers tagged with a controlled capability category. Use when you can map your need to one of the 12 categories below; if you can't, use 'search' instead. Mapping examples: Postgres / MySQL / SQLite / any SQL or NoSQL DB → 'database' Local files, read/write filesystem → 'filesystem' Browser automation, scraping, HTTP fetch → 'web' Vector search, RAG, retrieval, search engines → 'search' Notion, Jira, Linear, calendar, docs → 'productivity' Slack, Discord, SMTP, Twilio → 'comms' GitHub, GitLab, Docker, Kubernetes, CI → 'devtools' AWS, GCP, Azure, Cloudflare, Vercel → 'cloud' OpenAI, Anthropic, image-gen, transcription → 'ai' Knowledge graph, notes, Obsidian → 'memory' Stripe, payments, blockchain → 'finance' FFmpeg, OCR, image/video processing → 'media' Returns up to 'limit' servers ranked by composite quality score.
Find a specific MCP tool by name or natural-language intent. Searches the flat tools-index across every cataloged server. Returns matched tools with their owning server. Use when you know what tool you need (e.g. 'browser_navigate', 'read_file', 'send_message') rather than which server.
Output schemas not documented. Tool definitions show inputSchema but no return type specification. LLMs cannot plan downstream calls or extract fields without knowing what each tool returns.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 8 tools are read-only and idempotent, but this is not declared in the schema. Clients cannot infer safety properties.
Error handling guidance not visible in tool definitions. Code mentions 'rpcError()' and 'Bug #1 fix' but error recovery patterns are not documented in descriptions. LLMs cannot know what to do on failure.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 83 | 2026-07-28+ | v2 |
Free-text search across the catalog when 'find_server' enum doesn't fit. Matches against repo name, description, and capability tags. Returns up to 'limit' servers, ranked by relevance and quality. Use this for natural-language needs like 'postgres mcp', 'browser automation', 'github operations' — the matcher will translate.
Full lint output for one MCP server: every signal pass/fail with reason, all four axes, hard flags. Use when an agent needs evidence-level detail beyond the trust verdict.
Top MCP servers by ranking. Three orderings: composite score (quality), stars (popularity), recency (last push).
Trust-focused summary of one MCP server. Returns composite score, four axis scores, license, hard flags, and a 2D verdict: quality_tier (excellent | solid | acceptable | poor) × flag_status (clean | caution | archived). Use before recommending a server for production. Legacy single-string `verdict` field is also returned for backwards compatibility.
Parameter 'limit' lacks description in 'top' tool. The 'ranking' parameter also lacks a description explaining what each enum value means (composite vs stars vs recency).
Pagination guidance missing. Tools like 'find_server' and 'search' accept 'limit' but do not document whether results are paginated, whether a cursor/offset is returned, or how to fetch the next page.