MCP and A2A: what must survive a change of provider

Replacing a connection

A successful search can change what “there is no policy” means

Suppose an AI application switches its internal-document search role to a new provider. The same question can be sent, and a response comes back. Yet the new role may report “not found” because the user cannot read the policy, rather than because the policy does not exist. This is a hypothetical example for examining a replacement. For the user, the important question is whether the searched scope can be trusted.

Announcements and specifications for A2A, MCP, and OpenAPI make ways of connecting to other participants and tools more concrete. In June, A2A was donated to the Linux Foundation, and a walkthrough connected MCP Toolbox to an IDE and a database. More material is available for using shared connection formats to design work across products.

This article argues that freedom to replace a connection depends on preserving the conditions under which a user interprets its results. An answer with sources differs from prose alone; an empty search differs from a failed search. Starting with common formats, we need to compare meaning, permissions, and the treatment of failure.

What the formats share

Delegating a task, calling a tool, and describing an API do different jobs

The A2A announcement describes discovering another agent’s capabilities and exchanging tasks, progress, and artifacts. MCP connects AI applications to tools and data. OpenAPI 3.1.1 defines a format for describing HTTP API inputs, responses, authentication, and related details. Each standardizes a different part of a connection.

Our search example could call a document-search tool, or delegate research to another participant and wait for an artifact. Either could use a business API described with OpenAPI internally. Listing the three names does not determine which documents will be searched or what counts as completion. The work expected of the connected participant must be defined first.

The June 23 A2A donation describes moving the specification, SDKs, and developer tooling into an independent project. A framework through which multiple companies can develop and maintain a standard matters for long-lived connections. Neutral governance, however, does not establish that providers produce equivalent search results or business judgments.

A tool enters the work

A database connection can extend from searching to changing code

Google Cloud’s June 4 MCP Toolbox walkthrough follows Sara, a new developer, connecting from Cline in VS Code to a development database on Cloud SQL for PostgreSQL. She explores tables and open orders, adds a vendors table and vendor IDs to inventory, then updates application models and InventoryDAO tests. A connection used to read the database structure becomes part of work that changes and verifies code.

The material describes this flow and says it finishes quickly, but it does not report a controlled comparison of people and AI on the same task. The useful mechanism is access to actual data structures and a concrete scope of changes. A tool that reads tables and one that changes them require different permissions and different checks after failure.

When replacing the connection, seeing the same tool names is insufficient. Does it target the same development database? Does it allow the same reads and writes? Do the code and tests remain consistent after the changes? A common connection format makes such comparisons easier to begin. It does not make them unnecessary.

Output structure and meaning

The same fields can carry different facts

The June 18 MCP tools specification covers structured results and outputSchema, which describes their format. When a schema is supplied, the server must return structured results that conform to it, and clients should validate them. Its weather example describes a numeric temperature and specifies Celsius. This gives the receiving program information with which to check the format.

For document search, an application could define fields for prose, source URL, document version, and searched scope. These are this article’s proposed design, not fields MCP requires for every search. Results from old document versions and results from current versions can have identical fields while supporting different conclusions. Structural agreement and agreement in business meaning need separate checks.

OpenAPI descriptions can also express business meaning through explanations of responses and their fields. Merely using the same specification version does not show that two providers adopt the same definitions. A replacement needs comparison of both the code that passes values to the screen and the conclusions drawn from those values.

Whose permissions apply

A shared connection method does not automatically preserve what a user can read

The June 18 MCP authorization specification defines an authorization flow for HTTP connections. Authorization itself is optional; the same OAuth mechanism is not mandatory for every MCP implementation. Connections through standard input and output instead use credentials obtained from the environment. The connection method changes which conditions need checking.

The HTTP authorization specification requires a server to verify that an access token was issued for that server. Switching providers therefore cannot simply mean reusing a token issued for the previous destination. The destination must match the intended authorization target, and the application must check which documents that user can read. A shared format does not grant identical permissions at every destination.

The specification distinguishes 401 responses for conditions such as invalid tokens from 403 responses for insufficient permissions. If the application turns both into an empty search result, the user cannot distinguish “not found” from “cannot read.” That difference needs to survive through to the screen so the person can understand what was actually searched.

Reading success and failure

Receiving a result does not establish that the search succeeded

The MCP tools specification distinguishes protocol errors from errors during tool execution. The latter use isError within the result to indicate problems such as API failures or business-processing errors. Even when a result arrives, its content may describe a failed tool. A client that reads only the response prose loses that distinction.

In the opening document-search example, no matching documents within the searched scope, insufficient permission to read a document, and a stopped search process deserve separate treatment. This is a proposed business distinction. Preserving it when passing results to the answer-writing role helps prevent an application from claiming “there is no policy” when the search did not run successfully.

With longer work, an elapsed waiting period may also leave the other participant’s task unfinished. A search may be safe to repeat, while work that changes external records can create duplicates if repeated without checking whether the earlier operation committed. Waiting and retry policies need to reflect whether the tool only reads or also makes changes.

Combining with managed services

Common connections can coexist with managed execution

The May Responses API update added connections to remote MCP servers. Foundry’s Developer Essentials announcement also describes A2A, MCP, and OpenAPI connections alongside managed agent execution. A managed runtime can offer shared connection methods.

This combination opens a path to using external tools and participants while delegating runtime management. The application still needs to test whether sources, readable scope, and failure distinctions survive a change of destination. A list of supported protocols helps select candidates; explaining the conditions for replacing a working role requires checking the features and versions actually used.

Deciding on a replacement

Use the same work to test what changes and what must survive

To evaluate a replacement search role, use the same documents, users, and questions. Include current and old document versions, readable and restricted documents, and questions with no matching document. Compare insufficient permissions, failed tools, and pending responses as well as normal results. Check whether users can interpret conclusions under the same conditions, rather than merely comparing the appearance of answers.

Where differences appear, separate conditions an adapter can preserve from conditions the provider cannot support. If a replacement returns no sources, formatting its prose afterward cannot recover them. The application must narrow the uses for which it claims equivalence, or choose a destination that returns the required information.

The value of interoperability depends on more than the number of connections. After a replacement, users should still be able to read search results with the same meaning and continue their decisions. Using common formats while defining the conditions that must survive a replacement makes future choices more practical.