Skip to main content
Glama
akkireddy-challa

azure-mcp-platform

by akkireddy-challa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

azure-mcp-platform

MCP server for Azure resource management, AI Foundry, and Entra ID — inspect and operate Azure infrastructure through AI agents.

Glama Quality Score License: MIT Python Azure MCP

What is this?

azure-mcp-platform wraps the official Azure MCP Server with production-ready configuration, Entra ID authentication, and platform-engineering patterns for operating Azure environments safely from AI agents.

Built for platform engineers running multi-tenant Azure environments with AI Foundry, AKS, and enterprise SSO via Entra ID.

Related MCP server: cloudscope-mcp

Available Tools

Tool

Category

Description

list_resource_groups

Resource Mgmt

List all resource groups in a subscription

list_resources

Resource Mgmt

List resources in a resource group by type

get_resource

Resource Mgmt

Get details of a specific Azure resource

list_ai_foundry_projects

AI Platforms

List Azure AI Foundry projects and deployments

get_aks_cluster

Containers

Get AKS cluster status and node pool health

list_entra_users

Identity

List Entra ID users and group memberships (read-only)

get_key_vault_secrets

Security

List secret names (not values) in Key Vault

list_storage_accounts

Storage

List storage accounts and their access tiers

Quick Start

Prerequisites

  • Python 3.11+

  • Azure CLI authenticated: az login

  • Appropriate Azure RBAC role: Reader minimum

  • (Optional) Service principal with Reader + AcrPull for CI environments

Run Locally

git clone https://github.com/akkireddy-challa/azure-mcp-platform.git
cd azure-mcp-platform
pip install -r requirements.txt
az login
python server.py

Configure with Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "azure": {
      "command": "python",
      "args": ["/path/to/azure-mcp-platform/server.py"],
      "env": {
        "AZURE_SUBSCRIPTION_ID": "your-subscription-id",
        "AZURE_TENANT_ID": "your-tenant-id"
      }
    }
  }
}

Example Usage

Ask your AI agent:

  • "List all resource groups in my subscription"

  • "What AKS clusters are running in the production resource group?"

  • "Show me all AI Foundry projects and their model deployments"

  • "Which storage accounts in rg-data have public access enabled?"

  • "List all users in the platform-engineers Entra group"

Security Model

  • Read-only by default: all tools use GET operations only.

  • Entra ID SSO: authenticates via Azure CLI credential chain or Managed Identity.

  • No secrets exposed: Key Vault tool lists secret names only, never values.

  • Subscription-scoped: tools operate within a single configured subscription.

  • Recommended role: Reader at subscription scope for full read access.

# Assign Reader role to a service principal
az role assignment create \
  --assignee <service-principal-id> \
  --role Reader \
  --scope /subscriptions/<subscription-id>

Use Cases at Telia

This pattern is used to allow AI agents to:

  • Audit resource configurations across multi-tenant Azure environments.

  • Cross-reference AKS cluster state with AI Foundry model deployments.

  • Investigate Entra ID group membership for access reviews.

  • Inspect cost anomalies by listing resources and their SKUs.

Roadmap

  • get_cost_analysis — query Azure Cost Management for spend by resource group

  • list_policy_assignments — show Azure Policy compliance state

  • get_monitor_alerts — list active Azure Monitor alerts

  • list_app_registrations — Entra ID app registrations and permissions

  • Managed Identity support for AKS pod deployment

  • GitHub Actions workflow for CI validation

Related Projects

Repo

Purpose

k8s-mcp-server

Kubernetes cluster diagnostics via MCP

grafana-mcp-observability

Grafana dashboards and alerts via MCP

phoenix-mcp-eval

LLM tracing and evaluation via MCP

License

MIT License. See LICENSE for details.

Built by Akkireddy Challa — Platform Engineer at Telia, Stockholm.

Available Tools

3 tools
azure_list_resource_groupsA

List resource groups available within a specific Microsoft Azure subscription.

Usage Guidelines

  • Intended for cloud inventory mapping and configuration inspection.

ParametersJSON Schema
NameRequiredDescriptionDefault
subscription_idYesAzure Subscription GUID used to query active resource groups.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

There are no annotations, and the description only says 'list', which implies read-only behavior but does not explicitly disclose side effects, permissions, data scope, or any operational constraints.

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 compact and front-loaded, with no redundant information. The main purpose and intended use are stated in two short sentences.

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 simple one-parameter read-only list operation, the description is sufficient. It lacks explicit return format or pagination details, but these are not critical for basic use.

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?

The schema already provides a clear description for subscription_id, and the tool description adds no additional parameter nuance, so the baseline of 3 is appropriate.

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

Purpose5/5

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

Clearly states the action ('list') and object ('resource groups') within a specific Azure subscription, making the tool's purpose unambiguous and distinct from the Censys sibling tools.

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?

Mentions intended use cases ('cloud inventory mapping and configuration inspection') but does not explicitly explain when to prefer this tool over alternatives or when it should not be used.

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

censys_get_hostA

Retrieve comprehensive intelligence and protocol details for a single host.

Usage Guidelines

  • Provides full port fingerprints, TLS certificates, DNS records, and vulnerability exposure.

  • Target must be a raw IPv4 or IPv6 string without scheme or CIDR masking.

ParametersJSON Schema
NameRequiredDescriptionDefault
ipYesValid public IPv4 or IPv6 address to retrieve comprehensive scan telemetry for.
at_timeNoRFC-3339 formatted timestamp to retrieve historical host state.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

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

The description implies a read-only retrieval operation and discloses output content, but it does not explicitly state side-effect-free behavior, authentication needs, rate limits, or error handling. Since no annotations are provided, the description carries the burden of clarifying these behavioral traits.

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 concise, front-loaded with the main purpose, and uses a short bullet-style usage section. There is no redundant or filler content.

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?

The output schema is present, both parameters are documented, and the description captures the key deliverable categories. The only minor gap is the absence of explicit guidance on choosing between this and the host-search sibling tool.

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

Parameters5/5

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

Both parameters are fully described in the schema, and the description adds meaningful input constraints such as 'without scheme or CIDR masking'. It also clarifies that at_time is used for historical host state, going beyond the schema's basic type information.

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

Purpose5/5

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

The description clearly identifies the action ('Retrieve') and resource ('comprehensive intelligence and protocol details for a single host'). This distinguishes it from sibling tools like censys_search_hosts, which implies searching over hosts rather than fetching one host by IP.

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

Usage Guidelines4/5

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

It gives practical constraints, such as requiring a raw IPv4/IPv6 address without scheme or CIDR masking, and lists the types of data returned. However, it does not explicitly mention when to use this tool instead of censys_search_hosts.

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

censys_search_hostsA

Search internet-connected hosts across the global Censys IPv4/IPv6 database.

Usage Guidelines

  • Best for discovery of exposed external infrastructure, open ports, and services.

  • Uses Censys Search v2 syntax on the /v2/hosts/search endpoint.

  • Requires active CENSYS_API_ID and CENSYS_API_SECRET credentials.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query using Censys Search Language syntax (e.g., 'services.port: 443 AND location.country: US').
cursorNoBase64-encoded pagination cursor string obtained from a previous query response.
per_pageNoTotal quantity of host results to return per page (min 1, max 100).
virtual_hostsNoWhether to include virtual hosts. Allowed values: 'EXCLUDE', 'INCLUDE', 'ONLY'.EXCLUDE

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior3/5

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

No annotations are provided, but the description does disclose the credential requirement and the action is clearly a search, implying read-only behavior. It does not explicitly state whether the operation is non-mutating, mention rate limits, or describe pagination behavior beyond the cursor parameter, so some behavioral transparency is left implicit.

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 and usage guidelines are brief, focused, and free of redundant or filler content. Every sentence adds value, and the structure clearly separates purpose, usage, and credential requirements.

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

Completeness5/5

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

The description is complete for a search tool: it names the endpoint, specifies the query language, describes all input parameters, and covers authentication. The presence of an output schema means response details are not required in the description, and the provided context is sufficient for an agent to invoke the tool correctly.

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

Parameters5/5

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

All parameters are described with useful detail: query includes a syntax example, cursor explains base64 pagination, per_page has min/max constraints, and virtual_hosts lists allowed values. The schema coverage is complete and the descriptions add meaningful context beyond simple type declarations.

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

Purpose5/5

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

The description explicitly states the action ('Search'), the target resource ('internet-connected hosts'), and the scope ('global Censys IPv4/IPv6 database'). It also includes a clear use case ('discovery of exposed external infrastructure, open ports, and services'), which distinguishes it from the sibling single-host tool.

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

Usage Guidelines4/5

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

The Usage Guidelines provide concrete guidance: best for discovery tasks, uses Censys Search v2 syntax on the specific endpoint, and requires credentials. However, it does not explicitly contrast this tool with the sibling 'censys_get_host' or state when to prefer one over the other.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedazure_list_resource_groups
    • First observedcensys_get_host
    • First observedcensys_search_hosts
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation4/5

The three tools are clearly distinct: two Censys operations (search vs. get) and one Azure operation. However, the server name implies an Azure-only platform while including Censys tools, which could mislead an agent about the server's scope, though the tools themselves are unambiguous.

Naming Consistency5/5

All tool names follow a consistent provider_verb_noun pattern (censys_search_hosts, censys_get_host, azure_list_resource_groups), making it predictable and easy to parse.

Tool Count2/5

With only 3 tools spanning two unrelated domains (Censys and Azure), the set feels under-scoped for a 'platform' server. Each domain has minimal coverage, making the count too low for the implied breadth.

Completeness2/5

Censys is limited to host search and host details, missing certificate search, account info, or other common endpoints. Azure only lists resource groups, lacking create/update/delete or any other resource operations. The surface is severely incomplete for both domains.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • quads-mcp

    grafuls
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for interacting with QUADS infrastructure systems via API, enabling resource management and automation through LLM applications.
    MIT

  • avm-mcp-server

    stefanstranger
    A
    license
    A
    quality
    C
    maintenance
    MCP server for discovering and exploring Azure Verified Modules (AVM) from the Bicep Public Registry, enabling AI agents to search, retrieve module details, and access documentation.
    2
    6
    MIT