Server defines 5 tools with basic schemas and descriptions, but exhibits significant quality gaps. Tool names lack action verbs (inspect_call, inspect_output are acceptable but generic). Descriptions are present but brief (50-100 chars), below the 194-char baseline for production tools. Input schemas exist but lack parameter-level descriptions, the 'arguments' parameter in inspect_call is typed as 'object' with no field-level schema. Output schemas are completely undocumented. Error handling is absent from tool definitions. No evidence of pagination, result limits, or recovery guidance. The health/ready/metrics tools are operational probes, not domain tools, and dilute the security-focused toolset.

• Expand inspect_call and inspect_output descriptions to 150-250 chars. Include: what the five-layer defense checks, what a 'blocked' verdict means, and when to call each tool (before or after execution).
• Replace bare 'arguments: object' with a structured schema listing expected fields (name, server_id, arguments) with types and descriptions for each.
• Document output schemas: inspect_call should return {allowed: bool, threat_type?: string, confidence?: float, reason: string}. inspect_output should return {safe: bool, exfiltration_risk?: string}.
• Add error handling guidance: 'If a call is blocked, the LLM should log the threat and ask the user for confirmation before retrying with modified arguments.'
• Remove health, ready, metrics from the tool list. Expose them as HTTP endpoints (/v1/health, /v1/ready, /v1/metrics) instead, keeping the tool namespace focused on security inspection.

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

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