Multi-Cloud MCP: One Protocol to Manage Them All

Most organizations run workloads on multiple cloud providers. The reasons vary: best-of-breed service selection, regulatory requirements for geographic distribution, redundancy against provider outages, or the accumulation of services across multiple teams making independent decisions over years.

Whatever the reason, the result is the same: engineers need to manage resources across AWS, GCP, and Azure, each with its own console, CLI, authentication model, naming conventions, and mental model. The cognitive overhead is real and expensive.

I built a set of MCP servers that create a unified interface for multi-cloud management. One protocol, one mental model, consistent commands across providers. The cloud-specific details are handled by the MCP server layer, and the engineer (or AI agent) interacts through a consistent interface.

The Multi-Cloud Pain

Anyone who has worked across multiple cloud providers knows the friction.

Want to list your compute instances? On AWS, they are EC2 instances. On GCP, they are Compute Engine VMs. On Azure, they are Virtual Machines. Three different names for the same concept, three different CLI commands, three different output formats.

# AWS
aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,State.Name]'

# GCP
gcloud compute instances list --format='table(name,status)'

# Azure
az vm list --output table --query '[].{Name:name, Status:powerState}'

The commands are different. The output formats are different. The authentication flows are different. The query languages are different. Every time you switch between providers, you need to reload the provider-specific mental model.

This friction compounds for AI agents. An autonomous agent that manages multi-cloud infrastructure needs to understand three different APIs, three different error formats, three different authentication mechanisms, and three different sets of resource naming conventions. Every additional provider multiplies the complexity.

The MCP Approach

MCP servers for each cloud provider expose a normalized interface. The agent or user interacts through MCP tools with consistent naming and consistent input/output formats. The MCP server handles the translation to the provider-specific API.

// Unified interface across providers
// List compute instances, regardless of provider
mcp.tool("cloud.compute.list", {
  provider: "aws",    // or "gcp" or "azure"
  region: "us-east-1",
  filters: { status: "running" }
});

// Same interface, same output format, different provider
mcp.tool("cloud.compute.list", {
  provider: "gcp",
  region: "us-central1",
  filters: { status: "running" }
});

The response format is normalized:

{
  "instances": [
    {
      "id": "i-1234567890abcdef0",
      "name": "web-server-01",
      "provider": "aws",
      "region": "us-east-1",
      "status": "running",
      "type": "t3.medium",
      "ip": "10.0.1.15",
      "created": "2025-09-15T08:30:00Z"
    }
  ]
}

Whether the instance is an EC2 instance, a GCE VM, or an Azure VM, the response has the same shape. The consumer does not need to handle three different formats.

Normalized Service Categories

The MCP servers organize cloud services into normalized categories that map across providers:

Compute. EC2, Compute Engine, Azure VMs. Create, list, start, stop, terminate instances. Normalized instance types, status values, and metadata.

Storage. S3, Cloud Storage, Azure Blob Storage. Create buckets/containers, upload/download objects, manage lifecycle policies. Normalized access controls and naming.

Database. RDS, Cloud SQL, Azure Database. Create instances, manage backups, list databases. Normalized connection strings and configuration.

Networking. VPC, VPC (GCP), VNet. Create networks, manage subnets, configure security rules. Normalized CIDR handling and rule formats.

Serverless. Lambda, Cloud Functions, Azure Functions. Deploy functions, manage triggers, view logs. Normalized deployment packaging and invocation.

Container Orchestration. EKS, GKE, AKS. Manage Kubernetes clusters through a consistent interface. Normalized cluster configuration and node pool management.

IAM. Identity and access management across providers. List roles, policies, and service accounts through a consistent interface.

Each category provides a set of MCP tools with consistent naming conventions:

cloud.compute.list
cloud.compute.create
cloud.compute.stop
cloud.compute.terminate
cloud.storage.list-buckets
cloud.storage.upload
cloud.database.list
cloud.database.create-backup

Authentication Normalization

Authentication is one of the most painful aspects of multi-cloud management. AWS uses access keys and IAM roles. GCP uses service accounts and application default credentials. Azure uses service principals and managed identities.

The MCP servers handle authentication internally, using the provider's native credential chain. The user configures credentials once per provider, and the MCP server handles the authentication flow transparently.

# MCP multi-cloud configuration
providers:
  aws:
    auth: profile  # Uses AWS CLI profile
    profile: production
    default_region: us-east-1
  gcp:
    auth: service-account
    key_file: /path/to/service-account.json
    default_project: my-project
  azure:
    auth: cli  # Uses Azure CLI login
    subscription: my-subscription
    default_region: eastus

Configure once, use everywhere. No more juggling credentials between terminal sessions.

Agent-Driven Multi-Cloud

The real power of multi-cloud MCP becomes apparent when AI agents use it. An autonomous agent managing infrastructure across providers no longer needs provider-specific knowledge. It uses the same tools, the same formats, and the same mental model regardless of which cloud it is interacting with.

Consider an agent tasked with "ensure all production databases have recent backups":

1. cloud.database.list(provider="aws", filters={environment: "production"})
2. cloud.database.list(provider="gcp", filters={environment: "production"})
3. For each database:
   cloud.database.list-backups(provider=db.provider, database=db.id)
4. For databases without recent backups:
   cloud.database.create-backup(provider=db.provider, database=db.id)

The agent does not need to know AWS backup syntax versus GCP backup syntax. The MCP server handles the translation. The agent focuses on the logic: find databases, check backups, create missing backups.

This is a meaningful reduction in agent complexity. Instead of training agents on three different cloud APIs, you train them on one normalized interface. The agent's prompts are simpler, the context usage is lower, and the error handling is more consistent.

Cross-Cloud Operations

Some operations inherently span multiple providers. Multi-cloud MCP enables these natively.

Cross-cloud inventory. List all compute instances, storage buckets, or database instances across all providers in a single query. This is useful for cost analysis, security audits, and capacity planning.

// List all running instances across all providers
mcp.tool("cloud.compute.list-all", {
  filters: { status: "running" }
});
// Returns instances from AWS, GCP, and Azure in a single response

Cross-cloud cost comparison. Compare the cost of running a workload on different providers. Given a set of resource requirements, estimate costs across providers and regions.

Cross-cloud compliance scanning. Apply the same compliance checks across all providers. Verify that encryption at rest is enabled on all storage, that public access is restricted on all databases, that logging is enabled on all compute instances.

Limitations and Honest Assessment

Multi-cloud abstraction has inherent limitations, and I want to be transparent about them.

Lowest common denominator risk. Not every cloud service has an equivalent on other providers. DynamoDB on AWS, Spanner on GCP, and Cosmos DB on Azure are all databases, but they have fundamentally different consistency models, pricing structures, and operational characteristics. Normalizing them to a common interface necessarily loses provider-specific nuance.

The MCP servers handle this by providing both the normalized interface and provider-specific escape hatches. If you need DynamoDB-specific features, you can use the AWS MCP server directly rather than the normalized interface.

Not a replacement for provider expertise. Multi-cloud MCP reduces the friction of working across providers, but it does not eliminate the need to understand each provider's architecture for complex deployments. Networking architectures, pricing models, and service limitations are provider-specific and require provider-specific knowledge.

Performance characteristics vary. The same normalized "create compute instance" call might take 30 seconds on one provider and 90 seconds on another. The MCP layer normalizes the interface but cannot normalize the underlying platform's performance.

The Trajectory

Multi-cloud MCP is part of a broader trend toward infrastructure abstraction. Kubernetes abstracted container orchestration. Terraform abstracted infrastructure provisioning. MCP is abstracting the interaction layer between agents (human or AI) and cloud services.

The trajectory is clear: the interface through which we manage cloud infrastructure is moving from provider-specific consoles and CLIs to protocol-based interactions that AI agents can perform. MCP is the protocol layer that makes this transition practical.

For organizations running multi-cloud environments, the question is not whether to adopt a unified management interface. It is whether to build one internally or adopt an open source solution. The MCP servers I have built are one option. The important thing is that the problem is recognized and the solution exists.

One protocol. Multiple clouds. The complexity is handled at the right layer, and the humans and agents that manage infrastructure can focus on what matters: is the infrastructure serving the application's needs?