Blog · · 12 min read

MCP vs A2A vs Direct API: Choosing the Right Agent Boundary

MCP vs A2A vs Direct API: Choosing the Right Agent Boundary

Teams building AI features into existing products frequently hit an architectural crossroads. They have existing internal APIs, and they want to expose those capabilities to language models. However, they do not know what should stay internal, become a Model Context Protocol (MCP) tool, or cross an Agent-to-Agent (A2A) boundary. The default approach is often to wrap every endpoint in a direct API function call, which quickly creates a tightly coupled, brittle integration.

Choosing the right boundary determines how much custom orchestration you have to build, how securely you can isolate tenant data, and how easily you can swap models or agents in the future.

This guide provides a worked product architecture. We will define the failure modes of each approach and explain when to use direct APIs, when to adopt MCP, and when autonomous cross-system delegation justifies the A2A protocol.

The problem with defaulting to direct function calling

Direct API function calling remains the baseline integration method [1]. A platform engineer exposes an existing REST or GraphQL endpoint, provides a JSON Schema description, and passes it directly to the model.

The problem with this approach is that it forces the application tier to handle all the complexity of tool coordination. When a product team exposes dozens of endpoints, the model prompt becomes bloated with schemas. The application code must intercept every call, enforce domain invariants, manage authorization, handle retries, and translate product-specific errors into model-friendly feedback. As the Anthropic engineering team notes, while integrating tools is powerful, unnecessary abstraction or poorly scoped tools can degrade performance [2].

If you use direct function calling for everything, you end up rebuilding protocol-level concerns like discovery and session management from scratch.

Defining the three integration boundaries

To choose the right approach, platform engineers must separate internal domain logic from reusable context and autonomous delegation.

Direct API function calling: internal domain invariants

Direct APIs are best suited for narrow, product-specific actions where the application must tightly control the execution context. These are operations that require synchronous validation, immediate product-state updates, or strict transactional integrity.

When you use direct function calling, the integration boundary is the model itself. The application maintains full control over the execution loop. It decides when to invoke the model, what schemas to provide, and how to handle the response.

Use direct APIs when:

  • The tool interacts deeply with internal product state.
  • The action requires synchronous, transaction-safe execution.
  • The application needs to enforce strict domain invariants before the model sees the result.

Model Context Protocol (MCP): reusable tools and context

Model Context Protocol (MCP) defines an open standard connecting AI applications to external data, tools, and workflows [3]. It creates a standard client-server boundary. Instead of hardcoding schemas into the application, the application acts as an MCP client and connects to one or more MCP servers.

MCP is the right boundary when you need to decouple the tool implementation from the agent application. An MCP server handles discovery, resource exposure, and tool execution. It allows you to expose reusable capabilities like reading a filesystem, querying a database, or accessing a third-party SaaS without rebuilding the integration for every new agent.

Use MCP when:

  • You want to expose a reusable tool or context source to multiple agents.
  • You need to isolate the tool execution environment from the core application for security or dependency reasons.
  • You want to leverage community-built servers for standard resources.

Agent-to-Agent (A2A) Protocol: autonomous cross-system delegation

The Agent-to-Agent (A2A) Protocol defines discovery, long-running task state, authentication, authorization, idempotency, and approval states for agent-to-agent work [4].

Unlike MCP, which exposes tools to an agent, A2A coordinates independent, long-running agents. It provides a standard for asynchronous delegation. When Agent A delegates a task to Agent B, Agent A does not need to know how Agent B accomplishes the task. It only needs to know how to track progress, handle approval requests, and receive the final result.

Use A2A when:

  • An agent needs to delegate an autonomous, long-running task to another agent.
  • The delegated task crosses trust boundaries or organizational domains.
  • The interaction requires standardized pause, resume, and approval states.

A worked product architecture

Consider an existing customer support platform. The platform wants to deploy an AI agent that can read support tickets, query a customer database, and issue refunds.

If the team uses direct function calling for everything, the agent application must securely hold database credentials, manage the refund transaction, and handle pagination for the ticketing system. This mixes infrastructure, product logic, and AI orchestration in a single monolith.

Instead, the team should apply boundaries based on capability and risk.

Step 1: Wrap internal data with MCP

The ticketing system and customer database should be exposed via an MCP server. The agent acts as an MCP client. The MCP server handles connection pooling, data retrieval, and pagination.

This boundary allows the team to swap the agent framework without rewriting the data integrations. It also enforces a clean security boundary: the MCP server can run in a restricted environment, and the agent only sees the standardized MCP protocol.

Step 2: Enforce domain invariants with direct APIs

Issuing a refund is a high-risk, transaction-safe operation. It should not be a generic MCP tool. Instead, the application should expose a narrow, direct API function call specifically for initiating a refund.

When the model calls the refund tool, the application code intercepts the call. The application enforces domain invariants: checking the user's authorization, verifying the refund limit, and recording the audit trail. The application manages the transaction and returns a strict success or failure schema to the model.

Step 3: Delegate specialized tasks via A2A

Suppose the support agent needs to escalate a complex bug to the engineering team's specialized triage agent. This is an asynchronous, cross-system delegation.

The support agent uses the A2A protocol to send the task to the engineering agent. The support agent monitors the task state using A2A's standardized tracking. If the engineering agent requires human approval to proceed, it pauses its execution and surfaces the request through the A2A protocol. The support agent does not need to understand the engineering agent's internal tools; it only needs to understand the A2A state machine.

Managing authentication, state, and tenancy

Each boundary handles authentication and state differently.

For direct APIs, authentication is usually handled implicitly by the application context. The application knows the current tenant and user, and it scopes the function execution accordingly.

For MCP, the protocol supports connection-level authentication, but the server must still enforce tenant isolation. If a multi-tenant SaaS uses MCP, the client must pass the tenant context, and the server must apply row-level security or tenant-scoped credentials before retrieving data.

For A2A, authentication and authorization are built into the protocol. A2A defines how agents verify each other's identity and prove authorization to perform a delegated task. Task state is managed explicitly by the protocol, allowing long-running operations to survive process restarts.

When not to introduce a protocol

Do not introduce an external protocol if a simple synchronous function call suffices. If the tool is only used by one agent, deeply tied to internal application state, and executes synchronously, wrapping it in MCP adds unnecessary network overhead and latency.

Similarly, do not use A2A for simple data retrieval. A2A is designed for autonomous delegation and long-running state. Using it to fetch a user profile is an anti-pattern. Use MCP or a direct API for synchronous data access.

Verification and next steps

To implement these boundaries in your existing product:

  1. Audit your existing endpoints and categorize them as data retrieval, generic tools, or product-specific transactions.
  2. Implement an MCP server for your generic data retrieval and isolated tools.
  3. Keep high-risk transactions as direct API function calls within your application orchestration loop.
  4. If you have independent agents that need to coordinate asynchronously, evaluate the A2A protocol for standardization.

By choosing the right integration boundary, you can build an architecture that is secure, decoupled, and ready to scale.

To further explore these integration boundaries, it is helpful to look at how different layers of the software stack interact. A direct API approach means that the application developer must explicitly wire the model to the specific endpoint. This tight coupling means that any change in the API schema requires a corresponding change in the model's prompt and the orchestration logic. While this provides maximum control, it significantly increases the maintenance burden over time. When your application scales and the number of tools grows, managing these direct connections becomes complex and error-prone. The orchestration logic must handle all the edge cases, timeouts, and specific error codes for every single endpoint. This is why many teams start looking for abstractions.

When you introduce the Model Context Protocol, you shift this burden away from the core application. The MCP server acts as an intermediary, abstracting the specific implementation details of the underlying data source or tool. The agent application simply speaks the MCP protocol, asking the server to list its available resources and tools. This standardized discovery mechanism allows agents to dynamically adapt to available capabilities. For example, if a new reporting tool is added to the MCP server, the agent can discover it and use it without requiring a code change in the agent application itself. This decoupling is crucial for building resilient, extensible systems. However, this flexibility comes with the overhead of managing the MCP server infrastructure. You must ensure the server is highly available, secure, and performant.

The Agent-to-Agent protocol takes this abstraction a step further. While MCP focuses on exposing tools to a single agent, A2A focuses on orchestrating multiple, independent agents. In a complex enterprise environment, you rarely have a single monolithic agent that handles everything. Instead, you have specialized agents, a support agent, a billing agent, an engineering agent. These agents need to coordinate to solve complex user problems. A2A provides the necessary framework for this coordination. It defines how agents discover each other, how they authenticate, and how they delegate tasks. Most importantly, A2A provides a standardized mechanism for tracking the state of long-running tasks. This is essential for operations that may take hours or days to complete, and which may require human intervention or approval along the way.

Security and authorization also differ significantly across these boundaries. In a direct API integration, security is typically handled by the application's existing session management. The application already knows who the user is and what they are allowed to do. When the agent attempts to call a tool, the application simply applies its standard authorization checks. This is straightforward but tightly couples the agent to the application's security model.

With MCP, security must be managed at the protocol level. The MCP server must authenticate the client (the agent application) and authorize the specific operations it requests. This often involves passing tenant context or user tokens through the protocol. The server must then enforce row-level security and access controls based on this context. This requires careful design to ensure that a compromised agent cannot access unauthorized data or tools.

A2A introduces even more complex security challenges. When an agent delegates a task to another agent, it must prove its identity and authorization. A2A defines mechanisms for this mutual authentication and authorization, ensuring that agents can only delegate tasks they are permitted to initiate. Furthermore, the protocol must handle the passing of credentials or access tokens securely, ensuring they are not intercepted or misused.

The operational characteristics of these boundaries also vary. Direct API calls are generally fast and synchronous, making them suitable for low-latency operations. MCP introduces a network hop, which adds latency and potential failure points. You must monitor the performance of your MCP servers and ensure they are scaled appropriately. A2A operations are typically asynchronous and long-running. You need robust observability and tracking to understand the progress of these delegated tasks and to identify bottlenecks or failures.

Choosing the right boundary requires a deep understanding of your specific use case, your existing infrastructure, and your long-term goals. There is no single correct answer. Most complex applications will use a combination of all three approaches: direct APIs for synchronous, high-risk operations; MCP for reusable tools and data access; and A2A for asynchronous delegation between specialized agents. By carefully evaluating the trade-offs and selecting the appropriate boundary for each capability, you can build an agentic architecture that is scalable, secure, and maintainable.

As the ecosystem evolves, we expect to see further standardization and tooling around these boundaries. New protocols may emerge, and existing protocols will mature. However, the fundamental principles of decoupling, abstraction, and separation of concerns will remain relevant. By understanding the different ways agents can interact with the world, you can design systems that are resilient to change and capable of tackling increasingly complex problems. The key is to avoid defaulting to the simplest approach (direct APIs) when a more robust abstraction (MCP or A2A) is warranted, and conversely, avoiding over-engineering when a simple API call is sufficient.

For developers, understanding the distinction between a function call, an MCP tool invocation, and an A2A delegation is as important as understanding the distinction between a local function call, a REST API request, and an asynchronous message queue. It is a fundamental architectural decision that shapes the entire system.

Therefore, when designing your next agentic feature, take the time to map out your integration boundaries. Identify the data sources, the specific product actions, and the external systems your agent needs to interact with. Evaluate each interaction against the criteria outlined in this guide. Ask yourself: does this need to be a direct API? Can it be abstracted as an MCP tool? Does it require autonomous delegation via A2A? By systematically applying these principles, you will build a stronger, more adaptable AI integration.

The choice of boundary also impacts how you evaluate and test your system. Testing a direct API integration involves standard unit and integration testing techniques. You mock the API endpoint and verify that the agent generates the correct function call payload. Testing an MCP integration requires verifying the client-server interaction. You must ensure the agent correctly discovers resources, formats tool requests, and handles the server's responses. Testing A2A interactions is the most complex, as it involves verifying asynchronous communication, state transitions, and coordination between independent systems. You need end-to-end integration tests that simulate the entire lifecycle of a delegated task, including potential failures and edge cases.

In summary, the transition from simple chatbots to autonomous agents requires a sophisticated approach to integration architecture. Direct APIs, MCP, and A2A offer distinct capabilities and trade-offs. By mastering these boundaries, platform engineers can navigate the complexities of agent integration and build systems that deliver real value to users while maintaining security, scalability, and maintainability.

References

Be first in line.

Join the waitlist and we'll email you the moment it's ready. No sales call.

Try the demo →
or talk to us