a2a cloud
spec in, agent out

Turn any OpenAPI spec into an MCP server and agent.

Point a2a cloud at an OpenAPI or HTTP spec and it generates a hosted agent — one typed tool per operation — exposed as an MCP server and as A2A endpoints. Your whole API becomes callable by agents and MCP clients, with upstream auth and scoped grants handled for you. No per-endpoint glue code.

tool-per-operation · hosted MCP · scoped grants

the problem

Wrapping an API as an MCP server by hand is repetitive, partial work.

To make an existing API usable by agents, teams hand-write an MCP server: a tool handler per endpoint, parameters mapped by hand, responses marshaled manually. It's tedious, it usually covers only the few endpoints someone had time for, and it drifts out of sync the moment the API changes. Then you still have to solve auth and figure out who's allowed to call what.

One hand-written tool handler per endpoint — slow and error-prone.
Coverage is partial: only the endpoints someone bothered to wrap are reachable.
Types are copied by hand and drift as the API evolves.
Upstream API keys leak into client configs, with no record of who called what.
the a2a way

Give a2a the spec. It generates the agent, the MCP server, and the grants.

The spec already describes every operation, its parameters, and its responses. a2a cloud reads it and does the wrapping for you — the whole API, typed, hosted, and governed.

Point at a spec, get an agentOne tool per operationHosted MCP server, automaticallyA2A endpoints tooAuth handled at the edgeScoped grants per operation

Point at a spec, get an agent

Give a2a cloud the URL or file of an OpenAPI (or plain HTTP) API. It reads the spec and generates a hosted agent that wraps the API — no glue code, no per-endpoint handlers to write by hand.

One tool per operation

Each operation in the spec becomes a named, typed tool on the generated agent. Parameters, request bodies, and responses are derived from the spec's schemas, so the agent knows the shape of every call.

Hosted MCP server, automatically

Every generated tool is also exposed as an MCP tool. The result is a hosted MCP server for the API — paste the endpoint into Claude, Cursor, or any MCP client and the operations show up as tools.

A2A endpoints too

The same generated agent is A2A-native: it serves an agent card advertising the operations as skills, so other agents can discover and call the API through it — not just human-driven MCP clients.

Auth handled at the edge

Configure the upstream API's credentials once at the agent. Callers authenticate to a2a cloud; the platform holds the upstream key. Your API secrets don't get pasted into every MCP client or shared around.

Scoped grants per operation

Grant callers only the operations they need. A scoped grant can permit some skills and deny others, with an audience and TTL, and every invocation returns a signed receipt recording who called which operation under what authority.

side-by-side

Hand-rolled MCP server vs. generated from your spec.

dimension
hand-written
generated by a2a
effort
Hand-write an MCP server: one tool handler per endpoint, mapping params and marshaling responses yourself.
Point a2a at the OpenAPI spec. Tool-per-operation agent and MCP server are generated for you.
coverage
You wrap the two or three endpoints you had time for; the rest of the API stays inaccessible to the agent.
Every operation in the spec becomes a tool, so the whole API is available, not a hand-picked subset.
typing
Parameter and response shapes are copied by hand and drift out of sync with the API over time.
Types are derived directly from the spec's schemas, so the agent's view matches the contract.
auth
The upstream API key ends up embedded in client configs and passed around in plaintext.
Credentials live at the agent; callers authenticate to a2a cloud and never hold the upstream secret.
authority & audit
No record of which caller hit which endpoint, or whether they were even allowed to.
Scoped grants gate operations and every call returns a signed receipt of who did what.
questions

Frequently asked.

How do I turn an OpenAPI spec into an MCP server?

On a2a cloud, you point the platform at your OpenAPI (or HTTP) spec by URL or file. It generates a hosted agent with one tool per operation, and exposes every tool as an MCP tool. The result is a hosted MCP server for your API that you can connect to Claude, Cursor, or any MCP client — no per-endpoint code to write.

Can I turn any REST API into an agent?

If the API has an OpenAPI description — or a documented HTTP interface a2a can ingest — yes. Each operation becomes a typed tool on a generated agent, so the REST API becomes callable as an agent (via A2A) and as MCP tools, with auth and scoped grants layered on top.

Does each API operation become a separate tool?

Yes. The generator maps one operation in the spec to one named tool, deriving its parameters and response shape from the spec's schemas. That tool is exposed both as an A2A skill and as an MCP tool, so the granularity matches your API surface.

How is authentication to the upstream API handled?

You configure the upstream API's credentials once at the generated agent. Callers authenticate to a2a cloud, and the platform holds and uses the upstream key on their behalf — so your API secret isn't pasted into every MCP client config or shared around in plaintext.

Can I restrict which operations a caller can use?

Yes. Scoped grants let you allow a caller only the operations they need and deny the rest, with an audience and TTL. Every invocation returns an Ed25519-signed receipt recording who called which operation under which grant, so access is both controlled and auditable.

keep reading

Related guides.

All guides live in the guides index.

your API, agent-ready

Ship your API as an agent today.

Point a2a cloud at your OpenAPI or HTTP spec and get a hosted agent with one tool per operation, exposed as an MCP server and A2A endpoints. Upstream credentials stay at the edge, scoped grants gate access per operation, managed Postgres is included, and every call returns a signed receipt. One deploy turns an existing API into a governed, agent-native service.