Skip to main content

What Are A2A Agents?

A2A (Agent-to-Agent) is an open protocol for one program to discover and run another program's AI agent over HTTP. MCPBundles exposes every configured agent as an A2A agent — a runnable assistant with a public Agent Card, a unique slug, and a standard task lifecycle.

If you use MCP servers to give AI tools, A2A agents give AI (and other software) coworkers: assistants that follow your instructions, call your MCP tools on a schedule or on demand, and return structured results.

How MCPBundles maps to A2A

Every A2A agent in MCPBundles is backed by one row in your workspace:

What you configureWhat A2A exposes
Display name, description, skillsFields on the Agent Card
agents.md instructionsAgent identity and behavior
heartbeat.md checklist (optional)Repeatable steps for scheduled runs; not required for manual or on-demand runs
One MCP server (Hub or catalog slug)Tools the agent can call
Heartbeat intervalScheduled runs (cron-style)
Webhook URLEvent-driven runs from Zapier, Stripe, GitHub, etc.

When the agent is ready, MCPBundles publishes it at a stable slug. Other clients discover the Agent Card and start work with SendMessage — the A2A operation that creates a task, runs your checklist, and returns a reply.

User-facing pages vs protocol URLs

Human-readable agent pages live at https://www.mcpbundles.com/agents/{slug}. The A2A protocol endpoint (/a2a/{slug}/) is for client code and SDKs — you do not need to paste it into Zapier or email copy.

Agent Card and slug

The Agent Card is a JSON document (similar in spirit to an OpenAPI spec for an agent) that describes:

  • Name and description — what the agent does
  • Skills — optional capability tags from your skill definitions
  • Security — whether callers need OAuth, an API key, or can run anonymously (OPEN visibility)
  • Interfaces — where to send A2A messages

Cards are cached at /.well-known/agent-card.json under the agent slug. Registries and SDKs fetch the card before sending work.

Task lifecycle (SendMessage)

A typical programmatic call:

  1. Client fetches the Agent Card (or already knows the slug)
  2. Client sends SendMessage with user text or a trigger payload
  3. MCPBundles returns a task (submitted → working → completed / failed)
  4. Client polls or streams until the task finishes and reads the agent's reply

The same execution path powers scheduled heartbeats, webhook deliveries, Hub and bundle MCP agent tools, and external SDK callers — one door, one task model.

Two ways to reach an agent

MCPBundles deliberately splits chat UX from programmatic invocation:

SurfaceBest forProtocol
StudioInteractive chat with a human — streaming tokens, tool activity, editsAGUI (CopilotKit)
Everything elseSchedules, webhooks, Hub tools, external orchestrators, other agentsA2A

Studio is for conversation. A2A is for "run this checklist and give me a task back." Both use the same underlying agent configuration; they are different transports.

Visibility and who pays

Each A2A agent has an visibility setting:

VisibilityWho can discover the CardWho can run itBilling
WORKSPACEWorkspace membersSigned-in workspace membersYour workspace
PUBLICAnyoneAuthenticated MCPBundles callersCaller (or catalog rules)
OPENAnyoneAnyone, including anonymous browsersPublisher workspace

Most workspace-authored agents start as WORKSPACE. Catalog MCP servers can also publish global A2A agents for discovery.

Common triggers

  • Schedule — heartbeat interval (every hour, daily, etc.)
  • Manual Run — click Run on the agent page, Hub trigger_agent_run, or the same tools on your bundle MCP connection (trigger_agent_run, etc.)
  • Webhook — HTTP POST from Stripe, HubSpot, GitHub, Zapier, Make, n8n
  • External A2A client — any SDK or agent that speaks A2A 1.0