Loading ToolBench
MCP server that provides access to the MCP Registry API, allowing querying and listing of registered MCP servers.
This MCP server exhibits significant quality gaps across naming, descriptions, parameters, and schemas. All four tools are READ_ONLY and relatively simple, but lack proper parameter descriptions, output schema documentation, and error handling guidance. Tool names are adequate but generic. Descriptions are minimal (10-70 chars, below the 194 char baseline). Most critically, three of four tools accept empty input schemas with no documented constraints or expectations. The server is functional but would fail code review against production baselines.
Get details for a specific MCP registry server.
Checks the health of the MCP registry server.
Lists MCP registry server entries with pagination support.
Simple ping endpoint that returns environment configuration information.
CRITICAL: Three tools have completely empty input schemas ({}) with no description of what they accept or expect. This violates pattern:constrained-input and pattern:tool-description.
Tool descriptions are extremely brief (10-70 characters, well below 194 char baseline). 'Checks the health of the MCP registry server' (56 chars) lacks WHEN to use this tool, WHAT structure it returns, and WHY it matters. 'Simple ping endpoint that returns environment configuration information' (70 chars) mentions config but doesn't explain what config or how to use it.
No output schemas documented anywhere. LLMs cannot know what fields health_check() returns (is it {status: string}? {status, uptime, timestamp}? free-form text?). list_registry_server_entries returns format_servers() output (formatted string of name+id), but this is never documented as the response structure. Pattern:response-shaper requires LLMs know what fields to expect for downstream chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
get_server_details accepts a 'server_id' parameter with type string and basic description, but lacks constraints. Is it case-sensitive? What format? The description says 'unique identifier' but provides no pattern, length, or valid examples.
No pagination support or result limits documented. list_registry_server_entries() calls /v0/servers and format_servers() loops over response['servers'], but no indication of limit, offset, page, or total count.
No error handling or recovery guidance. If MCP_REGISTRY_URL is missing, the server fails at startup with KeyError. If an API call fails (404, 500, auth error), response.raise_for_status() throws an unhandled exception. LLMs receive no guidance on what went wrong or how to retry. Per pattern:recovery-guide, errors must say 'what to do next.'
Tool naming is generic and ambiguous. 'ping' is a deprecated MCP protocol feature (removed as of 2026-07-28 spec). The tool description says it 'returns environment configuration information,' but the name 'ping' suggests a simple liveness check. This mismatch confuses LLMs about the tool's purpose. Recommend rename to 'get_registry_config' or 'check_environment'.
list_registry_server_entries and get_server_details both return formatted plain text (via format_servers), not structured JSON. format_servers() joins lines like 'MCP Server Name: X\nMCP Server ID: Y'. LLMs must parse unstructured text, which wastes tokens and is error-prone. Pattern:response-shaper requires returning structured objects with typed fields.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). All four tools are READ_ONLY, but this is documented only in the metadata provided, not in the tool schema itself. Per spec alignment (2026-07-28), tool annotations should be present in the schema for LLM reasoning and safety.