How Function Calling, MCP and A2A Decouple Agents From Interfaces

Function calling, the Model Context Protocol (MCP), and the Agent-to-Agent (A2A) protocol together decouple AI agents from vendor-specific interfaces, enabling enterprise voice agents to act on backends and coordinate across ownership boundaries. MCP, introduced by Anthropic in November 2024 and donated to the Linux Foundation's Agentic AI Foundation, standardizes tool invocation over JSON-RPC 2.0 and has passed 97 million monthly SDK downloads, while A2A, introduced by Google in April 2025 and donated in June, models stateful task delegation with lifecycle states. The article argues that plain function calling remains suitable for deterministic capabilities, but MCP and A2A solve the N×M integration mess and cross-agent coordination, respectively.

Can a voice agent do anything, or only talk? It earns its keep when it checks an order status or books an appointment; the switch to action is function calling. That switch is where coupling starts: acting on a backend wires the agent to a vendor’s schema. Function calling, MCP and A2A do three different jobs. Together they turn your voice front end into a swappable client, within the multimodal interface revolution /ai-voice-agents-and-the-multimodal-interface-revolution . Why does function calling matter for enterprise voice agents? Function calling switches an agent from conversing to acting. The model emits a structured call, your runtime executes it, and the result returns. A survey of speech-to-speech models https://arxiv.org/html/2603.05413v1 found that none of the Level 1 or Level 2 models support function calling. Every provider has its own flavour: OpenAI function calling https://platform.openai.com/docs/guides/function-calling , Anthropic tool use https://docs.anthropic.com/en/docs/build-with-claude/tool-use , Google function declarations. That is the bespoke layer MCP later standardises. For one deterministic capability, plain function calling is still the right answer. HTTP-style calls don’t know whether they already ran https://blogs.oracle.com/developers/the-agent-communication-matrix-when-mcp-a2a-and-plain-rest-each-win , so retry logic stays in your team’s code. What is the Model Context Protocol MCP and what problem does it solve? MCP Model Context Protocol is an open standard Anthropic introduced in November 2024 and later handed to the Linux Foundation’s Agentic AI Foundation https://www.agenticaifoundation.org . It standardises how an agent discovers and invokes tools over JSON-RPC 2.0 https://www.jsonrpc.org/specification ; the spec lives at modelcontextprotocol.io https://modelcontextprotocol.io . It solves the N×M integration mess https://codilime.com/blog/model-context-protocol-explained/ : without a standard, every tool and model needs its own adapter. MCP replaces that with one typed contract any model can call, exposing Tools callable actions , Resources readable context , Prompts reusable templates and Sampling server-initiated model requests . An agent can list available tools and their JSON Schema https://json-schema.org at runtime. You don’t need to rip out your backend; a thin MCP server can wrap existing REST endpoints. OpenAI, Microsoft and AWS have adopted it, and it has passed 97 million monthly SDK downloads https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol . MCP covers one agent reaching tools. A voice agent handing work to another agent needs a different layer. What is the Agent-to-Agent A2A protocol and what problem does it solve? A2A Agent-to-Agent is the coordination layer. Google introduced it in April 2025 and donated it to the Linux Foundation https://www.digitalapplied.com/blog/google-a2a-protocol-agent-to-agent-communication-guide in June. Where MCP handles an atomic tool call, A2A models delegation as a stateful task with a lifecycle: working, input-required and completed, plus failure and cancellation. Discovery happens through a discoverable Agent Card, and the spec lives at a2a-protocol.org https://a2a-protocol.org . It standardises how agents discover, hand off and coordinate without exposing internal tools or memory. That matters when work crosses an ownership boundary you don’t own https://redis.io/blog/mcp-vs-a2a-which-protocol-do-you-need/ . The input-required state is where human approval gates sit. IBM’s Agent Communication Protocol has since merged in https://dev.to/pockit tools/mcp-vs-a2a-the-complete-guide-to-ai-agent-protocols-in-2026-30li , and 150+ organisations participate. MCP vs A2A: what is the difference, and do you actually need both? MCP connects an agent to tools and context https://www.stackone.com/blog/mcp-vs-a2a-protocol/ , while A2A connects an agent to other agents. MCP gives your agent hands, while A2A gives it colleagues. The working rule is MCP inside, A2A outside https://www.glukhov.org/ai-systems/mcp/a2a-vs-mcp-ai-agent-protocols/ . Use MCP when one agent must reach many tools behind a shared contract, and A2A when work crosses a boundary you don’t own. The deciding question is ownership: if you own the agents, you reach for tools; if the work crosses into someone else’s agents, you delegate. Both specs share JSON-RPC 2.0 and JSON Schema, but MCP treats interaction as atomic and A2A as stateful. Sometimes you need neither protocol. How do MCP and A2A decouple agents from interfaces? When you need both, here is what the separation buys you. Decoupling separates reasoning and action from the voice, chat or screen interface. MCP decouples agents from tools, so tools can be developed, versioned and deployed independently https://architecture.learning.sap.com/docs/ref-arch/76ec36 of the agents; A2A decouples agents from each other. The result is a headless agent https://gradient-labs.ai/blog/how-and-why-to-use-headless-ai-agents : the same logic serves a phone call, a chat window and a screen. AWS offers headless access to its DevOps Agent over MCP and A2A https://aws.amazon.com/about-aws/whats-new/2026/06/aws-devops-agent-custom-agents/ , and Salesforce treats Slack as one swappable surface https://architect.salesforce.com/docs/architect/fundamentals/guide/agentic-patterns.html on the same Agentforce agents. The stable layer is the agent’s memory and system of record. That separation also makes cloud versus self-hosted /cloud-versus-self-hosted-voice-ai-and-the-privacy-first-counter-current a practical choice. The trade-off: each protocol adds governance, security and observability surface. Which voice architecture pattern fits your use case: tool-driven, sub-agent or session segmentation? That decision shapes which pattern you build. Multi-agent voice systems fall into three patterns, and the choice follows your conversation’s shape. Tool-driven is the simplest: one agent with many tools. The model picks a tool, passes parameters and speaks the result back. It is the lowest-overhead option for narrow domains, but it gets brittle once calls need validation or chaining. Sub-agent, or agent-as-tool, wraps a specialist agent as a callable tool. The orchestrator delegates a whole task to an agent with its own model, prompt, tools and reasoning. Strands Agents and BidiAgent are reference examples https://aws.amazon.com/blogs/machine-learning/scalable-voice-agent-design-with-amazon-nova-sonic-multi-agent-tools-and-session-segmentation/ of the pattern. Session segmentation splits the conversation into phases, each with its own prompt and tool set, for long, multi-stage flows like onboarding or claims. The three patterns and their latency trade-offs show the details, and the choice feeds into the build versus buy decision /build-versus-buy-voice-agents-and-how-to-evaluate-both-paths . When should you use a sub-agent pattern instead of simple function calling? The hardest line is where a sub-agent ends and a plain function begins. Reach for a sub-agent when a capability needs its own reasoning, context and guardrails, not when you only need a new function. A CRM lookup is a function; a fraud specialist that weighs its own evidence is a sub-agent. If the capability carries its own state or rules that should not live in your main agent’s prompt, wrap it as an agent-as-tool. One clean test: if the ‘second agent’ is just a different prompt using the same model, it is a tool call. The reverse anti-pattern is turning every small capability into an agent. There is a cost either way: each sub-agent call adds inference time to the voice pipeline, and each protocol boundary adds monitoring and security work. Reserve sub-agents for boundaries where the reasoning is worth the round trip. Conclusion Function calling, MCP and A2A resolve into one stack. Function calling is the act, MCP is how one agent reaches tools and context, and A2A is how agents delegate to each other. Once those sit behind protocols, the voice interface becomes one swappable client among many. The pattern you choose follows the shape of your conversation, and the agent boundary is a reasoning boundary. That is the mental model to carry into the broader voice AI architecture and the build versus buy decision. Frequently Asked Questions Is MCP locked to Anthropic, or can I use it with other model providers? No. MCP is an open standard, not an Anthropic-only feature. Anthropic introduced it, but governance now sits with the Linux Foundation’s Agentic AI Foundation, and the protocol works with OpenAI, Microsoft, AWS and other providers. The whole point is a typed contract any model can call. Choosing MCP does not lock your voice agent to a single vendor’s tool schema. Do I need to replace my existing REST APIs to adopt MCP? No. You can wrap existing REST endpoints in a thin MCP server and expose them through Streamable HTTP, so your current backend stays intact. This migration path is why MCP is often described as a contract on top of your existing integration layer. You adopt the protocol gradually, endpoint by endpoint, rather than rewriting what already works. How is MCP different from OpenAPI? OpenAPI describes a REST API for humans and generated clients; MCP describes tools, resources and prompts for an agent. MCP adds capability discovery through tools/list and JSON Schema, so a model can find and call a tool without hand-written glue. It also supports server-initiated sampling, which OpenAPI does not. In short, OpenAPI documents an interface, while MCP gives an agent a working contract. Can I use plain function calling and MCP together in the same voice agent? Yes. These are not mutually exclusive. Native function calling is the right choice for one deterministic capability, while MCP earns its place when one agent must reach many tools behind a shared contract. A single agent can mix both: keep a simple lookup in native tool calling and route the broader tool estate through an MCP server. The deciding factor is overhead, not ideology. How do MCP and A2A handle security and governance? Both protocols add surface area you have to govern. With MCP, you control which tools an agent can discover and call, and you should apply authentication and authorisation at the server boundary. With A2A, delegation crosses ownership boundaries, so per-task approval gates matter, and the input-required state is where human sign-off happens. Neither protocol removes security work; they move it to explicit boundaries you can monitor and audit. Will adding MCP or A2A make my voice agent noticeably slower? Each layer adds a hop, so there is a small latency cost, but it is usually manageable in voice if you design for it. Run MCP servers close to your agent runtime and treat long-running A2A delegation as asynchronous rather than blocking the conversation. The pattern matters more than the protocol: a sub-agent call adds latency to the streaming pipeline, so reserve it for boundaries where the reasoning is worth the round trip. Can my voice agent delegate to another vendor’s agent through A2A? Yes, that is exactly what A2A is for. A2A standardises peer-to-peer coordination between independent agents, so your agent can discover another vendor’s agent through its Agent Card and delegate a task without exposing internal tools or memory. The handoff crosses an ownership boundary, which is the trigger for choosing A2A over MCP in the first place. What does a headless agent mean in practice? A headless agent has its reasoning, memory and tool access separated from any single interface. The same agent can serve a voice call, a chat window and a screen-based assistant because each surface is just a client over the protocol. AWS Kiro is the reference example: the agent logic stays constant while the voice, chat or screen front-end is swapped in and out. What exactly is an Agent Card? An Agent Card is a machine-readable description of an agent’s capabilities, served at /.well-known/agent.json . It tells other agents what the agent can do, how to authenticate and how to delegate a task. It plays the same discovery role for A2A that tools/list plays for MCP, and it is what lets two agents coordinate without any prior, hand-wired integration. How do I run an MCP server for a voice agent in production? You run an MCP server wherever your tools and context live, then connect the agent over stdio for local processes or SSE and Streamable HTTP for remote access. For a voice agent, a remote server near the agent runtime is the common shape, and self-hosting is a valid option when data must stay on your infrastructure. The key is treating the server as production infrastructure with its own auth, monitoring and versioning. Are MCP and A2A stable enough to build on today? Both are open, actively governed standards, not experimental vendor betas. MCP and A2A are under the Linux Foundation’s Agentic AI Foundation, and A2A draws on more than 150 participating organisations including IBM’s merged Agent Communication Protocol. They are still evolving, so pin your versions and design for change, but they carry enough ecosystem weight to be a defensible production bet.