All 5 tools have trivial descriptions (10-40 chars) and empty input schemas ({}). No parameter descriptions, no output schemas documented, no error handling guidance. Tools are read-only but lack idempotent/readOnly annotations. Naming is verb-based (get_*) but descriptions provide zero context for LLM selection. This server fails the critical baseline: 100% of A+ tools have documented return types and param descriptions; 94% have docstrings >34 chars. These tools have neither.

• Expand each tool description to 100 - 200 chars. Example: 'get_risks' → 'Retrieve all risks from ISOPlanner. Returns risk ID, name, description, status, and associated tags. Use this to discover available risks before filtering or analyzing controls.'
• Add explicit input schemas with type definitions. Even if tools accept no parameters, declare inputSchema: {type: 'object', properties: {}, required: []} to signal intentional emptiness.
• Document output schemas for each tool. Example for get_risks: 'Returns array of {riskId: integer, name: string, description: string, status: string, tags: array}'. Include this in tool metadata or a separate schema registry.
• Add tool annotations: set readOnlyHint: true and idempotentHint: true on all 5 tools to signal safety properties to LLMs.
• Implement error handling with recovery guidance. Wrap API calls in try-catch; return structured errors like {error: 'API_TIMEOUT', message: 'ISOPlanner API did not respond. Retry in 30s or check service status.', retryable: true}.