A resilient MCP server supervisor that manages child MCP servers with automatic restart, health monitoring, metrics collection, and tool injection capabilities.
Hydra provides 5 tools with explicit schemas and descriptions, but quality is uneven. All tools have descriptions (10-100 chars) and input schemas with type definitions. However, descriptions are minimal (avg 65 chars vs baseline 194), lack context on WHEN to use tools, and omit recovery guidance. Parameters lack descriptions in 3/5 tools (hydra_status, hydra_metrics have empty properties). No output schemas documented. Error handling is absent, no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Tool naming follows hydra_ convention but lacks verb clarity (hydra_restart vs restart_server). No tool annotations (readOnlyHint, destructiveHint) despite clear risk profiles. Composition is reasonable, each tool has one responsibility, but no chaining IDs documented.
Force restart even if in FAILED state.
Retrieve recent child stderr logs.
Get comprehensive Hydra proxy metrics including health score, request stats, and latency percentiles.
Manually restart the supervised MCP server.
Get current Hydra supervisor status.
No output schemas documented. LLMs cannot plan downstream calls or extract fields without knowing response structure.
Parameters lack descriptions in 3/5 tools. hydra_status and hydra_metrics have empty properties; hydra_restart reason param has no description. LLMs cannot infer parameter meaning from names alone.
Descriptions are minimal (avg 65 chars vs baseline 194) and lack context. No WHEN-to-use guidance, no prerequisites, no recovery hints. E.g., 'Manually restart the supervised MCP server' omits: when to call this vs force_restart, what happens during restart, expected duration.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
No error handling guidance. Tools do not indicate retryability, user-fixable vs fatal errors, or recovery paths. E.g., if restart fails, should the agent retry? Call status first? Ask the user?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). hydra_restart and hydra_force_restart are destructive but unmarked; hydra_status and hydra_logs are read-only but unmarked. Agents cannot reason about safety without explicit hints.