Publish an Agent as MCP / A2A

An agent you build in RunAIAgents doesn't have to be something only you run from the dashboard. You can publish it so other tools and agents can call it directly.

Publish as an MCP server

Model Context Protocol (MCP) is the same protocol RunAIAgents agents already use to call MCP tools themselves — publishing your agent as an MCP server puts it on the other side of that relationship. Once published, any MCP-compatible client (another agent, an IDE assistant, a custom integration) can connect to your agent as a tool source and invoke it the same way your own agents invoke MCP tools today.

This is useful when you've built an agent that performs a well-defined, reusable capability — summarizing a document, looking something up, triaging a request — and you want that capability available to systems outside RunAIAgents without rebuilding it there.

Expose an A2A card

A2A (agent-to-agent) is a way for one agent to discover and call another. Publishing an A2A card describes your agent — what it does and how to reach it — in a form other agent systems can read and act on. Where MCP publishing exposes your agent as a callable tool, an A2A card exposes it as a callable agent: something another agent can hand a task to and get a result back from, rather than a single tool invocation.

What this enables, conceptually

• Reuse across systems. Build the agent once in RunAIAgents, then let other tools or agents call it instead of re-implementing the same logic elsewhere.
• Composability. Other agents — inside or outside RunAIAgents — can treat your published agent as one more capability in their own tool set, including agents that themselves use subagent delegation.
• A stable interface. Because agents in RunAIAgents are versioned, publishing exposes a specific released version's behavior, so downstream callers aren't affected mid-flight by changes you're still testing.

How it fits with versioning and deploys

Publishing as MCP or exposing an A2A card operates on a released version of your agent, the same version model used elsewhere in the platform: you release a version, then make it callable. This keeps the same separation used for deploying to your own cloud — external callers hit a version you've explicitly released, not whatever you happen to be editing in the builder.

Security considerations

Calls arriving through a published MCP endpoint or A2A card still go through the same execution path as any other run — the agentic harness, tool argument validation, and destructive-action approval gates all still apply. Publishing an agent doesn't bypass approval gates; a destructive tool call triggered by an external caller still halts and waits for human approval the same way it would if you triggered the run yourself.

Related

• Bring your own keys — if the published agent uses BYOK, calls made by external callers still draw on that same key.
• Troubleshooting — for issues with connector calls or blocked outbound requests that can also affect published agents.