Which integrations are available for this server?

Provides tools for managing Azure PostgreSQL Flexible Server instances, including listing servers, databases, and parameters, querying table schemas, and executing SQL queries.

How do I use Azure Omni-Tool MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Azure Omni-Tool MCP Server list all storage containers in my production resource group" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Azure Omni-Tool MCP Server

by vedantparmar12

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Azure Omni-Tool MCP Server

A Model Context Protocol (MCP) server in TypeScript that acts as an intelligent bridge between natural language requests and Azure CLI execution.

Features

✅ Plan/Execute Flow - Review commands before execution
✅ Safety Guardrails - Shell injection detection, destructive command warnings
✅ Audit Trail - Operator email tagging for traceability
✅ Retry Logic - Exponential backoff for transient failures
✅ Caching - LRU cache with configurable TTL
✅ Tenant Scoping - Configure tenant/subscription via environment
✅ Azure Service Adapters - Type-safe access to 8 Azure services

Related MCP server: Azure Assistant MCP

Architecture Overview

flowchart TB
    subgraph Client["🖥️ Client Layer"]
        LLM[LLM / AI Agent]
    end

    subgraph MCP["⚙️ MCP Server"]
        direction TB
        Entry[index.ts]
        
        subgraph Tools["Tools"]
            T1[manage_azure_resources]
            T2[get_azure_context]
            T3[azure_service]
        end
        
        subgraph Lib["Core Libraries"]
            Auth[auth.ts]
            Cache[cache.ts]
            CLI[cli-executor.ts]
            Retry[retry.ts]
            Safety[safety.ts]
            Audit[audit.ts]
        end
        
        subgraph Services["Service Adapters"]
            S1[StorageService]
            S2[CosmosService]
            S3[SearchService]
            S4[KustoService]
            S5[MonitorService]
            S6[AppConfigService]
            S7[KeyVaultService]
            S8[PostgresService]
        end
    end

    subgraph Azure["☁️ Azure"]
        AzCLI[Azure CLI]
        AzAPI[Azure APIs]
    end

    LLM -->|MCP Protocol| Entry
    Entry --> Tools
    Tools --> Lib
    Tools --> Services
    Services --> Lib
    Lib --> AzCLI
    Auth --> AzAPI

Request Flow

sequenceDiagram
    participant C as Client
    participant M as MCP Server
    participant S as Safety
    participant E as CLI Executor
    participant A as Azure

    C->>M: Tool Request
    M->>S: Validate Input
    alt Unsafe Command
        S-->>M: Block + Warning
        M-->>C: Error Response
    else Safe
        S-->>M: Approved
        M->>E: Execute Command
        E->>A: az CLI call
        A-->>E: Response
        E-->>M: Result + Parse
        M-->>C: Structured Output
    end

Plan/Execute Flow

flowchart LR
    A[LLM Client] -->|Natural Language| B[MCP Server]
    B --> C{execute_now?}
    C -->|false| D[Return Plan]
    C -->|true| E[Execute CLI]
    E --> F{Success?}
    F -->|Yes| G[Return Output]
    F -->|No| H[Return Error + Analysis]
    H -->|Feedback Loop| A

Quick Start

1. Install Dependencies

npm install

2. Configure Environment

cp .env.example .env
# Edit .env with your settings

3. Build & Run

npm run build
npm start

MCP Client Configuration

{
  "mcpServers": {
    "azure-omni-tool": {
      "command": "node",
      "args": ["path/to/Azure-mcp/dist/index.js"]
    }
  }
}

Tools

`manage_azure_resources`

Plan and execute Azure CLI commands with safety checks.

Argument	Type	Description
`command`	string	Azure CLI command
`explanation`	string	Why this command was chosen
`execute_now`	boolean	`false` = plan, `true` = execute

`get_azure_context`

Query Azure environment with caching.

Query Type	Description
`subscriptions`	List accessible subscriptions
`resource_groups`	List resource groups
`resources`	List resources
`custom`	Custom KQL via Resource Graph

`azure_service`

Interact with specific Azure services.

Service	Actions
`storage`	list, listContainers, listBlobs, getContainer, listTables, queryTable
`cosmos`	list, listDatabases, listContainers, query, getContainer
`search`	list, listIndexes, getIndex, query, getService
`kusto`	list, listDatabases, listTables, getSchema, sample, query
`monitor`	list, getWorkspace, listTables, query, listMetrics, getMetrics
`appconfig`	list, getStore, listKeyValues, getKeyValue, setKeyValue, lock, unlock
`keyvault`	list, getVault, listKeys, getKey, createKey, listSecrets, getSecret, listCertificates
`postgres`	list, getServer, listDatabases, listParameters, getParameter, listTables, getTableSchema, query

Environment Variables

Variable	Description	Default
`AZURE_TENANT_ID`	Azure tenant for scoping	-
`AZURE_SUBSCRIPTION_ID`	Default subscription	-
`OPERATOR_EMAIL`	Email for audit trail	-
`OPERATOR_NAME`	Operator name	-
`LOG_LEVEL`	Logging level	`info`
`ENABLE_CACHE`	Enable query caching	`true`
`CACHE_TTL_SECONDS`	Cache duration	`300`
`CACHE_CLEANUP_INTERVAL_MS`	Cache cleanup interval	`60000`
`MAX_RETRIES`	Retry attempts	`3`
`RETRY_DELAY_MS`	Base retry delay	`1000`
`COMMAND_TIMEOUT_MS`	CLI timeout	`120000`
`AZURE_MCP_INCLUDE_PRODUCTION_CREDENTIALS`	Enable Managed Identity	`false`

Project Structure

Azure-mcp/
├── src/
│   ├── index.ts                 # MCP server entry
│   ├── lib/
│   │   ├── auth.ts              # Azure credential management
│   │   ├── audit.ts             # Audit trail with correlation IDs
│   │   ├── cache.ts             # LRU cache with TTL
│   │   ├── cli-executor.ts      # Azure CLI wrapper
│   │   ├── config.ts            # Environment config
│   │   ├── logger.ts            # Structured JSON logging
│   │   ├── retry.ts             # Exponential backoff
│   │   ├── safety.ts            # Input sanitization
│   │   └── types.ts             # Shared types
│   ├── services/
│   │   ├── base-service.ts      # Abstract service base
│   │   ├── storage.ts           # Azure Storage
│   │   ├── cosmos.ts            # Cosmos DB
│   │   ├── search.ts            # AI Search
│   │   ├── kusto.ts             # Data Explorer
│   │   ├── monitor.ts           # Monitor / Log Analytics
│   │   ├── appconfig.ts         # App Configuration
│   │   ├── keyvault.ts          # Key Vault
│   │   ├── postgres.ts          # PostgreSQL Flexible Server
│   │   └── index.ts             # Service factory
│   └── tools/
│       ├── azure-manager.ts     # Plan/Execute tool
│       ├── context-retriever.ts # Context queries
│       └── service-tool.ts      # Service adapter tool
├── .env.example
├── package.json
└── tsconfig.json

Prerequisites

Node.js >= 18.0.0
Azure CLI installed and authenticated (az login)

License

MIT

Available Tools

3 tools

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).

ParametersJSON Schema

Name	Required	Description
`service`	Yes	Azure service type
`action`	Yes	Action to perform
`params`	No	Action parameters (varies by service/action)

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While it lists services and actions, it doesn't explain what 'interact' entails - whether operations are read-only or mutating, authentication requirements, rate limits, error behaviors, or response formats. For a complex multi-service tool with potential write operations (e.g., setKeyValue, createKey), this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized but poorly structured. The initial sentence is clear, but the extensive bullet-like listing of services and actions could be better organized. While all content is relevant, the presentation lacks hierarchy and some redundancy exists (e.g., 'list' appears for nearly every service).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool supporting 8 services with 3-8 actions each, no output schema, and no annotations, the description is incomplete. It lists available operations but doesn't explain what they return, how to interpret results, error handling, or authentication requirements. The gap between tool complexity and description detail is substantial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds some value by listing service options and example actions, but doesn't provide additional semantic context beyond what's in the schema. The mention of 'required params for each action' is too vague to significantly enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'interacts with specific Azure services' and lists all eight supported services, providing a specific verb ('interact') and resource scope ('Azure services'). However, it doesn't explicitly distinguish this tool from its siblings (get_azure_context, manage_azure_resources), which would be needed for a score of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus its siblings (get_azure_context, manage_azure_resources). It lists available services and actions but offers no context about appropriate use cases, prerequisites, or exclusions. The final sentence about passing required parameters is operational rather than guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_azure_contextA

Retrieves Azure environment context.

TYPES: subscriptions, resource_groups, resources, custom (KQL)

CACHING: 5min default, bypass_cache=true for fresh data

EXAMPLES:

Find VMs: custom_query = "Resources | where type == 'microsoft.compute/virtualmachines'"
Find by tag: custom_query = "Resources | where tags.env == 'prod'"

ParametersJSON Schema

Name	Required	Description
`query_type`	Yes
`subscription_id`	No	Optional subscription scope
`resource_group`	No	Optional resource group filter
`custom_query`	No	KQL query for Resource Graph
`bypass_cache`	No	Force fresh data

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully describes important behavioral traits: the 5-minute default caching behavior and the bypass_cache parameter for fresh data. It also provides concrete examples of how to use custom queries. However, it doesn't mention authentication requirements, rate limits, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (TYPES, CACHING, EXAMPLES) and front-loaded with the core purpose. Every sentence earns its place by providing essential information. The examples are specific and helpful without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters, 80% schema coverage, and no output schema, the description provides good contextual coverage. It explains the different query types, caching behavior, and provides practical examples. However, without annotations or output schema, it could benefit from mentioning what format the results return in or any authentication requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 80% schema description coverage, the baseline would be 3, but the description adds significant value beyond the schema. The TYPES section clarifies what each query_type option returns, and the examples provide practical context for custom_query usage. The caching behavior explanation gives meaning to bypass_cache beyond the schema's 'Force fresh data' description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Retrieves') and resource ('Azure environment context'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'azure_service' and 'manage_azure_resources' by focusing on context retrieval rather than service operations or resource management. However, it doesn't explicitly contrast with siblings in the description text itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides implied usage guidance through the TYPES section and examples, showing when to use different query types. However, it lacks explicit direction on when to choose this tool over alternatives like 'azure_service' or 'manage_azure_resources', and doesn't mention any prerequisites or exclusions for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description
`command`	Yes	Azure CLI command (e.g., "az aks create ...")
`explanation`	Yes	Why this command was chosen
`execute_now`	No	false: plan only, true: execute

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it mentions safety ('Commands validated for injection. Destructive ops flagged HIGH risk.') and audit logging ('All ops logged with operator email and correlation ID.'). However, it lacks details on rate limits, error handling, or response formats, which would enhance transparency further.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise and well-structured, using clear sections (FLOW, SAFETY, AUDIT) with bullet-like formatting. Every sentence adds critical information without redundancy, making it easy to scan and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (executing Azure CLI commands with safety and audit considerations) and no output schema, the description is fairly complete: it covers usage flow, safety, and logging. However, it lacks details on output format, error cases, or prerequisites, which would be helpful for a tool with no annotations or output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by implying the purpose of 'execute_now' in the flow, but it doesn't provide additional semantic context for 'command' or 'explanation' that isn't already in the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states this is the 'Primary tool for all Azure operations via CLI,' which establishes it as the main interface for executing Azure commands. However, it doesn't explicitly differentiate from sibling tools like 'azure_service' or 'get_azure_context'—it implies but doesn't state that this is for command execution while others might be for service management or context retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance with a step-by-step flow: '1) Call with execute_now=false for plan 2) Review risk 3) Call with execute_now=true to execute.' This clearly indicates when to use the tool (for planning vs. execution) and implies alternatives by referencing risk review, though it doesn't name specific sibling tools as alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0

Disambiguation2/5

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 Consistency2/5

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.

Tool Count3/5

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.

Completeness2/5

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.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

OpenClaw Direct AOAuth
direct.openclaw
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Agent Orchestration Autonomous Agents Monitoring
2
Eyevinn Open Source Cloud
io.osaas.mcp
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
Cloud Platforms Agent Orchestration Developer Tools
2
Synlake
ai.synlake
Unified API to query AWS, GCP, Azure and generate Terraform/CLI execution kits for AI agents.
Cloud Platforms Developer Tools Agent Orchestration
2
Dataassist-IO
io.github.DataAssistIO
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Search Databases
2

Related MCP Servers

Azure MCP Server
Cloud Platforms Agent Orchestration
kalivaraprasad-gonapa
A
license
B
quality
C
maintenance
Enables natural language interaction with Azure services through Claude Desktop, supporting resource management, subscription handling, and tenant selection with secure authentication.
Updated a year ago (2025-07-03 19:24 UTC)
9
30
18
MIT
Azure Assistant MCP
Cloud Platforms Search Developer Tools
andrewstephenson-v1
A
license
B
quality
D
maintenance
Enables natural language exploration of Azure environments by generating and executing KQL queries against Azure Resource Graph. Supports multi-tenant configurations, subscription scoping, and provides direct access to Azure resource information through conversational interactions.
Updated a year ago (2025-09-12 19:31 UTC)
8
2
Apache 2.0
MCP Cloud Services Server
Cloud Platforms Monitoring Security
code-alchemist01
A
license
C
quality
D
maintenance
Enables AI assistants to manage multi-cloud resources (AWS, Azure, GCP) including resource operations, cost analysis, monitoring metrics, and security compliance checks through natural language commands.
Updated 10 months ago (2025-11-15 11:44 UTC)
26
16
2
MIT
kusto-mcp
Databases Cloud Platforms
johnib
A
license
A
quality
A
maintenance
Enables AI assistants to query Azure Data Explorer using natural language, eliminating the need to write KQL.
Updated a day ago (2026-09-03 05:45 UTC)
7
216
7
MIT

Appeared in Searches

C# Azure .NET development assistance

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vedantparmar12/Azure-_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server