How enterprises will hire your agent: MCP or A2A
If your product is an agent that other companies' agents will call, MCP versus A2A is a distribution decision before it is an architecture one. In the buyer's Amazon Bedrock AgentCore Gateway, an MCP target joins the consolidated tools/list, stays in sync and is findable by semantic search; an A2A service is an HTTP target behind a path with none of those. One is a distribution channel, the other an integration project.
You have built an agent and are selling it to companies whose own agents will call it. Early in the first enterprise conversation, a platform engineer asks: do you expose it as a Model Context Protocol (MCP) server or an Agent-to-Agent (A2A) service?
Most of what is written about that choice assumes one team owns the orchestrator, the sub-agents and the tools, so the choice is a design decision inside one system. You own one end of the wire. Someone else's orchestrator decides whether to call you, and their platform decides how you appear to it. For you the choice is a distribution decision before it is an architecture decision.
In this post, we look at how a vendor-shipped agent appears inside Amazon Bedrock AgentCore (AgentCore) depending on the protocol it speaks, what you give up by being a tool as the current MCP specification stands, and how the AWS Marketplace listing follows from the same choice.
One assumption runs through the post: that your enterprise buyer fronts third-party capabilities through Amazon Bedrock AgentCore Gateway (AgentCore Gateway) rather than wiring your endpoint directly into their agent. That matches what AgentCore Gateway is for, "a standardized, secure entry point for agentic traffic, letting AI agents discover and interact with tools, other agents, and large language models (LLMs)" (Gateway core concepts ). If your buyer wires you in directly instead, the argument below about where you land in the buyer's gateway, and whether their developers can find you there, does not apply to you. What a tool can and cannot do under the current MCP specification, and how the AWS Marketplace listing follows from the protocol you choose, hold whether the buyer reaches you through AgentCore Gateway or calls your endpoint directly.
The published guidance answers a design question. You have a distribution question.
The AWS Well-Architected Framework's Agentic AI Lens gives the standard answer in one line. The desired outcome of AGENTPERF04-BP02 is that "you use MCP for tool integration, A2A for agent-to-agent coordination, and streaming protocols for real-time agent-user interactions" (AGENTPERF04-BP02 ). It is a performance practice about connection overhead and serialization, and another of its desired outcomes is "documented protocol selection guidelines for the organization". The reliability counterpart, AGENTREL01-BP03, opens with "decompose the workflow into specialized agents", then deploying each on Amazon Bedrock AgentCore Runtime (AgentCore Runtime) with a dedicated AWS Identity and Access Management (IAM) role (AGENTREL01-BP03 ). Both assume you own the workflow.
When you sell an agent, you own the callee and nothing else. The question stops being how your agents should talk to each other and becomes how you want to be hired, which raises two questions that only exist when you do not own the caller: can a developer on the buyer's side find you without being told you exist, and does an unfunded pilot ever turn into a funded integration?
Where you land in the buyer's gateway decides whether you are found
AgentCore Gateway organizes everything behind it into three target categories: MCP, HTTP and inference. An A2A service is not a category of its own. It is one of the HTTP target types, alongside AgentCore Runtime agents, external MCP servers reached directly, and any endpoint behind a passthrough target (Gateway core concepts, target types ).
For MCP targets, the gateway "operates in aggregation mode, acting as an MCP server that combines the capabilities of all its MCP targets into a unified virtual MCP server" (key concepts ). HTTP targets "do not support capability synchronization or semantic tool search" (target types ).
| You ship MCP | You ship A2A | |
|---|---|---|
| Gateway target category | MCP target | HTTP target |
| Aggregation | Combined into a unified virtual MCP server | None; traffic goes directly to your endpoint |
| How the buyer's agent sees you | One entry in the consolidated tools/list, next to the buyer's own tools | A path the caller addresses individually |
| Capability synchronization | Supported | Not supported |
| Semantic tool search | Supported | Not supported |
Read the last three rows as go-to-market rather than architecture. Ship MCP and you arrive in the buyer's tool list without anyone on their side writing code that names you. If the buyer enabled semantic search, their agent can call the built-in
x_amz_bedrock_agentcore_search tool with a natural-language query and get back the relevant tools, which can include yours (Search for tools with a natural language query ). When you change your tool definitions, capability synchronization carries the change into the buyer's view. Ship A2A and none of that applies: a developer on the buyer's side needs your target name, constructs the path, and chooses to call it.Being in the
tools/list is a distribution channel. Being behind a path is an integration project. For an early-stage company selling through one champion with no platform team behind them and no budget line for you yet, that difference decides whether the first integration happens at all.Two qualifiers on semantic search. The buyer chooses it at gateway creation: the AgentCore CLI enables it by default, and the AWS CLI and SDK paths set
searchType to SEMANTIC (Create a gateway with semantic search ). And as of October 2026 the documentation lists 18 supported Regions (supported Regions ), so check the buyer's Region against the current list.The A2A path keeps the buyer's security and policy controls
The objection a buyer's platform team raises against an HTTP target is that it sounds second-class: outside the aggregated MCP server, are you also outside the gateway's authentication, policy and observability? You are not. The A2A path is second-class on discovery, and only on discovery.
An A2A service registers as an HTTP passthrough target. The gateway "forwards requests to the target endpoint without protocol translation, acting as a secure proxy layer", and fronting A2A agents "behind a single gateway endpoint with unified access control" is a named use (HTTP passthrough targets ). The target configuration is short:
1
2
3
4
5
6
7
8
{
"http": {
"passthrough": {
"endpoint": "https://partner-agent.example.com",
"protocolType": "A2A"
}
}
}Four properties matter to you, all from the target configuration , invocation and outbound authorization sections of that page.
protocolTypeis declarative. "The gateway uses the protocol type for observability and policy evaluation but does not perform protocol translation." You speak A2A end to end.- Declaring
A2Agives the buyer guardrail coverage without work. "ForMCPandA2Aprotocol types, a default schema is applied automatically", whereas "forCUSTOMprotocol types, you must provide a schema to use guardrails." Tell your buyer to register you asA2A, notCUSTOM. - Routing is
/{targetName}/{path}on the gateway's hostname, forwarded to{endpoint}/{path}. That is the concrete shape of "addressed individually": your target name becomes part of the buyer's code. - Outbound authorization is the buyer's choice among five documented types: IAM SigV4 with the gateway's service role, OAuth through an AgentCore credential provider, the caller's own IAM credentials, passthrough of the validated inbound JWT, or an API key injected as a header.
What being a tool costs you, measured against the current MCP specification
The standard argument for A2A over MCP goes like this: MCP has no task lifecycle, so a tool cannot report progress on long work or ask the caller a clarifying question mid-task. That argument has a date on it, and the date has passed. The current MCP specification is revision 2026-07-28 (MCP specification ), and it covers all three capabilities, one of them as an extension.
Asking the caller a question. Elicitation "provides a standardized way for servers to request additional information from users through the client during interactions" (Elicitation ). In 2026-07-28 it uses the multi round-trip request (MRTR) pattern: the server returns an interim result with
resultType set to "input_required", and the client answers on a retry of the original request (changelog, major change 7 ).Reporting progress. A client attaches a
progressToken to a request, after which "the server MAY send progress notifications to report the status of requests the client has issued" as notifications/progress messages (Progress ).Long-running work. MCP Tasks let a server return a durable handle instead of blocking, with polling through
tasks/get, client input through tasks/update, and a task ID that survives a client disconnect (Tasks extension ). One qualifier matters. The 2026-07-28 revision moved tasks "out of the core protocol and into an official extension (io.modelcontextprotocol/tasks)", having been experimental in 2025-11-25 (changelog, major change 6 ). Both sides must opt into the extension; it is not a baseline every MCP client supports.AgentCore Gateway forwards the first two for MCP targets. Its supported operations include
elicitation/create and notifications/progress, across MCP versions 2026-07-28, 2025-11-25, 2025-06-18 and 2025-03-26, and it "delivers notifications (notifications/progress and notifications/message) only for requests that opt in to them" (Use an AgentCore gateway ). Two qualifiers follow. The buyer controls the version, because the gateway "accepts only the MCP protocol versions listed in the supportedVersions field" of its configuration (version note ). And on 2025-11-25 and earlier, "stateful mode is required for elicitation and sampling, because the server delivers these requests over an open session", the opposite of the stateless default the AgentCore Runtime contract directs you to; MRTR on 2026-07-28 removes that requirement (MCP protocol contract ).Once the specification caught up, a sharper argument for A2A is the one left standing. MCP's interactivity is in-band on a live request, or on an extension; A2A's is a durable task by default. A2A "natively supports long-running tasks" and "handles scenarios where agents or users might not remain continuously connected" (What is A2A, key design principles ), and its streaming response carries an explicit task state machine (A2A request lifecycle ). The discriminating question is not "can you ask a question mid-call", because you can either way. It is whether your work must outlive the caller's connection, and if so, whether the buyer's client supports the MCP Tasks extension.
You are represented as a function, not as a capability. The A2A project's position is direct: "Wrapping an agent as a simple tool is limiting: it can't capture the agent's full capabilities" (What is A2A, A2A and MCP ). An MCP tool advertises a name, a description and a JSON Schema; an A2A agent advertises named skills on its agent card (A2A protocol contract, agent card ). If what you sell is judgement over an open-ended input, say a contract review that reports whatever it finds, the output has no fixed shape and a JSON Schema is a poor container for it. If what you sell is a determinate transformation, say extracting line items from an invoice, a schema fits and the agent card adds nothing.
IP exposure is the cost that does not survive scrutiny. A2A's opaque execution is real: "Agents collaborate without exposing their internal logic, memory, or proprietary tools" (What is A2A, key design principles ). It does not follow that a tool exposes them. An MCP server is also a black box: a tool definition is a schema and a description, and your model, prompts and pipeline stay on your side of the boundary. Do not pick A2A to hide what MCP was never going to show.
The AWS rule keys on interaction shape, not on whether you are an agent
The published rule is narrower than the one most sellers apply to themselves. AGENTREL01-BP03 states it in five words, "Communication pattern follows interaction shape", then tells you to use AgentCore Gateway to "expose agents as discoverable MCP tools when the caller treats the specialized agent as a capability it invokes on demand", and A2A "when agents need peer collaboration with streaming responses or multi-turn exchanges" (AGENTREL01-BP03, implementation guidance ).
Notice what the rule does not key on: whether the callee is an agent. It keys on how the caller uses you. A reasoning agent invoked on demand, single-turn, belongs on the MCP path, and the same sentence sanctions exposing agents as MCP tools as a pattern rather than a compromise. "We are an agent, so we need A2A" is the inference the rule does not allow. What qualifies you for A2A is peer collaboration, carried as streaming responses or multi-turn exchanges.
Four questions for a seller
- Can your buyer write your output schema in advance? If yes, you are a tool. Ship MCP. If no, because which fields your response contains depends on what you find, ship A2A.
- Does your work need to survive the caller disconnecting? This is sharper than "does it finish in one request". If a caller must be able to go away and come back to a task, A2A is built for it (What is A2A ). If the work only needs to report progress on a live request, MCP covers it, provided the buyer's caller opts in to progress notifications.
- Do you need to ask the buyer's system something mid-call? No longer an automatic A2A answer: AgentCore Gateway forwards
elicitation/create(Use an AgentCore gateway ). Ask instead which MCP version the buyer's gateway runs. - What is your buyer's integration budget? If it is effectively zero, because this is a pilot run by a champion with no platform team behind them, aggregation and semantic discovery are the difference between landing and not. Ship MCP, whatever questions 1 to 3 said. If the buyer has a platform team and budget to wire you in, let questions 1 to 3 decide.
Questions 1 to 3 are the technical read. Question 4 can override them, and for a company with one design partner it should.
Recommendation: ship MCP first
Ship MCP first, and add A2A when your buyers run their own orchestrators and want you as a peer. Three reasons:
- The adoption bar is lower. The aggregation, consolidated
tools/listand semantic search that MCP targets get and HTTP targets do not (Gateway core concepts ) is the whole reason. - It matches how first integrations begin. Someone on the buyer's side drops you into an existing agent's tool list and watches whether the agent picks you up and gives better answers with you there than without.
- The choice does not lock you out of AWS Agent Registry later. The registry, the managed catalog that lets organizations "publish MCP servers, tools, agents, agent skills, and custom resources into a searchable registry" (What is AWS Agent Registry ), carries both protocols. When a buyer's organization auto-detects AgentCore Runtime resources, the AgentCore Runtime protocol maps to a descriptor type:
MCPtomcpServer,A2Atoa2aAgentCard,HTTPtohttp, andAGUItoagui(auto-detection field mapping ). Publishing on the other protocol later is a new descriptor, not a new distribution strategy.
Two details of that mapping are worth knowing, both from the auto-detection field mapping table . Every AgentCore Runtime protocol maps to
recordType: AGENT, "because auto-detection can't distinguish a standalone MCP server from an agent that exposes an MCP interface"; narrowing to MCP is a manual step on the buyer's side. And the auto-generated record name is aws-autodetected-<accountId>-<region>-<resourceId>, not your display name.If you ship both, the container contract makes it an engineering decision rather than a flag. Each protocol has its own contract: an HTTP agent binds
0.0.0.0:8080 and serves POST /invocations (HTTP protocol contract ); an MCP server binds 0.0.0.0:8000 and serves POST /mcp (MCP protocol contract ); an A2A server binds 0.0.0.0:9000, serves POST / and publishes its agent card at /.well-known/agent-card.json (A2A protocol contract ). All three require ARM64. The AgentCore Runtime containerConfiguration accepts a single containerUri and nothing else (ContainerConfiguration ), so there is no entrypoint override at deploy time. Supporting both means two images, or one image whose entrypoint reads an environment variable and starts the right server on the right port.The listing decides your product shape
The protocol you pick is also the product shape you list. AWS Marketplace has a catalog of AI agents and tools, and among the types the seller guide names, "agentic tools" covers "specialized components that enhance other AI agents, including knowledge bases, guardrails, and integration protocols such as AWS MCP Server (MCP)" (AI agent products, types ).
Two deployment options follow:
| API deployment | Container deployment | |
|---|---|---|
| Hosting | Vendor-hosted endpoints | Customer's own AWS environment |
| Suits | Specialized infrastructure or proprietary models you keep in your own environment | Customers whose data cannot leave their environment |
| Data control | Data processed on vendor servers | Greater customer control over data |
| Updates | Automatically provided by vendor | Manual updates, on the customer's schedule |
With API deployment you keep the runtime, so the container contract stays your concern. With container deployment you hand your image to the buyer, and the port and architecture requirements become a line in their deployment guide. AWS publishes those requirements for Marketplace sellers, describing the A2A differences as "the port (9000 vs 8080 for HTTP), mount path (
/ vs /invocations), and the standardized agent discovery mechanism" (AgentCore Runtime for AWS Marketplace ). Hand that page to the buyer's platform team.Listing privately first: what the private offer prerequisites allow
A tempting plan for a startup with one design partner is to transact that partner through a private offer while the listing stays in Limited visibility, skipping a public launch. If that listing is your only product, the private offer prerequisites rule the plan out.
The allowlist is a testing mechanism. When you list a container-based AI agent product, you "list any AWS accounts that should have access to the listing while in the limited state", which creates "a new change request for limited visibility testing" (Listing container-based AI agent products, step 6 ). And private offers have a prerequisite that rules the plan out. "To be eligible to issue private offers, you must have at least one active public listing" (Creating and managing private offers ). The FAQ's test is to search for your vendor on AWS Marketplace, and it gives a limited listing as one of the two reasons no products come up (Private offer FAQ, prerequisites ). Limited visibility is a testing state: allowlisted accounts can subscribe at the listed price, and no private offer can be issued against it.
If the concern is public pricing rather than public listing, there is a documented path. The pricing visibility feature, also called a leads-only listing, keeps the product visible without public pricing and replaces the Subscribe button with Request for private offer (Update pricing visibility ). Note its qualifiers: it is in preview and subject to change, it requires AWS Customer Engagement (ACE) eligibility, it applies to contract-based SaaS, AMI and container listings, so a usage-metered agent does not qualify, and the public offer must have no active subscriptions, test subscriptions included (prerequisites ). That last one means a design partner who has been subscribing from an allowlisted account has to unsubscribe before you can remove public pricing. It gets a startup most of what the private-first plan wanted.
Conclusion
If you sell an agent that other companies' agents will call, the MCP-or-A2A question is a distribution question before it is an architecture question. Inside the buyer's AgentCore Gateway, an MCP target is aggregated into one
tools/list, kept in sync and findable by semantic search; an A2A service is an HTTP target behind a path with none of those three, while keeping the gateway's authentication, policy and guardrail coverage. MCP revision 2026-07-28 gives tools elicitation and progress in the core protocol and durable tasks as an extension, so the remaining case for A2A is work that must outlive its caller, peer collaboration, and judgement that does not fit a schema.The recommendation is to ship MCP first and add A2A when buyers run their own orchestrators and want you as a peer. AWS Agent Registry carries both descriptors, so the second protocol is an addition, not a migration. Whichever you choose, read the AgentCore Runtime contract before you build the image, and the private offer prerequisites before you plan a private-first launch. For per-skill authorization and error semantics on each path, see the companion piece listed in the header.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article