Azure Omni-Tool MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging level | info |
| MAX_RETRIES | No | Retry attempts | 3 |
| ENABLE_CACHE | No | Enable query caching | true |
| OPERATOR_NAME | No | Operator name | |
| OPERATOR_EMAIL | No | Email for audit trail | |
| RETRY_DELAY_MS | No | Base retry delay | 1000 |
| AZURE_TENANT_ID | No | Azure tenant for scoping | |
| CACHE_TTL_SECONDS | No | Cache duration | 300 |
| COMMAND_TIMEOUT_MS | No | CLI timeout | 120000 |
| AZURE_SUBSCRIPTION_ID | No | Default subscription | |
| CACHE_CLEANUP_INTERVAL_MS | No | Cache cleanup interval | 60000 |
| AZURE_MCP_INCLUDE_PRODUCTION_CREDENTIALS | No | Enable Managed Identity | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| manage_azure_resourcesA | Primary tool for all Azure operations via CLI. FLOW: 1) Call with execute_now=false for plan 2) Review risk 3) Call with execute_now=true to execute SAFETY: Commands validated for injection. Destructive ops flagged HIGH risk. AUDIT: All ops logged with operator email and correlation ID. |
| get_azure_contextA | Retrieves Azure environment context. TYPES: subscriptions, resource_groups, resources, custom (KQL) CACHING: 5min default, bypass_cache=true for fresh data EXAMPLES:
|
| azure_serviceC | Interact with specific Azure services. SERVICES: storage, cosmos, search, kusto, monitor, appconfig, keyvault, postgres STORAGE actions: list, listContainers, listBlobs, getContainer, listTables, queryTable COSMOS actions: list, listDatabases, listContainers, query, getContainer SEARCH actions: list, listIndexes, getIndex, query, getService KUSTO actions: list, listDatabases, listTables, getSchema, sample, query MONITOR actions: list, getWorkspace, listTables, query, listMetrics, getMetrics APPCONFIG actions: list, getStore, listKeyValues, getKeyValue, setKeyValue, lock, unlock KEYVAULT actions: list, getVault, listKeys, getKey, createKey, listSecrets, getSecret, listCertificates POSTGRES actions: list, getServer, listDatabases, listParameters, getParameter, listTables, getTableSchema, query Pass required params for each action (e.g., accountName, resourceGroup, query). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools have overlapping and unclear boundaries. 'azure_service' appears to handle data querying across multiple Azure services, while 'manage_azure_resources' seems to cover CLI-based operations, but their scopes are not clearly differentiated. 'get_azure_context' is distinct for context retrieval, but the other two tools could easily be confused for similar purposes, leading to agent misselection.
Naming is inconsistent across the tool set. 'azure_service' uses snake_case, 'get_azure_context' follows a verb_noun pattern with snake_case, and 'manage_azure_resources' uses a verb_noun pattern but with a different verb style ('manage' vs. 'get'). This mixed convention reduces predictability and readability for agents.
With 3 tools, the count is borderline for a server named 'Azure Omni-Tool MCP Server', which suggests broad Azure coverage. This feels thin given the extensive Azure domain, as many operations might be crammed into a few tools, but it's not critically low. A more appropriate scope might include more specialized tools for better granularity.
The tool surface has significant gaps for an Azure-focused server. While 'azure_service' covers querying across services and 'manage_azure_resources' handles CLI operations, there are missing core operations like creating, updating, or deleting resources directly. The server lacks clear CRUD lifecycle coverage, which could cause agent failures in common Azure workflows.