Single tool with basic schema and description. Tool name 'generate_system_diagram' follows verb_noun convention (+). Description is 67 chars, adequate but generic. Input schema present with proper types and enum constraint on diagramType. However, no output schema documented, LLMs cannot predict response structure. Parameter 'diagramType' has description; 'description' param description is minimal (47 chars). No error handling guidance. Tool does not declare idempotency or side effects. Missing per-tool annotations (readOnlyHint, destructiveHint). No pagination, no rate-limit guidance. Implementation returns unstructured text responses ('System diagram generated successfully...') rather than typed objects. Baseline: 194 chars avg description, 72 chars avg param annotation, this tool underperforms on both.

• Add explicit output schema to tool definition: { type: 'object', properties: { link: { type: 'string', description: 'URL to view/edit diagram in draw.io' }, xml: { type: 'string', description: 'Raw draw.io XML' } }, required: ['link'] }
• Expand tool description to 100-150 chars: 'Generate a system architecture diagram from a text description. Returns a draw.io URL for viewing and editing. Supports simple, detailed, and cloud architecture layouts. Useful for visualizing system components and relationships.'
• Add minLength/maxLength constraints to 'description' parameter: minLength: 10, maxLength: 2000, and update description: 'Text description of system components and their relationships (10-2000 chars). E.g., "User sends requests to web app, which queries database"'
• Add tool annotations in ListToolsRequestSchema response: { name: 'generate_system_diagram', ..., inputSchema: {...}, annotations: { readOnlyHint: true } }
• Enhance error responses with recovery guidance: return { isError: true, content: [{ type: 'text', text: 'Error: description parameter required (10-2000 chars). Provide a text description of system components.' }] }