Dora NodaWithin a week of each other this spring, the two biggest clouds answered the same question — how should AI agents operate infrastructure? — in exactly opposite ways. AWS shipped one managed MCP server with a small, fixed set of tools covering all of its services. Google shipped more than fifty managed MCP servers, roughly one per service. Both are generally available, both are free beyond the resources agents touch, and both claim to be the enterprise-ready path. They cannot both be right for you.
Short answer: if you are designing a deploy surface that agents operate — deploy, rollback, scale, logs, status — start with one server and a fixed, auditable tool vocabulary, the AWS shape. The deciding factor is not taste; it is arithmetic. Every tool definition rides along in the agent's context window, and accuracy degrades measurably past a couple dozen tools.
A fleet of per-resource servers multiplies that cost, plus one auth endpoint and one version to track per server. Split into more servers only when team or versioning boundaries force it, not on day one. The sections below are the evidence: what each hyperscaler actually shipped, a head-to-head on five concrete cost rows, and a proposed tool vocabulary you can copy.
The AWS shape: one endpoint, a handful of verbs
The AWS MCP Server went generally available in April 2026 (after a November 2025 preview) as part of the Agent Toolkit for AWS. It is a single managed remote endpoint — served from two regions, US East and Frankfurt, able to call APIs in any region — and its entire pitch fits in one sentence: secure, authenticated access to all AWS services through a small, fixed set of tools.
That tool set is worth enumerating, because it is the whole design:
call_awsexecutes any of more than 15,000 AWS API operations with the caller's existing IAM credentials. New APIs are supported within days of launch, with no tool-schema change on the client side.search_documentationandread_documentationfetch current AWS docs and best practices at query time. Documentation retrieval needs no authentication, and it exists because agents otherwise answer from stale training data — AWS's own demo shows a model with a May 2025 cutoff inventing five S3 vector-storage answers while missing S3 Vectors entirely.run_scriptlets the agent run a short Python script server-side in a sandbox that inherits the caller's IAM permissions but has no network access and no local filesystem. Multi-step work — call several APIs, filter, combine — collapses into one round trip instead of N tool calls burning context each time.- Skills, served on demand and maintained by the AWS service teams, carry the curated guidance for tasks where agents most commonly err (CDK over raw CLI calls, least-privilege IAM policies). AWS is explicit about why: keeping the tool list short and predictable reduces hallucination and keeps the agent focused.
Auth and audit stay centralized because there is exactly one thing to secure. The server speaks IAM SigV4, bridged to MCP's OAuth 2.1 requirement by an open-source local proxy (mcp-proxy-for-aws). IAM context keys mean no separate permission to use the server, and policies can split human permissions from agent permissions — a user may hold mutating rights while the MCP server is restricted to read-only actions.
Observability follows the same single-choke-point logic: CloudWatch metrics under an AWS-MCP namespace separate agent calls from human calls, and CloudTrail captures every API call. In June 2026 AWS added cross-account and cross-role access within a single session, so the one endpoint follows the operator across accounts without reconnecting.
Notice what never appears in this design: a per-service tool namespace, a registry to discover servers, or a version matrix. There is one endpoint, a fixed vocabulary, and everything new arrives as API coverage or skill content behind the same verbs.
The Google shape: a server per service
At Google Cloud Next '26, Google announced the mirror image: more than 50 Google-managed MCP servers generally available or in preview, roughly one per service, after a December 2025 preview. Compute gets GKE, Cloud Run, and GCE servers. Data gets Spanner, AlloyDB, Cloud SQL, Firestore, Bigtable, BigQuery, Pub/Sub, and managed Kafka.
Then come Cloud Storage, the Developer Knowledge server (live docs grounding), Workspace servers for Gmail, Drive, Calendar, People, and Chat, plus Maps, Pay/Wallet, Security Operations, Logging, and Monitoring. Coverage is the pitch: every Google Cloud service MCP-enabled, each with tools shaped around that service's own concepts.
A fleet of fifty-plus endpoints is ungovernable without compensating platform pieces, and Google shipped those too:
- Centralized discovery through an Agent Registry — a unified directory for agents, MCP servers, and tools, so clients are not hunting endpoints.
- Fine-grained access control via native Cloud IAM, including Deny policies that can forbid MCP tool use per service.
- Content safety via Model Armor inline integration, defending against indirect prompt injection and data exfiltration at the platform layer.
- Full observability with OpenTelemetry tracing and Cloud Audit Logs for forensic review of agentic actions.
- Protocol interop work so servers expose Resources and Prompts alongside Tools, plus an Apigee path that turns any API into an MCP server with minimal effort.
Steelmanned, the fleet shape has real virtues. Each service team versions and evolves its own server independently; a breaking change to BigQuery tools never ripples into GKE clients. Tool names can be domain-specific (query_table, tail_logs) instead of squeezed through one generic verb. And least privilege composes naturally: connect the agent only to the servers it needs, and the unconnected services are unreachable by construction rather than by policy.
The honest price of those virtues is everything the registry, Deny policies, Model Armor, and audit plumbing exist to contain: N endpoints to secure, N versions to track, N tool schemas competing for the agent's attention in every session that connects broadly.
Head-to-head: where the costs actually land
Abstractions aside, here is the comparison on the five rows that decide the shape of your own server. This is the expanded, evidence-backed version of the verdict from the intro.
| Cost row | One gateway (AWS shape) | Per-service fleet (Google shape) |
|---|---|---|
| Agent context | Fixed handful of tool schemas; new APIs arrive as coverage, not new tools. run_script-style batching collapses multi-step work into one round trip. Winner on context economics. | Each connected server injects its full schema. Practitioner reports put the pain threshold at roughly 20–40 loaded tools, with single-digit-server sessions already eating six-figure token counts and tool-selection accuracy dropping by more than half on bloated toolsets. Clients like Cursor enforce hard tool caps. |
| Auth endpoints | One endpoint, one credential flow (IAM via a local OAuth bridge), one place to enforce human-vs-agent splits. | N endpoints, N credential configurations, N places to get scoping wrong — mitigated by central IAM Deny policies and a registry, but the surface still grows per server. |
| Versioning blast radius | A tool-schema change affects every consumer at once; but the vocabulary is fixed precisely so schema changes are rare — evolution happens in API coverage and skill content. | Each server versions independently; a BigQuery tool change never breaks GKE clients. Winner on isolation, at the cost of tracking N versions and N changelogs. |
| Audit attribution | Trivial: one metrics namespace and one audit trail already separate agent from human calls. | Requires platform investment — centralized logging and tracing stitched across servers — to answer "which server did the agent touch, when, with what result?" |
| Evolvability | Adding a capability means extending coverage behind existing verbs or publishing a skill: no client changes. Risk: the generic verb (call_aws) is only as safe as the IAM policy behind it. | Adding a capability means shipping a new server or new tools: discoverable and typed, but every addition spends context budget and registry/maintenance overhead. |
Neither shape sweeps all five rows, and that is the point. The gateway wins on context, auth concentration, and audit simplicity; the fleet wins on versioning isolation and domain-typed tools. For a hyperscaler with hundreds of services, independent teams, and a platform org to build registries and Deny-policy frameworks, the fleet's overhead is affordable. For a deploy surface — a bounded set of verbs over apps, releases, and logs — the gateway's wins dominate and the fleet's wins solve problems you do not have yet.
What this means for your deploy MCP surface
If agents are going to operate your platform, copy the AWS shape first and steal Google's governance pieces as you grow. Concretely:
Ship one server with a fixed, auditable vocabulary. For a git-push PaaS, seven verbs cover nearly everything an operator agent needs: deploy, rollback, scale, logs, status, search_docs, and a sandboxed exec for the multi-step glue (the run_script lesson: give the agent a batching primitive or it will burn a tool call per API hop). New platform capabilities should arrive as coverage behind these verbs or as skill content — runbook knowledge the server retrieves on demand — not as an eighth, ninth, and tenth tool. Version the vocabulary like the API contract it is: additive changes freely, removals never without a major version.
Put docs and skills behind the server, not in the prompt. Both hyperscalers converged here despite opposite shapes: AWS serves skills on demand and retrieves docs at query time; Google ships a Developer Knowledge server for the same reason. Stale training data is the failure mode — the agent confidently describing last year's deployment flow. A search_docs tool plus maintained runbook skills keeps the agent grounded in today's platform without bloating its context on every call.
Centralize auth and audit at the one choke point. One endpoint means one OAuth flow, one place to enforce read-only-vs-mutating splits per tenant, and one audit trail where every agent action is attributable. This is the gateway's compounding advantage: the audit story that costs Google a cross-service logging platform costs you a request log with tool name, caller identity, and result.
Split only when a boundary forces it — and name the boundary. The legitimate reasons to add a second server are organizational, not aesthetic: a separately-versioned surface owned by another team, a compliance scope that must be unreachable-by-construction rather than by policy, or a tool family whose schemas genuinely do not fit the core vocabulary. "The tool list feels long" is not a boundary; it is a sign to move guidance into skills. When you do split, adopt Google's compensations on day one of the split: a registry or directory, deny-by-default scoping, and centralized audit — because an undiscoverable, unaudited second server is how a tidy gateway decays into a fleet with none of the fleet's governance.
One more lesson spans both designs: keep the agent's permissions visibly narrower than the human's. AWS lets policy say "this user may mutate, their agent may only read"; Google's Deny policies do the same per service. Whatever shape you pick, the deploy surface should make that split a first-class, reviewable policy — it is the control your future incident review will ask about first.
The vocabulary is the product
Strip away the branding and both clouds agree on the deep point: the tool vocabulary is the API contract agents program against, and it deserves API-contract discipline. AWS keeps that contract tiny and central; Google distributes it and invests heavily in the machinery — registries, Deny policies, injection defenses, unified audit — that makes a distributed contract safe. A self-hosted platform gets to choose its burden: a small vocabulary that is cheap to secure and easy for agents to use correctly, or a fleet whose power you pay for in context, auth surface, and governance plumbing with every addition.
Start with the gateway. Count your tools like you count your API endpoints. And when the day comes that a real boundary demands a second server, you will know exactly what it costs — because the two biggest clouds just showed you both receipts.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agents as first-class operators. Star the repo on GitHub or deploy your first app today.
