MCP, APIs and A2A: where each belongs in an agent system

They are not three model types, and choosing one does not automatically eliminate the others. A system may call an existing business API directly, expose a selected part of it through MCP, and use A2A for a separately operated specialist agent. It may also need only the first option.

Consider an illustrative equipment service assistant. A customer asks for help with a machine. The assistant needs to read the purchase record, check an approved service policy and prepare a request for a specialist service partner. The customer-facing product remains responsible for showing the status and explaining what happens next.

There are three different questions here. How does the software retrieve an order? How does the AI application discover the tools and knowledge it can use? How does it give a bounded job to another agent and understand the result? Treating all three as “connect the AI” hides important decisions.

The images in this article use ordinary information packages as a visual analogy: a request form, a tool catalogue and a work-order file. They are not diagrams of a specific vendor implementation. The actual interface needs explicit data structures and tested behavior.

An order API might accept an order identifier and return the purchase details the caller is allowed to see. A service API might create a draft case and return its identifier. The application must understand required fields, authentication, errors and whether an operation changes state.

For HTTP APIs, the OpenAPI Specification provides a standard way to describe an interface. That description can support documentation and tooling. It does not itself implement the business operation, grant access or prove that a caller used the correct customer record.

Direct API integration can be sufficient when your application knows exactly which operation to call and controls the surrounding logic. There is no requirement to wrap a stable, narrow integration in another protocol just because a model participates elsewhere in the workflow.

The MCP architecture documentation describes hosts, clients and servers, with server capabilities including tools, resources and prompts. The protocol defines the exchange; it does not decide the application's business policy or how the model should reason.

In the service example, an MCP server could expose a narrowly defined purchase lookup and approved policy resources. Its implementation may call existing APIs behind the scenes. The AI application can discover the exposed capabilities through the protocol rather than requiring a different discovery format for every integration.

The design work is in deciding what to expose. A tool called “update anything” with a large free-form payload is difficult to constrain and evaluate. A tool for preparing a draft service case can have a clear input contract, limited permissions and a result that distinguishes created, rejected and uncertain outcomes.

MCP does not make the connected system trustworthy merely because the connection succeeds. Tool descriptions and returned documents still need an appropriate trust boundary. Access to a tool catalogue also does not mean the current user is authorized to perform every operation listed in it.

The A2A overview describes communication between agents, capability discovery and exchanges that can include ongoing task updates. This is relevant when a separately operated agent carries out a defined piece of work and returns its result, rather than exposing only a simple lookup.

For the service partner, the delegated task could be to assess whether a specialist inspection is feasible from the provided information. The partner's agent may ask for missing details, continue its assessment and return a report. Your product needs to relate those responses to the original request and show when the assessment is incomplete.

A2A is not a replacement for the service partner's operating agreement. Decide what information may be shared, what the report means and whether any appointment has actually been reserved. A remote agent saying “ready” is not enough to infer that a customer has a confirmed booking.

These boundaries can overlap. An agent can be presented as a tool, and protocol capabilities evolve, including support for longer-running work. Choose based on the contract and lifecycle you need, not a rule that one acronym is exclusively for short tasks and another for long tasks.

Give the service request a stable business identifier. Keep it distinct from a transport request ID or a remote agent's task ID, and store the relationship. This lets an operator answer which customer request a delayed result belongs to.

Pass the input version with the work. If the customer changes the machine model while a specialist is assessing the previous one, the old report should not silently become the answer to the new request. Decide whether to cancel, restart or ask for confirmation, and keep the earlier result for appropriate traceability.

Treat a timeout as an unknown outcome until the relevant operation is checked. An API, MCP tool or remote agent can complete its work even if your application misses the response. Retrying a read differs from repeating a case creation or booking. The wrapper protocol does not remove that distinction.

Keep credentials on the trusted application side and scope access to the actual user and job. Do not let a document supply a new destination for confidential results without checking it against the intended workflow. A link returned by another system is data to validate, not an automatic grant of authority.

Inventory the systems and interfaces you already have. If one known API supplies the required order data, use it directly unless another interface solves a concrete distribution or maintenance problem. Consider MCP when exposing reusable capabilities to compatible AI applications. Consider A2A when a separate agent needs a shared task interaction contract.

Test the versions and optional capabilities that both sides actually support. A protocol name on a product page is not enough to establish interoperability. Exercise discovery, authentication, partial results, failure, cancellation and access revocation in the integration you will operate.

Read business data ownership before allowing multiple systems to update the same records, and agent permissions and approvals before enabling actions that affect customers.

Talvyn Labs can connect your AI product to business systems with interfaces that match the work. Bring the systems, available APIs and the task you want an agent to perform. We can select the necessary boundaries, build the integration and make its status and permissions understandable to the team operating it.