Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server has decent tool naming and consistent schemas, but falls short in several critical areas. All 9 tools have input schemas with proper JSON Schema structure and type definitions. Tool names follow verb_noun convention (add_process, start_process, etc.), which is good. However, descriptions are brief and often lack depth about when to use each tool and what happens on success/failure. Parameter descriptions are minimal, many lack guidance on expected formats or constraints. Output schemas are entirely undocumented. Error handling and recovery guidance are absent. The server implements basic MCP mechanics but lacks the depth and LLM-optimization expected of production-grade tools.
Tools (9)
add_processwritesource verified74/100
Add a new process to Supervisord (requires config reload)
No output schemas documented. Tools return results but LLMs cannot predict structure. No guidance on what fields to expect, forcing runtime discovery and increasing hallucination risk.
Missing error handling and recovery guidance. Tools declare no error cases, expected failure modes, or how agents should respond to failures. No categorization of errors as retryable vs. user-fixable.
Descriptions are too brief and generic. Most are single short sentences (e.g., 'Start a process', 'Stop a process') that lack context on WHEN to use the tool, what prerequisites exist, and what happens on success. LLM-optimized descriptions should be 50-200 chars and answer: what, when, and why.
Recommendations
Add explicit output schemas for every tool. Document at minimum: the response type (object/array), all top-level fields, their types, and meanings. Example: 'Returns {status: string (running|stopped|failed), uptime_seconds: integer, pid: integer}'. This enables LLMs to plan downstream calls and extract the right data.
Expand tool descriptions to 50-200 characters and answer three questions: (1) What does it do? (2) When should you call it instead of a similar tool? (3) What happens as a result? Example for start_process: 'Start a stopped or failed process by name. Use after a process exits unexpectedly or you want to activate it. Returns the new process status or an error if the process name does not exist.'
Add enum constraints to autorestart parameter. Change description to: 'Restart policy. Set to one of: true (always restart), false (never restart), unexpected (restart only on abnormal exit). Defaults to unexpected.' This eliminates guessing.
Document output for list_processes: 'Returns a list of process objects with fields {name: string, state: string (running|stopped|failed), uptime_seconds: integer, restart_count: integer}. For servers with >50 processes, consider pagination: add optional limit and offset parameters.'
Add min/max constraints to get_logs lines parameter. Example: 'Number of log lines to retrieve (1-10000, default 100). Requesting >10000 lines may timeout.'
Document dependencies and sequencing in add_process description: 'Add a new process configuration to Supervisord. After calling this tool, you MUST call reload_config to activate the new process. Returns the process name on success or error if configuration is invalid.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Parameter descriptions lack constraint details. For example, 'autorestart' accepts string values ('true', 'false', 'unexpected') but the description only says 'Restart policy (true, false, unexpected)', not clear if LLM should pass boolean or string. 'lines' parameter in get_logs has no min/max bounds.
add_process description says 'requires config reload' but does not explain what that means or whether the caller must invoke reload_config separately. Dependency and sequencing guidance is missing.
No tool annotations for destructive operations. start_process, stop_process, restart_process, and reload_config are state-modifying but lack destructiveHint annotation. add_process and reload_config should carry warnings.
list_processes returns all processes with no pagination or limit controls. Large process lists will blow context window. No documentation of result structure, field count, or when to expect truncation.
list_processes
Add tool annotations for destructive operations. Mark start_process, stop_process, restart_process with a destructiveHint indicator. Mark reload_config with a destructiveHint (can disrupt running processes on config errors).
Add error handling guidance. For example, start_process description should include: 'Error if the process name does not exist. Error if the process is already running. On failure, call get_process_status to check current state.'
Implement confirmation request pattern for reload_config: 'Before reloading, validate the configuration syntax to catch errors early. Consider offering a dry-run mode to preview changes without applying them.'
Return chaining IDs in responses. If list_processes returns process names, ensure get_process_status accepts those exact names so agents can chain calls without lookup overhead.