The server defines 12 tools, all read-only Azure resource discovery operations. Tool naming follows verb_noun conventions (list_*, get_*) which is correct. However, descriptions are generic and lack depth. Input schemas are present with basic type definitions, but parameter descriptions are minimal. No output schemas are documented. Error handling is not evident. The server appears to be a straightforward wrapper around Azure SDKs with limited agent optimization.

• Document output schemas for every tool. Example: list_resource_groups should return {type: 'object', properties: {resource_groups: {type: 'array', items: {type: 'object', properties: {id: {type: 'string'}, name: {type: 'string'}, location: {type: 'string'}, state: {type: 'string'}}}}, total_count: {type: 'integer'}}}
• Expand tool descriptions to 100-200 characters with WHEN/WHY context. Example: 'List all Azure resource groups in your subscription. Use this to discover which resource group contains the cluster or resource you want to query. Returns group names, IDs, locations, and provisioning state.'
• Add pagination parameters (limit, offset) to all list_* tools and document result limits. E.g., default limit=20, max=100. Return total_count and next_offset for paging.
• Add detailed parameter constraints to descriptions. E.g., resource_group: 'Name of the Azure resource group (1-90 alphanumeric chars, hyphens allowed; case-insensitive)'
• Implement error responses that guide recovery. E.g., if resource_group is not found, return: 'Resource group "xyz" not found in subscription. Available groups: [list]. Did you mean one of these?'
• Add readOnlyHint: true to all tool definitions to signal to agents that these are safe to retry without side effects.
• For list tools, document what fields are returned and their meaning. Add a 'Returns' section to each tool description or a separate response schema.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry