Two tools with significant definition gaps. aegis_status has empty input schema ({}), which is acceptable for a read-only status check, but lacks depth in description. aegis_ssh_<alias> has a well-structured schema with proper parameter descriptions and type definitions, but the tool name pattern is problematic: it uses a dynamic suffix (<alias>) rather than a stable verb_noun pattern, making it difficult for LLMs to discover and reason about tool selection. Descriptions are present but generic. No output schemas documented. No error handling guidance. No tool annotations (readOnlyHint/destructiveHint). Overall definition quality is below median for production tools.

• Replace dynamic tool naming with a single stable tool (e.g., 'execute_ssh_command') that accepts an 'alias' or 'host' parameter. This enables LLM discovery and reasoning.
• Document output schemas for both tools. Example: aegis_status returns {registered_hosts: number, active_profiles: string[], uptime_seconds: number}; aegis_ssh_<alias> returns {exit_code: number, stdout: string, stderr: string}.
• Add tool annotations: aegis_status with readOnlyHint=true; aegis_ssh_<alias> with destructiveHint=true (since it executes commands on remote systems).
• Enhance error descriptions with recovery guidance. E.g., 'If command validation fails, check that the executable is in the rule profile's allowlist. Call aegis_status to see active profiles.'
• Expand aegis_status description to explain use case: 'Call this before executing commands to verify the gateway is healthy and the target host is registered.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry