Raw Cloud Run or Vercel hands you a URL and leaves auth, per-tool authorization, execution evidence, and separate code isolation for you to build. a2a cloud hosts your MCP server as a production service: every agent tool becomes an MCP tool automatically, behind an authenticated endpoint, with scoped grants per tool and gateway-signed receipts for standard MCP `tools/call` requests.
authenticated endpoint · scoped grants · signed receipts
Standing an MCP server on generic hosting is the easy 20%. The hard 80% is everything a production tool surface actually needs: authenticating callers, authorizing individual tools, keeping a tamper-evident record of what each tool did, and isolating tools that run untrusted code. On Cloud Run or Vercel that's all yours to design, wire, and keep running. Most teams ship the URL and skip the rest — and then can't answer who called which tool, under what authority.
On a2a cloud the MCP endpoint is a first-class output of `a2a deploy`, not a container you hand-harden. Auth, authorization, audit, and isolation are primitives, not follow-up projects.
Every function you expose on your agent is published as an MCP tool with a generated schema. Write the tool once; it's callable over MCP, the REST/OpenAPI gateway, and A2A without a second definition.
The hosted MCP endpoint is authenticated by default. Callers present a short-lived signed token, not a shared secret you paste into a config file and forget to rotate.
An Ed25519 grant binds exactly which tools a caller may invoke, with an audience and a TTL. A caller that needs one read tool never receives the authority to call the write tools next to it.
Standard MCP `tools/call` requests on `/mcp` and `/_a2a/mcp` pass through the the gateway gateway, which persists an Ed25519-signed receipt with caller, input evidence, result, timing, and grant IDs. Connector MCP jobs and other transports are outside this claim.
The hosted MCP service runs in a Knative or Kubernetes container. Code a tool explicitly sends through `ctx.sandbox` executes in a separate microsandbox microVM rather than turning every tool call into a VM lifecycle.
The endpoint ships with TLS, a stable hostname, and a managed Postgres database wired in. Tools that need to persist state have a database on the first deploy, not the third.
Raw Cloud Run or Vercel gives you a URL. You bolt on token verification, key rotation, and a caller identity yourself.
Authenticated MCP endpoint on deploy — short-lived signed tokens and scoped grants, no key-paste config.
One shared API key grants every tool. A read-only caller can call the destructive tools by accident or design.
Per-tool scoped grants: audience, TTL, and an explicit tool allowlist per caller.
Tool calls land in stdout logs you can edit or lose. Proving what a tool did is guesswork.
Standard `tools/call` requests on `/mcp` and `/_a2a/mcp` get gateway-signed, persisted receipts.
Tools share a container. A tool that runs untrusted code shares a blast radius with the rest.
Container-hosted MCP service; explicit `ctx.sandbox` code runs in a separate microsandbox microVM.
MCP server, database, TLS, and a hostname are four separate setup tasks across two dashboards.
One `a2a deploy` provisions the MCP endpoint, Postgres, TLS, and DNS together.
Point a2a cloud at your agent and run `a2a deploy`. It publishes an authenticated MCP endpoint with TLS and a stable hostname, provisions a managed Postgres database, and exposes every agent tool as an MCP tool. You don't stand up auth, a gateway, or a database separately.
You can — but Cloud Run and Vercel give you a URL and stop there. Authentication, per-tool authorization, signed execution evidence, and separate sandboxed code execution are yours to build and maintain. a2a cloud supplies scoped grants, gateway-signed receipts for standard MCP `tools/call`, and a microsandbox for code explicitly sent through `ctx.sandbox`.
Yes. Any function you expose on your agent is published as an MCP tool with a generated schema, and the same tool is reachable over the REST/OpenAPI gateway and A2A. You define the capability once instead of maintaining separate MCP, HTTP, and A2A definitions.
With scoped grants — Ed25519 permission tokens that bind an audience, a TTL, and an explicit tool allowlist. A caller receives authority for exactly the tools it needs, not a shared key that unlocks the whole server. There is no ambient trust between caller and endpoint.
Standard MCP `tools/call` requests on `/mcp` and `/_a2a/mcp` receive a trusted-ingress Ed25519 receipt covering caller, input evidence, result, timing, and grant IDs. Changing a signed field breaks verification. Connector MCP jobs can outlive the initial response and are not included in this coverage claim; charges and fee splits remain separate control-plane ledger fields.
All guides live in the guides index.
a2a cloud deploys any agent and publishes its tools as authenticated MCP tools — with managed Postgres, an OpenAPI gateway, TLS, and trusted-ingress Ed25519 receipts for standard `tools/call` requests on `/mcp` and `/_a2a/mcp`. Scoped grants replace shared keys, and explicit `ctx.sandbox` code execution uses a separate microsandbox. Connector MCP jobs are not included in the receipt-coverage claim.
