What is the current MCP specification as of August 10, 2026?

The current dated core revision is 2026-07-28. It defines stateless, self-contained requests and per-request capability negotiation.

Does MCP 2026 prohibit stateful applications?

No. It removes protocol-level sessions. A server can preserve business state by returning an explicit handle that the client passes in later tool calls.

Is SSE removed from MCP?

No. The general GET stream and replay mechanism are removed, but a Streamable HTTP response can still be SSE when scoped to one request, and subscriptions/listen uses a long-lived response stream for opted-in notifications.

Can a modern client talk to a legacy server automatically?

Only if the implementation includes the documented dual-era detection and fallback behavior. A modern-only client and legacy-only server do not inherently interoperate.

Is authorization required for every MCP server?

Authorization is optional in the core protocol. When authorization is supported over HTTP, implementations should conform to the MCP authorization specification; stdio implementations should obtain credentials from the environment instead of using that HTTP flow.

Should a new enterprise deployment use DCR?

Prefer CIMD or pre-registration. DCR remains available for backward compatibility but is Deprecated in 2026-07-28.

When should an architecture use A2A as well as MCP?

Use MCP for an agent’s tools and context. Add A2A when separate agents need standards-based discovery, delegation, and task exchange across system boundaries.

Protocols & integration

MCP 2024–2026 Enterprise Release Tracker and Migration Guide

MCP’s July 2026 release is an architectural boundary, not a routine feature update. The protocol moved from connection-scoped negotiation and optional transport sessions to stateless, self-contained requests. Teams upgrading from a 2025 implementation must revisit lifecycle, routing, state, recovery, authorization, notifications, and extension handling together. This tracker converts the official, dated specifications — the five revisions from 2024-11-05 through 2026-07-28, plus the stable Enterprise-Managed Authorization extension released in June 2026 — into an enterprise migration plan.

Author: Implement Agentic Research
Published: Published 2026-08-10 · Updated 2026-08-26
Reading time: 18 min read
Data currency: Official specifications and implementation notices reviewed through 2026-08-26

Key findings

Treat 2026-07-28 as a new protocol era. It removes the initialize / notifications/initialized handshake and Mcp-Session-Id. Version and client capabilities now travel with each request; clients should also identify themselves per request. Servers must implement server/discover, although clients do not have to call it before invoking another method.
Do not equate “stateless protocol” with “stateless application.” Cross-call state can remain, but the server should mint an explicit handle and the client should pass it as a normal tool argument.
Replace connection recovery assumptions. The modern Streamable HTTP binding has no GET stream endpoint and no Last-Event-ID resumption. A broken response stream loses that in-flight request; a client reissues the operation with a new request ID.
Update gateways and caches deliberately. Modern HTTP requests mirror protocol metadata into required MCP-Protocol-Version, Mcp-Method, and—in named operations—Mcp-Name headers. Cacheable discovery, list, and resource-read results include ttlMs and cacheScope.
Rebuild interactive flows around Multi Round-Trip Requests (MRTR). Instead of a server sending roots/list, sampling/createMessage, or elicitation/create over an open stream, it returns resultType: "input_required"; the client retries the original operation with inputResponses.
Modernize authorization, not just transport. The current authorization specification prefers Client ID Metadata Documents (CIMD), deprecates Dynamic Client Registration (DCR), requires resource indicators, and requires validation of a present RFC 9207 iss. Enterprise-Managed Authorization (EMA) adds an opt-in IdP-controlled flow for centralized policy.

Comparison & evidence

Each row summarizes the dated official revision. Revision labels are calendar dates, not semantic versions.

Versioned change tracker: MCP revisions 2024-11-05 through 2026-07-28, plus the stable EMA extension
Revision / milestone	Lifecycle and transport	Authorization and enterprise controls	Features and migration signal
2024-11-05 revision; MCP publicly announced Nov. 25, 2024	Stateful connection lifecycle: initialize, capability negotiation, notifications/initialized, operation, shutdown. Standard transports were stdio and HTTP+SSE; the HTTP binding used separate SSE and POST endpoints.	Authorization was outside the core specification; peers could negotiate custom strategies.	Establishes the legacy baseline. Inventory any implementation that still assumes a persistent connection or separate SSE endpoint.
2025-03-26	Streamable HTTP replaced HTTP+SSE. It defined one MCP endpoint that had to accept POST and GET; a GET could either open an SSE stream or return 405 Method Not Allowed, so the standalone server-to-client SSE stream was optional. It allowed a server-issued Mcp-Session-Id and SSE replay using event IDs and Last-Event-ID.	Added an OAuth 2.1-based authorization framework for HTTP transports; authorization remained optional for MCP implementations.	Added tool behavior annotations and JSON-RPC batching. HTTP+SSE became deprecated as Streamable HTTP replaced it.
2025-06-18	Required the negotiated version in MCP-Protocol-Version on subsequent HTTP requests. Session IDs and SSE resumption remained available.	Classified MCP servers as OAuth resource servers, added Protected Resource Metadata discovery, and required clients to use RFC 8707 Resource Indicators.	Removed JSON-RPC batching; added structured tool output, elicitation, and resource links in tool results.
2025-11-25	Retained handshake, sessions, GET streams, and resumability; clarified that resumption uses GET and that servers may disconnect polling streams.	Added OpenID Connect Discovery, incremental scope consent through WWW-Authenticate, and CIMD as the recommended registration mechanism.	Added URL-mode elicitation and sampling with tools; introduced Tasks as an experimental core feature for durable requests and deferred retrieval.
EMA stable, June 18, 2026	An optional authorization extension, not a replacement protocol revision.	The enterprise IdP becomes the policy decision point; the client obtains an ID-JAG and exchanges it for an access token at the MCP authorization server. The extension supports centralized policy, SSO, and revocation.	Evaluate when corporate access must be governed centrally rather than authorized server by server. Client support varies and the extension is never active by default.
2026-07-28	Stateless per-request lifecycle; no initialize handshake, protocol session, GET stream, or SSE replay. Adds server/discover, MRTR, subscriptions/listen, and modern/legacy compatibility rules.	Adds issuer-response validation, issuer-bound client credentials, correct DCR application_type, and formal DCR deprecation in favor of CIMD. EMA remains an optional extension.	Requires routing headers and cache hints; formalizes extensions; moves redesigned Tasks to io.modelcontextprotocol/tasks; deprecates Roots, Sampling, Logging, and formally registers HTTP+SSE as Deprecated.

Sources for every row are listed under Sources below; the claim-level fact-check ledger records the exact locator for each normative statement.

Primary-source ledger: official sources and what each one establishes
Source	Date / revision	What it proves
2024 overview, lifecycle and transport pages	2024-11-05	Stateful lifecycle, initialization, stdio, HTTP+SSE, no core authorization
Introducing MCP	2024-11-25	Public announcement and original scope
2025-03-26 changelog, transport and authorization pages	2025-03-26	Streamable HTTP, sessions/resumption, OAuth framework, annotations, batching
2025-06-18 changelog and transport	2025-06-18	No batching, structured output, elicitation, OAuth resource-server changes, version header
2025-11-25 changelog and release article	2025-11-25	OIDC discovery, scopes, CIMD, URL elicitation, sampling tools, experimental Tasks
EMA release article and extension documentation	2026-06-18	Stable status, centralized IdP model, ID-JAG flow, opt-in requirements
2026 specification, changelog and release article	2026-07-28	Stateless core and consolidated release changes
Versioning and discovery pages	2026-07-28	Modern/legacy eras, per-request negotiation, server/discover, compatibility matrix
Streamable HTTP and caching pages	2026-07-28	POST/SSE model, headers, no resumption, cache fields and semantics
Authorization page	2026-07-28	Discovery, resource indicators, issuer validation, CIMD/DCR posture, bearer-token rules
Deprecated registry and lifecycle policy	Current on 2026-08-10	Deprecated features, replacements, earliest-removal rules
Tasks extension overview	Current on 2026-08-10	Official extension lifecycle and opt-in behavior
A2A v1.0 announcement and change guide	v1.0	Narrow MCP/A2A layer comparison

Direct links for every row appear in the Sources section below.

The architecture shift: session-era MCP to self-contained requests

In the 2024 and 2025 revisions, a client first negotiated a version and capabilities through initialize. A Streamable HTTP server could then issue Mcp-Session-Id; the client had to return that header on later requests. SSE event IDs and Last-Event-ID could be used to replay events after a broken connection. These mechanics made the transport capable of stateful sessions and resumable streams.

The 2026-07-28 specification defines “modern” implementations as those that convey version and capabilities per request, with client identity also recommended per request; 2025-11-25 and earlier are “legacy.” There is no negotiation handshake. A modern request declares its version in _meta, and HTTP mirrors that value in MCP-Protocol-Version. An unsupported version produces UnsupportedProtocolVersionError with the versions the server supports. A client may call the required server/discover RPC first, or attempt its preferred operation and retry with a mutually supported version.

Streamable HTTP still permits SSE, but only as a response scoped to a request or as the response to subscriptions/listen. That is different from the legacy HTTP+SSE transport and from the removed general GET stream. The current binding uses one MCP POST endpoint; a server may answer a request with a JSON object or a request-scoped SSE stream.

Routing: any modern request should be serviceable without hidden protocol-session affinity. HTTP intermediaries can inspect Mcp-Method and, for tools/call, resources/read, and prompts/get, Mcp-Name. Servers must reject metadata/header disagreement.
Application state: if later calls depend on earlier work, make the dependency explicit with an application handle. Define its ownership, authorization scope, expiration, replay behavior, and deletion policy as you would for any business object.
Recovery: do not resume a broken modern response stream. Treat the request as lost, generate a new request ID, and apply application-level idempotency where duplicate business action would be unsafe. The new-ID requirement is normative; the idempotency control is an implementation recommendation.
Interactivity: convert open-stream, server-initiated requests to MRTR. Persist or cryptographically protect any requestState, validate the returned inputResponses, and ensure a retry cannot bypass the authorization or approval context of the original operation.

Authorization, EMA, routing, caching, and extensions

Authorization is optional at the MCP protocol level, but an HTTP implementation that supports it should follow the authorization specification. The current flow treats the protected MCP server as an OAuth resource server. Clients must use Protected Resource Metadata for authorization-server discovery, support OAuth Authorization Server Metadata and OpenID Connect Discovery, include the RFC 8707 resource parameter in authorization and token requests, and send the bearer token in every HTTP request—not in a query string.

For new client registration, the specification prefers CIMD or pre-registration. DCR remains for backward compatibility but is Deprecated. When an authorization response contains iss, the client must compare it to the recorded issuer before sending the code to a token endpoint. Persisted credentials must also be keyed to their issuer and must not be reused across authorization servers. These checks belong in a shared authorization component, not in individual tools.

EMA is a separate, opt-in extension for organizations that want the IdP to control MCP server access. Its documented flow uses an Identity Assertion JWT Authorization Grant (ID-JAG), group/role-aware policy, and centralized revocation. Adopting EMA therefore requires compatibility across the client, enterprise IdP, MCP authorization server, and policy model; enabling it on one component alone is insufficient.

The modern protocol also exposes safer infrastructure seams. Complete (resultType: "complete") results from server/discover, tools/list, prompts/list, resources/list, resources/templates/list, and resources/read must include ttlMs and cacheScope. Interim input_required results and results produced by MRTR retries carrying inputResponses or requestState must not be cached. A private result must not be treated as a cross-user catalog, and TTL is a freshness hint rather than a guarantee. Servers should return tools deterministically to improve client and prompt-cache stability.

Optional capabilities now have a formal extension namespace and negotiation mechanism. Tasks moved from the experimental 2025 core into io.modelcontextprotocol/tasks; the redesign uses task handles plus tasks/get, tasks/update, and tasks/cancel. Both sides must declare extension support or use documented fallback behavior.

Migration checklist 1: establish the compatibility envelope

Record every client, server, gateway, SDK, transport, protocol revision, extension, and authorization server in scope.
Decide whether each component will be modern-only, legacy-only, or dual-era. A modern-only client does not automatically work with a legacy server, and a legacy client has no fall-forward path to a modern-only server.
For dual-era stdio clients, probe with server/discover; for HTTP, use the documented modern-request/error-body detection before falling back.

Migration checklist 2: separate the modern lifecycle path

Remove initialize, notifications/initialized, and Mcp-Session-Id from modern requests.
Put protocol version and client capabilities in the required per-request _meta; include client identity where recommended.
Implement server/discover on every modern server and return supportedVersions and capabilities; include server identity in result _meta as recommended by the specification.
Return or handle UnsupportedProtocolVersionError; never silently reinterpret an unsupported modern version.

Migration checklist 3: rework transport, recovery, and notifications

Expose one POST-capable MCP endpoint for modern Streamable HTTP.
Accept both JSON and request-scoped SSE responses on the client.
Remove GET-stream and Last-Event-ID logic from the modern path. After a broken stream, retry as a new request with a new ID.
Move long-lived change notifications to subscriptions/listen; keep request-scoped progress and message notifications on their originating response stream.
Validate Origin; reject an invalid present Origin with HTTP 403. Bind local servers to localhost where applicable.

Migration checklist 4: make state and interactive work explicit

Replace hidden session state with scoped application handles passed as tool arguments.
Define idempotency keys or business deduplication for mutating calls that may be retried.
Replace server-initiated elicitation, sampling, and roots requests with MRTR input_required results and retry handling.
Migrate 2025 experimental Tasks integrations to the official Tasks extension lifecycle.

Migration checklist 5: update the gateway and cache contract

Derive MCP-Protocol-Version, Mcp-Method, and applicable Mcp-Name values from the request body, and reject missing or mismatched required headers before routing, authorization, or execution.
Intermediaries that enforce policy on mirrored headers should first verify that the declared protocol version requires header/body validation; otherwise they should reject the request rather than trust unvalidated header values.
Add ttlMs and cacheScope to complete results from the six cacheable operations; never cache input_required results or MRTR retries, and partition private data by authorization context.
Make list ordering deterministic and test cache invalidation alongside listChanged notifications.

Migration checklist 6: harden authorization

Verify that MCP servers publish Protected Resource Metadata, authorization servers expose at least one of RFC 8414 Authorization Server Metadata or OpenID Connect Discovery, and MCP clients support both discovery mechanisms; also test PKCE behavior, token audience validation, and the RFC 8707 resource parameter.
Store the expected issuer with the authorization transaction; validate a present RFC 9207 iss before code redemption.
Partition persisted client credentials by issuer and reject cross-issuer reuse.
Prefer CIMD or pre-registration for new deployments; retain DCR only where compatibility requires it and set the appropriate application_type.
Evaluate EMA only when client, IdP, authorization server, claim mapping, revocation, and audit ownership are all defined.

Migration checklist 7: test before changing the default

Build a matrix for modern↔modern, dual-era↔modern, dual-era↔legacy, and intended failure cases.
Test missing and mismatched routing headers, unsupported versions, invalid origins, issuer mismatch, wrong token audience, insufficient scope, public/private cache behavior, stream interruption, duplicate mutation, MRTR retry, and task cancellation.
Capture protocol version, method, tool/resource name, trace context, authorization decision, extension set, result type, and application handle in telemetry—subject to redaction and access policy.
Roll out by explicit compatibility cohort and keep the legacy path isolated so it can be removed without changing modern behavior.

Ecosystem implementation notice: Codex server mode

Ecosystem implementation notice, not an MCP specification revision. This item records a product command change published by OpenAI and does not modify any protocol-version claim in this tracker.

OpenAI's product release notes dated August 24, 2026 state that the codex mcp-server command is deprecated. Integrations should use the Codex app server instead, and Claude Code users should use OpenAI's official Codex plugin.

Distinguish codex mcp-server from codex mcp. The codex mcp command is used to configure external MCP servers for Codex, and this notice makes no deprecation claim about it.

Deprecation decisions to make now

The current lifecycle policy normally requires at least 12 months between deprecation and earliest removal. Core Maintainers may approve expedited removal when a feature presents an active security risk with no in-place mitigation, but the shortened window must still provide at least 90 days. An earliest-removal date marks eligibility, not a scheduled removal; actual removal is a later Core Maintainer decision.

Roots, Sampling, Logging, and DCR were deprecated in 2026-07-28; the registry lists the first revision released on or after July 28, 2027 as their normal earliest removal point. New implementations should use tool parameters/resource URIs/server configuration instead of Roots, direct model-provider integration instead of Sampling, and stderr or OpenTelemetry instead of protocol Logging.

HTTP+SSE is a transition case. It was already described as deprecated when Streamable HTTP replaced it in 2025-03-26; the 2026 registry reclassified it under the formal policy and currently lists “three months after SEP-2596 reaches Final” as its earliest removal. Do not infer a fresh 12-month window from July 2026 for this transport. Use the registry—not a generic rule—as the planning source.

MCP versus A2A v1.0

MCP and A2A address adjacent layers. The A2A project describes MCP as tool and context integration inside an agent, while A2A focuses on communication and coordination between agents. A2A v1.0 adds its own version negotiation, protocol bindings, multi-tenancy, signed Agent Cards, and polling/streaming/webhook result modes. Use MCP migration work to stabilize an agent’s tool boundary; evaluate A2A when independently deployed agents need to discover, delegate, and exchange task state across product or organizational boundaries.

Download the data

Machine-readable CSV files behind the tables above. Cite this page as the source.

56-claim fact-check ledger (CSV, v1) (CSV download)Claim-level ledger of every normative statement in this tracker, with article section, claim type, protocol revision or date, official source title and URL, source locator, source date, verification status, check date and notes.CSV · 56 rows

Methodology

This guide was checked on August 10, 2026.
Normative MCP claims were taken only from official, versioned specifications, the official MCP extension documentation, the MCP project blog, and the original official announcement.
Ecosystem implementation notices are labeled separately from specification claims and are sourced to the product maintainer that published them.
The revision label is a calendar date, not semantic versioning.
The first tracked specification is dated 2024-11-05, while MCP was publicly announced on November 25, 2024.
A2A v1.0 sources are used only where the boundary between tool integration and agent-to-agent coordination matters.

Limitations

The tracker does not measure market adoption, implementation prevalence, performance, security effectiveness, compliance, or migration duration.
It does not certify any SDK or vendor product.
Vendor commands and product integrations can change independently of the MCP specification, so verify the current product documentation before you rely on any command name.
Extension specifications and client support can evolve independently from the dated core revision, so confirm the extension support matrix and the migration notes for the exact SDK release you deploy.
“Should” and “must” in this article are paraphrases for planning; the linked specification remains authoritative.

Sources

OpenAI product release notes (opens in a new tab)OpenAI · 2026-08-24Cited for: Deprecation of the codex mcp-server command and migration to the Codex app server or the official Codex plugin for Claude Code.
Overview — Model Context Protocol (2024-11-05) (opens in a new tab)Model Context Protocol · 2024-11-05Cited for: Stateful base protocol and the absence of authorization from the 2024 core.
Lifecycle — Model Context Protocol (2024-11-05) (opens in a new tab)Model Context Protocol · 2024-11-05Cited for: The initialize and notifications/initialized handshake requirements.
Transports — Model Context Protocol (2024-11-05) (opens in a new tab)Model Context Protocol · 2024-11-05Cited for: stdio and HTTP+SSE as the 2024 standard transports.
Introducing the Model Context Protocol (opens in a new tab)Anthropic · 2024-11-25Cited for: The public announcement date and original scope.
Key Changes — Model Context Protocol (2025-03-26) (opens in a new tab)Model Context Protocol · 2025-03-26Cited for: Streamable HTTP replacing HTTP+SSE, tool annotations and JSON-RPC batching.
Transports — Model Context Protocol (2025-03-26) (opens in a new tab)Model Context Protocol · 2025-03-26Cited for: POST/GET endpoint behavior including 405 responses, Mcp-Session-Id, and Last-Event-ID resumability.
Authorization — Model Context Protocol (2025-03-26) (opens in a new tab)Model Context Protocol · 2025-03-26Cited for: The optional OAuth 2.1-based authorization framework for HTTP transports.
Key Changes — Model Context Protocol (2025-06-18) (opens in a new tab)Model Context Protocol · 2025-06-18Cited for: Batching removal, structured output, elicitation, resource-server classification, resource indicators and the version header.
Transports — Model Context Protocol (2025-06-18) (opens in a new tab)Model Context Protocol · 2025-06-18Cited for: MCP-Protocol-Version on subsequent HTTP requests and fallback behavior.
Key Changes — Model Context Protocol (2025-11-25) (opens in a new tab)Model Context Protocol · 2025-11-25Cited for: OIDC discovery, incremental scope consent, CIMD, URL-mode elicitation, sampling with tools, experimental Tasks and resumption clarifications.
One year of MCP (2025-11-25 release article) (opens in a new tab)Model Context Protocol blog · 2025-11-25Cited for: Release framing for the 2025-11-25 revision.
Enterprise-Managed Authorization: Zero-touch OAuth for MCP (opens in a new tab)Model Context Protocol blog · 2026-06-18Cited for: EMA stable status on June 18, 2026.
Enterprise-Managed Authorization — Model Context Protocol (opens in a new tab)Model Context Protocol · 2026-06-18Cited for: The IdP-as-policy-decision-point model, the ID-JAG exchange, and the opt-in/client-support caveats.
Specification — Model Context Protocol (2026-07-28) (opens in a new tab)Model Context Protocol · 2026-07-28Cited for: The stateless, self-contained request model of the current revision.
Key Changes — Model Context Protocol (2026-07-28) (opens in a new tab)Model Context Protocol · 2026-07-28Cited for: Session and handshake removal, MRTR, subscriptions/listen, new request ID after stream loss, DCR/application_type and issuer-bound credential changes, Tasks relocation and deterministic tool ordering.
2026-07-28 release article (opens in a new tab)Model Context Protocol blog · 2026-07-28Cited for: Consolidated release framing for the 2026 revision.
Versioning and Compatibility — Model Context Protocol (2026-07-28) (opens in a new tab)Model Context Protocol · 2026-07-28Cited for: Modern/legacy eras, per-request negotiation, UnsupportedProtocolVersionError, the compatibility matrix and extension negotiation.
Discovery — Model Context Protocol (2026-07-28) (opens in a new tab)Model Context Protocol · 2026-07-28Cited for: The server/discover requirement, optional client call, and the ttlMs/cacheScope result shape.
Streamable HTTP — Model Context Protocol (2026-07-28) (opens in a new tab)Model Context Protocol · 2026-07-28Cited for: The POST endpoint and request-scoped SSE model, required routing headers, header/body mismatch rejection, absence of GET streams and resumption, and Origin validation.
Caching — Model Context Protocol (2026-07-28) (opens in a new tab)Model Context Protocol · 2026-07-28Cited for: Cacheable result set, ttlMs and cacheScope semantics, and the prohibition on caching input_required and MRTR retry results.
Authorization — Model Context Protocol (2026-07-28) (opens in a new tab)Model Context Protocol · 2026-07-28Cited for: Discovery requirements, resource indicators, RFC 9207 issuer validation, CIMD/DCR posture, bearer-token rules and stdio credential guidance.
Deprecated Features — Model Context Protocol (2026-07-28) (opens in a new tab)Model Context Protocol · 2026-07-28Cited for: Deprecation of Roots, Sampling, Logging and DCR, their earliest-removal eligibility, and the HTTP+SSE transition row.
Feature Lifecycle and Deprecation Policy (opens in a new tab)Model Context ProtocolCited for: The normal 12-month deprecation window and the security exception with a 90-day floor.
Tasks extension overview (opens in a new tab)Model Context ProtocolCited for: The official Tasks extension lifecycle and opt-in behavior.
A2A Protocol Ships v1.0 (opens in a new tab)A2A ProtocolCited for: The official MCP/A2A layer comparison and A2A v1.0 enterprise features.
What's new in A2A v1.0 (opens in a new tab)A2A ProtocolCited for: A2A v1.0 version negotiation, bindings and result modes.

Frequently asked

What is the current MCP specification as of August 10, 2026?: The current dated core revision is 2026-07-28. It defines stateless, self-contained requests and per-request capability negotiation.
Does MCP 2026 prohibit stateful applications?: No. It removes protocol-level sessions. A server can preserve business state by returning an explicit handle that the client passes in later tool calls.
Is SSE removed from MCP?: No. The general GET stream and replay mechanism are removed, but a Streamable HTTP response can still be SSE when scoped to one request, and subscriptions/listen uses a long-lived response stream for opted-in notifications.
Can a modern client talk to a legacy server automatically?: Only if the implementation includes the documented dual-era detection and fallback behavior. A modern-only client and legacy-only server do not inherently interoperate.
Is authorization required for every MCP server?: Authorization is optional in the core protocol. When authorization is supported over HTTP, implementations should conform to the MCP authorization specification; stdio implementations should obtain credentials from the environment instead of using that HTTP flow.
Should a new enterprise deployment use DCR?: Prefer CIMD or pre-registration. DCR remains available for backward compatibility but is Deprecated in 2026-07-28.
When should an architecture use A2A as well as MCP?: Use MCP for an agent’s tools and context. Add A2A when separate agents need standards-based discovery, delegation, and task exchange across system boundaries.

Need an independent MCP architecture review?

Start with MCP tool integrations (/services/mcp-tool-integrations) or bring one tool surface to a 20-minute Workflow Triage (/ai-workflow-assessment). We can map clients, servers, gateways, identity, compatibility requirements and conformance tests into a migration backlog tied to one governed workflow.

Book a 20-minute Workflow Triage

← Back to the research library