Server exposes 13 Azure tools with complete input schemas and descriptions. Naming follows verb_noun convention (cosmos_query, pg_execute, arm_get). Descriptions are present and actionable (avg ~100 chars), explaining WHAT each tool does and WHEN to use it. However, parameter descriptions lack constraint details (ranges, enums, formats), and output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. Security is strong (credentials injected server-side, allowed-host validation for pg_execute), but composition could be tighter (arm_get/post/put/delete are generic HTTP wrappers rather than domain-specific operations).

• Add enum constraints to parameter descriptions. E.g., for pg_execute, document that 'statement' must start with one of: INSERT, UPDATE, DELETE, MERGE (case-insensitive). Use JSON Schema enum field in addition to description text.
• Document output schemas for all tools. E.g., 'cosmos_query returns {items: [{id, ...fields}], count: int, continuation_token?: string}'. This enables LLMs to chain tools and extract required fields.
• Wrap generic ARM HTTP tools into domain-specific operations. Create dedicated tools like create_resource_group(name, location), deploy_template(resource_group, template_uri), list_resources(resource_group, type) instead of exposing raw ARM paths.
• Add actionable error messages. E.g., if pg_execute receives a host not in PG_EXECUTE_ALLOWED_HOSTS, return 'Host "unknown.postgres.database.azure.com" not allowed. Allowed hosts: tank-operator-db.postgres.database.azure.com, glimmung-pg.postgres.database.azure.com'.
• Implement confirmation for destructive operations. Add a 'confirm' parameter (default false) to cosmos_delete, arm_delete, keyvault_delete_secret. When false, return a summary of what would be deleted; when true, execute. This prevents accidental data loss.