Loading ToolBench
The Mixpeek MCP server provides only one explicitly registered tool: 'mixpeek.health'. This health check tool has a trivial definition with an empty input schema and a minimal description (18 characters). The server is designed to dynamically fetch and expose OpenAPI endpoints at runtime from the Mixpeek API, but NO explicit tool definitions appear in the source code for these dynamic tools. The code shows parsing logic (extract_endpoints, ToolArg, Endpoint classes) but no registration of dynamically-fetched tools with proper MCP schemas. Since tool definitions are inferred rather than directly visible with explicit schema and description declarations in the MCP registration layer, per the hard scoring rules, dynamic tools are capped at 50. The single explicit 'health' tool scores poorly on all dimensions: naming is acceptable but generic ('health' as a verb-noun is weak; 'check_server_health' would be stronger), description is too brief (18 chars, well below the 50-200 char LLM-optimized baseline), and schema is empty (critical failure). No parameter descriptions exist. Output schema is undocumented. No error handling guidance is present.
Basic health check for the MCP server
Health tool description is only 18 characters ('Basic health check for the MCP server'), below the 50-character LLM-optimized minimum. At this length, LLMs cannot determine when to invoke the tool or what specific checks it performs.
Health tool input schema is empty ({}). Per hard scoring rules, empty input schemas score 0 for schema completeness. Even a trivial health check should document what inputs it accepts (none, one, or query parameters for customization).
Output schema is not documented for the health tool. LLMs cannot plan downstream tool calls or extract the response structure without knowing what fields the health check returns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 29 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 11 | - | v1 |
Dynamic OpenAPI tools are parsed and generated at runtime but NOT explicitly registered with the MCP server with full schemas and descriptions visible in the source code. Per hard scoring rules, tool definitions that are inferred rather than directly visible are capped at 50 overall. The code extracts operation_id, method, path, and parameter metadata into Endpoint and ToolArg objects, but does not show explicit tool registration calls (e.g., server.tool(...) decorators or registration method calls) with proper MCP input/output schemas for these dynamically-generated tools.
No error handling guidance. Tools return raw HTTP errors without recovery context. Per pattern:recovery-guide, errors must tell the LLM what to do next (e.g., 'Rate limit exceeded; retry after 10 seconds' or 'API key invalid; check MIXPEEK_API_KEY environment variable').
No parameter descriptions for dynamically-extracted query/path arguments. The code identifies query_args and path_args from OpenAPI, but does not ensure each parameter in the final MCP schema includes a description. LLMs cannot reason about ambiguous parameters without descriptions (e.g., does 'status' mean HTTP status, resource status, or active flag?).
Tool naming for dynamic endpoints is derived from OpenAPI operationId, which may not follow verb_noun conventions (e.g., 'get_user' vs 'GetUserById'). No name normalization or validation is visible in the code.
No pagination support declared in the source. If dynamic endpoints return lists, the MCP server should expose limit and offset/cursor parameters and document them. The code does not show pagination wrapping for list results.