The useful architectural distinction here is not vendor branding but whether MCP is being introduced as an agent control plane or as a data-access boundary. That choice affects how you design isolation, approval flows and auditability. If an MCP server can mutate cloud resources, it belongs in the same governance conversation as infrastructure automation: scoped roles, break-glass controls, environment separation and policy guardrails. If it primarily fronts databases, the harder problem is query safety, data minimisation and protecting high-value records from over-broad tool exposure.
For multi-cloud teams, the protocol standard does not remove integration complexity. It can actually hide it. A single agent using several MCP servers still crosses distinct identity domains, logging systems, rate limits and permission models. That means architects should treat each server as a separate trust zone with its own lifecycle: credential issuance, tool registration, telemetry, incident response and revocation. “One agent” does not mean one blast radius.
Before adopting any of these offerings, practitioners should test three implementation details that are easy to underestimate:
- whether tool permissions map cleanly to least-privilege roles rather than broad human administrator access;
- how observable model-initiated actions are across existing SIEM, cloud audit and operational monitoring pipelines;
- where policy enforcement happens when the model chains several tools across clouds or from code assistant to production resource.
The near-term winner in most enterprises will not be the broadest MCP catalog, but the server model that fits existing identity, approval and logging controls with the least custom glue. MCP may standardise tool calling, but operational trust still depends on platform-specific controls around it.
The Model Context Protocol is the common wire between an AI agent and the tools it is allowed to use. AWS, Azure, and Google Cloud all ship MCP servers now, and they are not the same product with different logos. One side of the market is a cloud control plane for agents. The other is a guarded door into data. Identity, hosting, and blast radius follow from that split.
If you are connecting an agent to cloud resources, picking an MCP server is picking what the model can see and who authenticates the call.
AWS: a catalog, then a managed remote server
AWS Labs publishes open-source MCP servers as a monorepo. The set is meant to sit in a developer workflow: documentation lookup, API access, and specialized servers for individual services. In July 2025 AWS announced the AWS API MCP Server, which lets an MCP client discover supported AWS APIs and inspect, create, or change resources through the model. Access control is IAM.
That open-source API server is already being folded into something hosted. The AWS MCP Server (in preview), described in the same Labs repo, is remote and run by AWS. It pairs API access with documentation retrieved at query time, Getting Started material, and pre-built agent SOPs. Calls are syntactically validated. Activity can land in CloudWatch and CloudTrail. OAuth 2.0 is part of the design. The point is not a clever protocol wrapper. It is putting the agent on the same control plane you already use: IAM for permission, CloudTrail for the record.
InfoWorld called official maintenance the real advantage. The catalog is broad and it keeps moving. You pay for that with more moving parts. There is not one “the AWS MCP server” in the way Microsoft presents Azure MCP Server. You choose from a suite, or you point at the managed endpoint.
Azure: one productized server, Entra ID, Copilot as the client
Microsoft’s Azure MCP Server is the named entry. It speaks MCP to clients such as GitHub Copilot agent mode, the OpenAI Agents SDK, and Semantic Kernel. Sign-in is Entra ID through the Azure Identity library. The server covers Azure resources and also the Azure CLI and Azure Developer CLI (azd), which matters if the agent is supposed to do what a person would do at a terminal.
There is a hosted track as well. Foundry MCP Server (preview) is cloud-hosted. You do not stand up infrastructure. Agents get a curated set of read and write tools against Foundry services, still authenticated with Entra ID. Copilot Studio can register an MCP server as an HTTPS endpoint so a studio-built agent discovers tools at runtime, as Microsoft Q&A describes for custom servers running in Azure.
Docs are the other difference. InfoWorld found Azure’s getting-started path easier than AWS’s, with clearer notes on tool parameters and on turning off agent control of sensitive functions. If the shop already lives in Entra and Copilot, this is the least awkward fit. The scope is Azure-shaped: resources, CLIs, Foundry, Copilot. It is not a general database gateway.
Google Cloud: databases first, Gemini as the usual client
Google did not start with a kitchen-sink control plane. It started with data. MCP Toolbox for Databases (formerly Gen AI Toolbox for Databases) is an open-source MCP server that connects agents to enterprise databases. Google later said it natively supports 42 data sources, including AlloyDB, Cloud SQL, Cloud Spanner, and third-party stores. The Toolbox takes on connection pooling, authentication, and observability so that glue is not rewritten for every agent.
BigQuery has a documented path to pre-built MCP tools. Gemini CLI extensions and Gemini Code Assist can bundle the server, so you may not install Toolbox separately if you stay inside those clients. Google’s MCP overview treats local versus remote and managed versus self-hosted as first-class choices.
The trade is obvious. An agent that should run constrained SQL against AlloyDB or BigQuery is on home ground. An agent that should provision clusters or rewrite IAM the way AWS’s API path can mutate AWS resources is a different job. Google’s MCP story is strongest where the data lives.
Auth, hosting, and surface area
Three dimensions matter more than the logo.
Who signs in. AWS leans on IAM, and on OAuth for the managed server. Azure leans on Entra ID. Google’s Toolbox is built around database credentials and Google Cloud auth for those sources. Mixing clouds means mixing identity models. An agent with three MCP servers is three trust boundaries.
Where it runs. AWS now offers local open-source servers and a hosted AWS MCP Server. Azure offers the developer-facing Azure MCP Server and a hosted Foundry MCP Server. Google’s Toolbox is something you run, often next to the IDE, with Gemini products bundling it. Hosted servers cut ops. Local servers keep credentials and data on your machine.
What the agent can touch. AWS is APIs and docs across many services. Azure is Azure resources plus developer CLIs plus Foundry and Copilot. Google is databases. Community servers still fill gaps (GitHub, Slack, Postgres, Drive) that none of the three treat as their main job.
How to choose without a bake-off
Match the server to the job, not to a brand preference. An ops agent that should list buckets and rotate keys belongs on AWS’s API path or on Azure MCP, depending on the account. An analyst agent that should run constrained SQL belongs on MCP Toolbox. A Copilot Studio bot that should call an internal tool belongs on a remote HTTPS MCP server registered in Studio, which can sit in Azure even if the tool is not an Azure resource.
Multi-cloud agents will run more than one MCP server. That is normal. The protocol is shared. The servers are still product-specific, with product-specific blast radius.
The interesting split is not which cloud “has MCP.” They all do. It is whether you want a general cloud control plane for an agent (AWS and Azure) or a guarded door into data (Google), and whether that door is hosted by the vendor or sitting next to the model on your laptop.
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.