Three tools with clear security-focused design and proper Zod schemas. Naming is verb-based and descriptive (discover_, execute_, capability_). Descriptions are present and explain the security model well (10 - 20 words each). However, parameter descriptions are minimal or absent, 'capability' and 'action' in execute_capability lack detail on format/constraints. Input schema for discover_capabilities is empty ({}), violating the pattern:tool requirement. Output schemas are not documented, LLMs cannot predict response structure. Error handling returns JSON but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles (READ_ONLY vs WRITE).

• Add explicit input schema to discover_capabilities: change {} to {type: 'object', properties: {}, required: []} or document why no parameters are needed.
• Enhance parameter descriptions: 'capability' should read 'Capability identifier (string, 1-255 chars, alphanumeric + underscore)' and 'action' should specify valid action names or reference discover_capabilities output.
• Document output schemas in tool descriptions. E.g., 'Returns {capabilities: [{id, service, actions, description?}]}' for discover_capabilities and '{ok: boolean, status: number, result?: unknown, error?: string}' for execute_capability.
• Add tool annotations via server.tool() or tool metadata: execute_capability should include destructiveHint: true; discover_capabilities and capability_health should include readOnlyHint: true.
• Improve error messages with recovery hints: 'Capability "foo" not found. Call discover_capabilities to see available capabilities.' or 'Action "bar" not supported. Available actions: [list from discovery]'.