Single monolithic 'azure' tool with a generic, catch-all design. While the description is lengthy (500+ chars) and the schema is present with typed parameters, the tool violates core composition patterns. It attempts to handle 100+ Azure operations through a single routing interface ('learn', 'tool', 'command', 'parameters'), forcing the LLM to discover and reason about sub-tools at runtime. No per-operation error handling, no idempotency hints, no output schema documentation. The 'intent' parameter is vague and duplicates 'tool'+'command'. No pagination, no result limits, no chaining IDs documented. This design pattern (single god-tool) is explicitly discouraged in production tooling.

• Split 'azure' into 20-30 namespace-grouped tools (e.g., 'azure_acr_*', 'azure_aks_*', 'azure_keyvault_*') matching the VSCode config enum. Each tool should have a single, clear responsibility (e.g., 'azure_acr_list_repositories', 'azure_aks_create_cluster'). This matches the 'namespace' server mode already documented in package.json.
• Document output schema for each operation. Specify what fields are returned, which are IDs for chaining (subscription_id, resource_group_name, resource_id), and what pagination/limits apply. Include example responses in tool descriptions.
• Add toolAnnotations: mark write operations with 'destructiveHint: true' and read-only operations with 'readOnlyHint: true'. This signals to the LLM which calls are safe to retry.
• Implement error classification in responses: return structured errors with 'category' (retryable|user_fixable|fatal), 'message' (actionable guidance), and 'suggestion' (next step or alternative tool). E.g., 'User not found. Try azure_search_users() with a partial name.'
• Add pagination support: document page/offset and limit parameters, return total_count or next_cursor, and cap results at 20-50 items per call. State limits in tool descriptions.