18 tools with consistent naming (verb_noun pattern) and descriptions present. All tools have input schemas with Zod validation. However, descriptions are brief (avg ~80 chars, below 194-char baseline), lack WHEN/WHY context, and omit error recovery guidance. Parameter descriptions are minimal. Output schemas are undocumented, LLMs cannot predict response structure. No tool annotations (readOnlyHint/destructiveHint). Error handling returns plain text without actionable recovery steps. Composition is sound (single responsibility per tool), but descriptions need expansion to meet LLM-optimization standards.

• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Call rule_list first to see all rules, then rule_get to inspect a specific rule by ID'). Example: 'Get a ModSecurity rule by ID. Returns rule text, enabled status, and metadata. Call rule_list() first to discover available rule IDs.'
• Document output schemas for all tools. E.g., rule_get returns {id: number, enabled: boolean, variable: string, operator: string, actions: string}. Use structured response objects instead of plain text.
• Add tool annotations via MCP SDK. Mark rule_remove, nginx_stop as destructiveHint=true; rule_list, rule_get, nginx_status as readOnlyHint=true; rule_add, rule_import as idempotentHint=false (since they modify state).
• Enhance error messages with recovery steps. E.g., 'Rule id:123 not found. Call rule_list() to see available rules (IDs range from 1000000+).' or 'Nginx reload failed: syntax error in config. Call nginx_test_config() to validate.'
• Expand parameter descriptions. E.g., auto_reload: 'If true, automatically reload nginx after the change. If false, changes are written but not active until nginx_reload() is called separately. Default: true.'