MCP server providing search and catalog access for TensorBlock's awesome-mcp-servers repository
TensorBlock MCP Registry exposes three tools with adequate but inconsistent definition quality. All tools have descriptions and basic schemas, but several critical gaps emerge: (1) parameter descriptions are terse or missing context about usage patterns; (2) output schemas are not formally documented in the tool definitions themselves, forcing LLMs to infer structure; (3) error handling provides HTTP status codes but no actionable recovery guidance; (4) tool compositions assume prior knowledge of the server ecosystem. The server is functionally usable but falls short of production-grade quality that would enable confident agent planning.
Generate an MCP client install config for a catalog entry.
Get a TensorBlock MCP catalog entry by server id.
Search TensorBlock MCP catalog entries.
Parameter descriptions lack actionable guidance. 'Search query (minimum 1 character)' does not explain WHEN to use this tool vs discovery tools, what constitutes a good query, or what semantic fields are searched (name, description, category, tags?). LLMs cannot disambiguate.
No output schemas documented in tool definitions. The code returns CatalogEntry objects and generated configs, but LLMs see no formal schema describing returned fields (name, description, transport, auth, category, installConfig structure, etc.). This forces inference and breaks chain-ability.
Error responses provide HTTP status codes (404, 500) but no recovery guidance. A 404 for 'Server not found: invalid-id' gives the agent no path forward. Should return: 'Server not found. Try search_servers() with a partial name, or list categories first to discover available servers.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
Tool composition assumes prior knowledge. get_server_profile accepts a serverId parameter, but the tool description does not state 'First call search_servers() to discover server IDs, or call get_server_profile with a known ID.' This makes the tool less discoverable.
get_install_config 'client' enum is incomplete in LLM context. The enum lists ['claude', 'cursor', 'codex', 'vscode'], but the code also accepts aliases ('claude-desktop', 'vs-code'). The tool definition does not expose aliases, forcing agents to guess or fail if users mention 'Claude Desktop' naturally.
search_servers lacks pagination parameters and result limit documentation. The underlying search() function likely respects a limit, but the tool schema does not expose it. Returning 100 servers in one response wastes tokens and degrades LLM reasoning (baseline: cap at 20 - 50, document in description).