setup
local server
Write an MCP server, run it locally, and keep the process alive on your machine.
a2a endpoint
Deploy the agent once; a2a hosts the MCP endpoint. Copy the URL into your client.
deploy, paste, done
Connect your agent to Claude & Cursor as an MCP tool.
Deploy an agent on a2a cloud and you get a hosted MCP endpoint URL. Paste it into Claude, Cursor, or another MCP client and the agent's tools become callable. Scoped grants control access, and standard MCP `tools/call` requests on `/mcp` and `/_a2a/mcp` receive trusted-ingress signed receipts. Connector MCP jobs are outside this claim.
hosted endpoint · any MCP client · scoped per tool
the problem
Running your own MCP server to reach Claude and Cursor is a chore.
The usual path to using your agent inside Claude or Cursor is to write an MCP server, run it locally, and keep that process alive on your machine. It only works where it runs, your API keys sit in a plaintext config the client reads, and there's no way to give one client fewer tools than another. Sharing it with a teammate means they set the whole thing up again.
A local MCP server only works on the machine it's running on.
API keys live in the client's config file, in plaintext.
All-or-nothing access — no way to scope tools per client.
No record of what Claude or Cursor actually did through the agent.
the a2a way
Deploy once, get an MCP URL, paste it into any client.
a2a cloud hosts the MCP endpoint for you. The agent's tools are published over MCP automatically, access is scoped with grants, and standard `tools/call` requests on `/mcp` and `/_a2a/mcp` are signed and persisted by the gateway. Connector MCP jobs are not included in that receipt coverage.
Deploy, get an MCP URLPaste into Claude or CursorWorks with any MCP clientScoped grants per toolYour keys stay server-sideStandard tool calls, signed
Deploy, get an MCP URL
When you deploy an agent to a2a cloud, it exposes a hosted MCP endpoint. Every tool on the agent becomes an MCP tool automatically — you don't build or run a separate MCP server.
Paste into Claude or Cursor
Add the MCP endpoint URL to Claude Desktop, Claude Code, Cursor, or any MCP-compatible client. The agent's tools appear in the client, ready for the model to call directly inside your workflow.
Works with any MCP client
Because a2a serves standard MCP, the same endpoint works across MCP clients — not just Claude and Cursor. One deployed agent, many clients, no per-client rebuild.
Scoped grants per tool
Issue a grant that exposes only the tools a given client should have, with an audience and TTL. A read-only assistant and a build agent can point at the same deployment with different, least-privilege access.
Your keys stay server-side
The agent's upstream credentials and database live on a2a cloud, behind the MCP endpoint. Clients authenticate to the endpoint — they never hold your API keys or database passwords.
Standard tool calls, signed
Standard MCP `tools/call` on `/mcp` and `/_a2a/mcp` returns an Ed25519-signed receipt with caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. These gateway receipts record zero platform economics.
side-by-side
Local MCP server vs. a hosted a2a endpoint.
reach
local server
A local stdio server only works on the one machine it runs on.
a2a endpoint
A hosted URL works from any MCP client, on any machine, for anyone you grant.
tools exposed
local server
You wire each tool by hand and keep it in sync with the agent's real capabilities.
a2a endpoint
Every agent tool is exposed over MCP automatically, always in sync with the deploy.
access control
local server
All-or-nothing: whoever has the config gets every tool, with no per-client scoping.
a2a endpoint
Scoped grants expose only the tools a client should have, with an audience and TTL.
credentials
local server
API keys sit in the local config file the client reads, in plaintext.
a2a endpoint
Keys stay server-side behind the endpoint; clients authenticate without holding them.
dimension
local server
a2a endpoint
setup
Write an MCP server, run it locally, and keep the process alive on your machine.
Deploy the agent once; a2a hosts the MCP endpoint. Copy the URL into your client.
reach
A local stdio server only works on the one machine it runs on.
A hosted URL works from any MCP client, on any machine, for anyone you grant.
tools exposed
You wire each tool by hand and keep it in sync with the agent's real capabilities.
Every agent tool is exposed over MCP automatically, always in sync with the deploy.
access control
All-or-nothing: whoever has the config gets every tool, with no per-client scoping.
Scoped grants expose only the tools a client should have, with an audience and TTL.
credentials
API keys sit in the local config file the client reads, in plaintext.
Keys stay server-side behind the endpoint; clients authenticate without holding them.
questions
Frequently asked.
How do I connect my agent to Claude as an MCP tool?
Deploy the agent to a2a cloud, which exposes a hosted MCP endpoint where every tool becomes an MCP tool. Copy that endpoint URL into Claude Desktop or Claude Code as an MCP server. The agent's tools then appear in Claude and the model can call them directly — no separate MCP server for you to run.
How do I add my agent as an MCP server in Cursor?
Take the MCP endpoint URL from your deployed a2a cloud agent and add it as an MCP server in Cursor's settings. Cursor connects to the hosted endpoint and surfaces the agent's tools. Because it's a standard MCP endpoint, the same URL works in Cursor, Claude, and other MCP clients.
Does it work with MCP clients other than Claude and Cursor?
Yes. a2a cloud serves a standard MCP endpoint, so any MCP-compatible client can connect to it. You deploy the agent once and reuse the same endpoint across whichever MCP clients you or your team use, without rebuilding anything per client.
Can I limit which tools a client can access?
Yes. Scoped grants let you expose only the tools a given client should have, with an audience and a TTL. Two clients can point at the same deployment with different, least-privilege access — for example a read-only assistant versus an agent allowed to run write operations.
Do I have to put my API keys in the client config?
No. Your agent's upstream credentials and database stay server-side behind the MCP endpoint. Clients authenticate to the endpoint, and standard `tools/call` requests on `/mcp` and `/_a2a/mcp` receive signed receipts. Connector MCP jobs are outside this coverage.
keep reading
Related guides.
All guides live in the guides index.
one URL, any client
Put your agent inside Claude and Cursor.
Deploy any agent and get a hosted MCP endpoint URL. Scoped grants control access and upstream keys stay server-side. Standard `tools/call` requests on `/mcp` and `/_a2a/mcp` receive trusted-ingress signed receipts; connector MCP jobs and other transports are outside that coverage.