WebSocket MCP Server for AI provider fallback management with automatic failover, usage analytics, and real-time event subscriptions
This server has moderate structural issues that prevent it from reaching production readiness. While tools have names, descriptions, and visible schemas in the source code, there are significant gaps in parameter documentation, output schema clarity, and error handling guidance. The server implements 11 tools across provider management, analytics, and authentication, a reasonable scope, but the quality varies significantly. Several parameters lack descriptions entirely, output schemas are not formally documented, and error responses provide minimal guidance for LLM recovery. The implementation pattern (HTTP server with WebSocket support) is sound, but tool definitions need substantive improvement to meet production standards.
Get cost analysis
Get provider comparison analytics
Get usage analytics summary
Check authentication for a specific provider
Get authentication status for all providers
Get detailed information about a specific model
List all available models
Get the currently active provider
List all available providers with their status
Output schemas completely undocumented. None of the 11 tools explicitly declares what fields will be returned, their types, or format. LLMs cannot plan downstream tool calls or extract data reliably without knowing the response structure.
Error handling responses provide no recovery guidance. Handlers return `{ error: 'message' }` with no indication of whether the error is retryable, what the LLM should try next, or what constraint was violated. Example: 'Provider not found' gives no hint to search providers or check authentication first.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Switch to a different provider
Subscribe to real-time events
Parameter descriptions are missing or minimal across multiple tools. `model.list` has three parameters (family, provider, capability) with no descriptions at all. `analytics.summary` period description is present but 'analytics.providers' and 'analytics.costs' lack descriptions for their parameters. Parameters under 20 characters cannot score above 20.
No pagination support on list/analytics tools. `provider.list`, `model.list`, and `analytics.providers` return unbounded results with no limit, page, offset, or cursor parameters.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint per MCP 2026-07-28 spec) are absent. The schema includes 'Risk: READ_ONLY' and 'Risk: WRITE' labels in metadata, but these are not encoded as formal tool annotations in the protocol response. Current spec expects structured annotation support.
No MRTR (Multi Round-Trip Request) support visible. Destructive operations like `provider.switch` and `subscribe` could benefit from a confirmation step before execution, preventing accidental failures. Current handlers lack `input_required` result pattern.
subscribe tool has unclear contract. Description says 'Subscribe to real-time events' but the handler checks `context?.ws` and returns error if no WebSocket. This WebSocket requirement is not reflected in the parameter schema or description. LLMs cannot infer that this tool requires a persistent connection.
Inconsistent parameter naming and missing field name suffixes. Parameters named 'providerId', 'modelId' use camelCase IDs, but descriptions do not clarify they are system identifiers vs human-friendly names.