Paper deep dive
A Comparative Study of MCP and A2A for Inter-Agent Coordination in LLM-Based Systems
Ionut Predoaia, Tuong Manh Vu, Konstantinos Barmpis, Dimitris Kolovos, Antonio García-Domínguez
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 87%
Last extracted: 7/28/2026, 3:16:50 AM
Summary
This paper presents an implementation-grounded comparative study of the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol for inter-agent coordination in LLM-based systems. Using a software engineering task involving domain model generation, the authors evaluate both protocols against requirements such as agent discoverability, multi-turn conversations, and observability. The results indicate that MCP offers a lightweight implementation with lower coordination complexity but requires explicit application-layer handling for state management, whereas A2A provides richer native support for stateful, multi-turn coordination through protocol-level abstractions, albeit with higher complexity.
Entities (9)
Relation Signals (7)
Agent2Agent Protocol → supports → stateful multi-turn coordination
confidence 95% · A2A provides richer native support for stateful, multi-turn coordination through protocol-level abstractions for tasks and lifecycle management
Model Context Protocol → designedfor → tool integration
confidence 90% · MCP was designed to streamline the connection of LLM-based applications to tools, data sources, and workflows
Agent2Agent Protocol → designedfor → inter-agent communication
confidence 90% · A2A was specifically designed to support inter-agent communication and collaboration across heterogeneous agents
Emfatic → partof → Eclipse Modelling Framework
confidence 90% · Emfatic textual language of the Eclipse Modelling Framework (EMF)
Model Context Protocol → supports → inter-agent coordination
confidence 90% · MCP can support inter-agent coordination in constrained LLM-based systems through a comparatively lightweight implementation model
Model Context Protocol → hascomplexity → lower coordination complexity
confidence 85% · MCP can support inter-agent coordination... with lower coordination complexity
Agent2Agent Protocol → hascomplexity → substantially greater implementation and coordination complexity
confidence 85% · A2A... comes with substantially greater implementation and coordination complexity
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Recent industry practice has seen the rapid emergence of agentic systems composed of heterogeneous, tool- and LLM-mediated agent components, raising practical questions about inter-agent coordination and protocol design. This paper presents an implementation-grounded comparison of the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol, from a multi-agent systems engineering perspective, using an inter-agent coordination scenario involving LLM-based agents. We evaluate an MCP-based and an A2A-based multi-agent implementation of the same software engineering task against a set of requirements derived from prior literature and discussions with industry partners, including agent discoverability, multi-part messaging, multi-turn conversations, asynchronous communication, observability, interoperability, and access control. The results evidence that MCP can support inter-agent coordination in constrained LLM-based systems through a comparatively lightweight implementation model with lower coordination complexity, although coordination concerns such as conversational state management and task lifecycle handling must be implemented explicitly at the application layer. In contrast, A2A provides richer native support for stateful, multi-turn coordination through protocol-level abstractions for tasks and lifecycle management, but this comes with substantially greater implementation and coordination complexity. Given the narrow scope of the evaluated coordination pattern, these findings are presented as design observations from an empirical experience report rather than general claims of protocol suitability or superiority across broader classes of MAS, highlighting trade-offs and how protocol abstractions shape the distribution of coordination responsibilities in contemporary agentic systems.
Tags
Links
- Source: https://arxiv.org/abs/2607.23884v1
- Canonical: https://arxiv.org/abs/2607.23884v1
Trouble viewing inline? Open PDF directly →
Full Text
51,494 characters extracted from source content.
Expand or collapse full text
11institutetext: University of York, York, United Kingdom 11email: ionut.predoaia, tuong.vu, konstantinos.barmpis, dimitris.kolovos, a.garcia-dominguez@york.ac.uk A Comparative Study of MCP and A2A for Inter-Agent Coordination in LLM-Based Systems Ionut Predoaia Tuong Manh Vu Konstantinos Barmpis Dimitris Kolovos Antonio García-Domínguez Abstract Recent industry practice has seen the rapid emergence of agentic systems composed of heterogeneous, tool- and LLM-mediated agent components, raising practical questions about inter-agent coordination and protocol design. This paper presents an implementation-grounded comparison of the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol, from a multi-agent systems engineering perspective, using an inter-agent coordination scenario involving LLM-based agents. We evaluate an MCP-based and an A2A-based multi-agent implementation of the same software engineering task against a set of requirements derived from prior literature and discussions with industry partners, including agent discoverability, multi-part messaging, multi-turn conversations, asynchronous communication, observability, interoperability, and access control. The results evidence that MCP can support inter-agent coordination in constrained LLM-based systems through a comparatively lightweight implementation model with lower coordination complexity, although coordination concerns such as conversational state management and task lifecycle handling must be implemented explicitly at the application layer. In contrast, A2A provides richer native support for stateful, multi-turn coordination through protocol-level abstractions for tasks and lifecycle management, but this comes with substantially greater implementation and coordination complexity. Given the narrow scope of the evaluated coordination pattern, these findings are presented as design observations from an empirical experience report rather than general claims of protocol suitability or superiority across broader classes of MAS, highlighting trade-offs and how protocol abstractions shape the distribution of coordination responsibilities in contemporary agentic systems. 1 Introduction Recent advances in large language models (LLMs) have led to the emergence of contemporary agentic systems in which multiple, specialised agent components collaborate to accomplish complex tasks. In the classical Multi-Agent Systems (MAS) literature, Wooldridge defines agents under the weak notion of agency as autonomous computational entities that are situated in an environment, perceive and act upon that environment, exhibit reactive and proactive behaviour in pursuit of their objectives, and are capable of interacting with other agents through explicit communication mechanisms [48]. This weak notion contrasts with stronger notions of agency, which assume rich internal mental states [39] or normative social semantics [41]. Nevertheless, in contemporary LLM-based practice, agents are often defined more pragmatically as LLM-enabled components that participate in multi-step task execution within a software system. This usage is closely related to the LangChain notion of agents [25] as LLM-driven components within an application, which frames agentic behaviour as a spectrum based on the extent to which an LLM determines system control flow. Inspired by the LangChain perspective on agentic systems, this paper adopts a pragmatic notion of agents as LLM-enabled components capable of executing multi-step tasks within a software system. The paper’s focus is on coordination patterns in contemporary agentic systems, where heterogeneous agents interact through tools, APIs, and communication protocols. Although these systems differ architecturally from many classical MAS settings, they raise related engineering concerns, including agent discoverability, interaction structure, and task lifecycle coordination. The paradigm of decomposing complex tasks into collaborations among multiple, specialised agents introduces substantial integration challenges, requiring careful consideration of communication protocols and interoperability standards. From 2024 onwards, there has been a significant industry push toward inter-agent collaboration, accompanied by the proposal of several agent communication protocols, with recent surveys comparing their relative strengths and weaknesses [49, 15]. Among these protocols, two have gained the most traction within the developer community, as reflected by GitHub activity (in terms of repository stars) and reported adoption: the Model Context Protocol (MCP) [42] and the Agent2Agent (A2A) protocol [29]. These two protocols differ fundamentally in their original design intent: MCP was designed to streamline the connection of LLM-based applications to tools, data sources, and workflows, whereas A2A was specifically designed to support inter-agent communication and collaboration across heterogeneous agents. Prior academic work comparing agent interoperability protocols characterises MCP and A2A as addressing different layers of agentic systems, with MCP primarily supporting structured access to tools and data sources, and A2A focusing on explicit agent-to-agent communication and task delegation [49, 15]. Several studies argue for a complementary use of MCP and A2A rather than treating them as competing alternatives [27, 28, 44, 20, 23, 24]. Application-oriented works that employ both protocols consistently follow this layered architecture across domains such as incident response, engineering design, digital twins, and automation [44, 20, 23, 18, 13, 19, 21]. Practitioners have explored the use of MCP beyond its original design scope, notably as an infrastructure for supporting coordination in agentic systems. This exploration is reflected in practitioner discussions, industry presentations [46, 11], and technical blog posts [4, 12], where MCP is often positioned as a unifying integration layer for orchestrating agent-based components. We treat these practitioner-oriented sources not as scientific evidence, but as indicators of emerging engineering practices in rapidly evolving LLM-based agentic systems. Collectively, they suggest a growing tendency to repurpose general-purpose integration protocols, such as MCP, to address coordination concerns beyond their original design scope. To the best of our knowledge, the existing literature has neither investigated the use of MCP for enabling inter-agent coordination nor provided an empirical comparison between MCP and A2A in this setting. This motivates the implementation-grounded comparative study presented in this paper. MCP is increasingly adopted as a standard mechanism for providing tool access to LLM-based systems, and practitioners may therefore already rely on MCP as part of their existing systems. In the context of LLM-based systems that already rely on MCP for tool integration, the introduction of multi-agent coordination raises a practical design question: whether MCP can be reused to support inter-agent communication, or whether a protocol explicitly designed for agent-to-agent communication, such as A2A, is required. This question has been actively debated in industry discussions, where MCP is often argued to already satisfy many practical requirements for coordinating agent-based components. The software engineering use case that we have selected for the comparison in this paper is intentionally narrow in scope and instantiates a minimal yet representative coordination pattern involving task delegation, iterative refinement with feedback, and validation. This coordination pattern recurs across many contemporary agentic systems (e.g., iterative cycles of planning, execution, and verification), making it suitable for protocol-level analysis. To study the practical use of MCP and A2A in this setting, we implement a multi-agent collaboration that solves a common software engineering task: given a natural language prompt, generate an object-oriented domain model. This paper contributes an implementation-grounded, empirical engineering study comparing MCP and A2A by applying both protocols to the same multi-agent coordination scenario. Our objective is to characterise how differing protocol abstractions shape the distribution of coordination responsibilities between protocol mechanisms and application-specific orchestration logic in a concrete collaboration pattern. Furthermore, we evaluate the MCP-based and the A2A-based implementations against a set of requirements derived from prior literature and discussions with industry partners, including agent discoverability, multi-part messaging, multi-turn conversations, asynchronous communication, observability, interoperability, and access control. This work is intended as an empirical experience report on applying emerging industry protocols in a concrete LLM-based MAS, rather than as a benchmark or performance evaluation. The results indicate that MCP can support inter-agent coordination in constrained LLM-based systems through a comparatively lightweight implementation model with lower coordination complexity, fewer protocol primitives, and reduced orchestration overhead, although key coordination concerns such as conversational state management and task lifecycle handling must be implemented explicitly at the application layer. In contrast, A2A provides richer native support for stateful, multi-turn coordination through protocol-level abstractions for tasks and lifecycle management, but this entails substantially greater implementation and coordination complexity. Given the narrow scope of the evaluated coordination pattern, these findings are intended as design observations rather than general claims of protocol suitability across broader classes of MAS. 2 Background 2.1 Agentic Communication In classical MAS, interaction is usually discussed in relation to an environment that mediates perception and action, and that can be treated as a first-class abstraction to clarify what responsibilities belong to agents versus shared infrastructure [47]. A closely related engineering perspective separates agents (decision-making entities) from the artifacts they use. Artifacts provide controllable, explicit capabilities in the working environment and can be either resources (for accessing and sharing information) or tools (for performing actions) [38]. This abstraction highlights that “communication” is not just message exchange: it is part of the broader machinery by which agents coordinate action and share responsibility. Historically, agent communication has been supported by standardised message languages that expose the intent of messages (e.g., ask, tell, reply), with canonical examples including KQML (Knowledge Query and Manipulation Language) [16] and the FIPA-ACL specification [17]. These early formal models rely on a limited set of standardised interaction patterns and assume mentalist semantics, i.e., they define communicative acts in terms of an agent’s internal beliefs and intentions. For example, when an agent sends a message (such as tell), it is attempting to make the receiving agent believe something (i.e., changing its mental state). Such standards are often criticized as outdated [8] for a system of heterogeneous and autonomous agents, because agents’ internal states are hidden. Because of these limitations, many modern approaches prefer social semantics, in which the meaning of communication is defined in terms of publicly observable interaction state (e.g., commitments created, delegated, or discharged) and the explicit protocol being enacted, rather than in terms of beliefs and intentions. This shift supports reasoning and verification over interactions between heterogeneous and autonomous agents, precisely because it does not require access to, or agreement on, any particular internal mental representation [9, 40, 7, 8]. These approaches treat interaction protocols as first-class engineering artifacts and emphasise declarative protocol specifications that can be enacted and reasoned about independently of any single agent architecture. In contemporary LLM-based agentic systems, agents can collaborate with other agents, decompose tasks, call external tools (APIs, databases, code execution), and exchange intermediate artifacts. As a result, agent orchestration and tool access become important engineering concerns. This distinction between agents and tools also has direct implications for communication protocol design: agent-to-tool protocols typically emphasise structured invocation and resource access, whereas agent-to-agent protocols must support richer interaction patterns including negotiation, delegation, and multi-turn coordination. Recent surveys of agent interoperability protocols highlight that emerging proposals often target different aspects of an agentic system (e.g., context/tool vs. inter-agent) [49, 15]. From an engineering standpoint, this leads to a recurring design decision: whether a protocol primarily standardises agent-to-tool integration (structured invocation of external capabilities) or agent-to-agent interaction (turn-taking, delegation, long-running tasks, and progress reporting). To make this distinction concrete, the next two subsections introduce MCP and A2A as representative protocols: one aimed primarily at tool integration, the other at inter-agent collaboration. 2.2 Model Context Protocol (MCP) The Model Context Protocol (MCP) [42] is a JSON-RPC client–server interface for secure context ingestion and structured tool invocation which streamlines the integration of LLMs with external data sources and tools. To this end, it supports flexible plug-and-play tools, safe infrastructure integration, and compatibility across LLM vendors [15]. The usage of MCP is characterised by the presence of three architectural components that structure how LLM-based agents interact with external resources and tools. In this architecture, the host refers to agents responsible for interacting with users, understanding and reasoning through user queries, and selecting tools. The client is connected to a host and is responsible for providing descriptions of available resources, whereas the server is connected to the resource(s) and establishes a one-to-one connection with the client, providing the required context from the resource(s) to the client. MCP primitives constitute the core protocol abstractions and define the types of contextual information and executable actions that clients and servers can exchange. They specify both what information can be shared with LLM-based applications and which actions can be performed. MCP defines three first-class primitives that servers can expose: resources, tools, and prompts. Resources are data sources such as file contents, database records, or API responses; tools are executable functions such as file operations, API calls, or database queries; and prompts are reusable templates that structure interactions with language models. 2.3 Agent2Agent (A2A) Protocol A2A is a lightweight, web-native protocol for enterprise-oriented agent communication, building on existing standards (i.e., HTTP and JSON-RPC) to support asynchronous, long-running interactions across heterogeneous agents. It enables modality-independent message exchange while preserving opaque execution, allowing agents to collaborate without exposing internal logic or proprietary capabilities. The official specification of A2A [1] is expressed as a set of JSON-RPC messages to be exchanged between an A2A client and an A2A server. An A2A server hosts one or more agents, which are described using agent cards served from the same server, or from a registry or catalogue. Agent cards are JSON documents served over HTTP that provide structured metadata advertising each agent’s capabilities and providing the necessary communication endpoints. A2A defines a specific structure for a message, which can be divided into multiple parts. Within a specific turn of communication between a client and an agent, the client will send a message with its request to the agent, who can reply directly with another message (in case a response can be immediately given), or with a task. A task represents a stateful and long-running piece of work whose progress needs to be tracked by the client and the server. Tasks have a well-defined lifecycle within A2A. A task is created in response to a message from the client when the agent considers that producing the response will take some time, is immediately returned to the client with a unique ID for later reference, and may provide interim updates on changes in the artifacts produced by the task or in the state of the task. At some point, the task will reach a terminal state (e.g., completed, cancelled, failed, or rejected), or a paused state (input-required or auth-required), allowing the client to provide additional information for the agent to resume execution. 3 Methodology 3.1 Software Engineering Task To study the practical use of MCP and A2A in a realistic setting, we implement and evaluate a multi-agent collaboration that solves a common software engineering task: given a prompt in natural language, produce an object-oriented model of the domain. This task instantiates a coordination pattern in which a solution-producing component is embedded within an iterative validation and refinement loop involving specialised supervisory components. The object-oriented model is expressed in a machine-readable format, such that it can be used by specialised tools to automatically generate code and documentation. While formats such as PlantUML [37] and MermaidJS [33] may be sufficiently popular to be directly generated by existing foundational models (e.g., GPT-4), these formats are primarily intended for visualisation and not for automated model processing (e.g., generating Java code or HTML documentation of a domain model). Instead, domain models are produced in the Emfatic [14] textual language of the Eclipse Modelling Framework (EMF) [43], from which it is possible to generate Java code and perform other automated transformations. We propose the multi-agent collaboration defined in Algorithm 1 to solve the domain model generation task described above. The collaboration structure is fixed across both protocol implementations in order to isolate the effects of protocol-level abstractions on coordination and interaction design. The algorithm takes as input a prompt describing a domain, and a maximum number of retries, and then returns either a validated artifact or a failure outcome if no valid artifact can be generated within the allowed number of attempts. 1 Input: User prompt P, maximum retries N Output: Validated artifact M or failure 2 3attempts←0attempts← 0, validated←falsevalidated← false; 4 5while attempts<Nattempts<N and not validatedvalidated do 6 7 attempts←attempts+1attempts← attempts+1; 8 9 M←SolutionAgent.Generate(P)M← SolutionAgent.Generate(P); 10 11 syntaxFeedback←SyntacticSupervisorAgent.Validate(M)syntaxFeedback← SyntacticSupervisorAgent.Validate(M); 12 13 if syntaxFeedback.status=invalidsyntaxFeedback.status=invalid then 14 P←RefinePrompt(P,syntaxFeedback)P← RefinePrompt(P,syntaxFeedback); 15 16 continue ; 17 18 19 semanticFeedback←SemanticSupervisorAgent.Validate(P,M)semanticFeedback← SemanticSupervisorAgent.Validate(P,M); 20 21 if semanticFeedback.status=invalidsemanticFeedback.status=invalid then 22 P←RefinePrompt(P,semanticFeedback)P← RefinePrompt(P,semanticFeedback); 23 24 continue ; 25 26 27 validated←truevalidated← true; 28 29 30return M if validatedvalidated else failure; 31 Algorithm 1 Collaboration Agent: Workflow for Model Generation 1. A collaboration agent orchestrates the entire agentic workflow described in Algorithm 1. It receives the description of the domain from the user, and forwards it as a new request to the solution agent (line 4). As the focus of this paper is to compare protocol-level support for coordination, the internal implementation strategy of individual agents is not treated as a variable in the analysis. Accordingly, the workflow used in this paper is fixed; computing collaborations on the fly is outside the scope of this work. 2. A solution agent uses an LLM to drive the production of the domain model, which it returns to the collaboration agent. This LLM may directly generate the domain model in the Emfatic language, or it may use tools to build up a model and then generate Emfatic source code, by following the ReAct architecture [50]. The choice will depend on the capabilities and training data used by the selected LLM: larger models may be able to directly generate Emfatic, whereas smaller models may require the assistance of purpose-specific tools and the ReAct architecture. The possibility that the solution agent produces invalid, incomplete, or no output at all is explicitly considered in order to exercise iterative interaction and feedback in the collaboration (up to a certain number of attempts), with failures being signalled by the solution agent through detailed error messages to support fixing the generated model. The solution agent may produce output that does not conform to the Emfatic grammar or semantics. For that reason, the collaboration agent will take the proposed solution and forward it to the syntactic supervision agent (line 5), which will parse the solution using an Emfatic parser. • If any errors are reported (lines 6–8), the syntactic supervision agent will inform the collaboration agent that the solution is invalid, and include feedback with the specific errors. The collaboration agent will then pass on the feedback to the solution agent, who will make another attempt to produce a valid solution (up to a certain number of attempts). • If no errors are reported, the agent will only indicate that the solution is valid, and the collaboration agent will proceed to the next step. 3. Although syntactically correct, the output may not meet all the requirements of the original description. For that reason, the collaboration agent will pass on the original description of the domain and the generated Emfatic source to a semantic supervision agent (line 9). This agent will use an LLM that has been instructed to read Emfatic code through few-shot prompting, by providing it a few examples of Emfatic syntax within the prompt. • If any issues are detected (lines 10–12), the semantic supervision agent informs the collaboration agent, who forwards the feedback to the solution agent and asks for an updated solution. • If the semantic supervision agent finds no issues in the solution, the collaboration agent returns the final solution (lines 13 and 14). 3.2 Requirements To structure the analysis of the protocol-based implementations of the collaboration scenario described in Section 3.1, we derive a set of requirements informed by recent survey literature [49, 15] and by practical needs articulated by industry partners within the MOSAICO research project [34]. MOSAICO investigates collaborative, LLM-based agent ecosystems for software development, focusing on the design of communication protocols, intelligent agents spanning the software development lifecycle, and practical conditions for their effective and responsible adoption in real-world settings. These requirements are intended as analytically useful dimensions that reflect recurring concerns in the design and engineering of coordinated agent systems, rather than as an exhaustive or normative evaluation framework. In particular, they are used to structure a qualitative, implementation-grounded comparison of protocol characteristics, rather than to support quantitative benchmarking or claims of protocol superiority. Specifically, within MOSAICO, functional and non-functional requirements were elicited from practical use cases provided by business partners in diverse industries, including banking (National Bank of Greece [35]), aerospace (Collins Aerospace [10]), immersive technologies (Immersion [22]), and IoT (UNPARALLEL [45]). R1: Agent discoverability The protocol should have a way to list the collaboration / solution / supervision agents implemented by a given agent server, and describe their most important features. The description should include: identification (name and description), skills, message formats of input and output, and security formats (authentication schemes and authority). R2: Multi-part messaging The protocol should separate the natural language parts of their responses from their structured parts (e.g., valid/invalid evaluations, or the generated Emfatic source code), resulting in multi-part messages. R3: Multi-turn conversations The protocol should allow the solution agent to request further clarification on the domain description if it considered necessary. Note that for this experiment, the implemented agents did not perform requests for clarification: instead, we reviewed the protocol specifications for the support of such a mechanism. R4: Asynchronous and streaming communication A user should be able to either ask regularly for updates on the generation of the solution (polling), or to maintain an ongoing connection and receive live updates (streaming). Collaboration agents would use the same part of the protocol to monitor the progress of the solution and supervision agents. R5: Agent observability For this experiment, we will evaluate integrating the agents with existing observability platforms for LLM-based applications, which can be run on-premises, such as Arize Phoenix [6] and Langfuse [26]. Their instrumentations send OpenTelemetry [36] traces to their servers. To unify these traces across a collaboration involving a tree of tasks and sub-tasks to be solved, the protocol would need to support super-task IDs that relate agent traces to higher-level tasks. R6: Interoperability The protocol should not arbitrarily constrain developers’ choices with respect to implementation technologies, such as programming languages or agentic frameworks. We specifically selected a software engineering task that necessitates the use of multiple programming languages. Since the Emfatic parser is implemented in Java, the syntactic supervision agent must be implemented in Java. On the other hand, many contemporary agentic frameworks are predominantly based on Python, which implies that other agents in the collaboration can naturally be implemented in Python. R7: Access control Access control will be evaluated through examination of the protocol itself, rather than through the implemented agents. It is envisioned that HTTP-based protocols can largely treat authentication in an off-band manner, through existing HTTP mechanisms (e.g., additional headers or TLS encryption). Authorization will require having some way to signal the refusal to comply with a specific request, or to provide access to a specific agent. 4 Implementation This section details the implementation of the use case described in Section 3.1 using MCP and A2A. Thus, two equivalent implementations have been realised: one based on MCP (see Figure 1) and another based on A2A (see Figure 2). Figure 1: MCP-based system architecture 4.1 MCP-Based Implementation In the MCP multi-agent system implementation, each agent is exposed as an MCP server that contains one tool, as depicted in Figure 1. The tool of an agent’s MCP server carries out the actions of the agent; for example, the solution agent’s MCP server exposes a tool that calls an LLM for proposing a solution. However, the MCP tool encapsulating the solution agent’s behaviour also provides the LLM with additional tools for building the Emfatic source code by following the ReAct architecture, as detailed in Section 3.1. In this setting, the tool encapsulating the agent’s behaviour corresponds to the root-level tool, in which other tools are called. Therefore, although tools and agents are not strictly identical concepts, the root-level tool becomes nearly equivalent to the agent in this setting, as it effectively encapsulates the behaviour and execution logic of the agent. The user uses an MCP client (e.g., the MCP Inspector [5]) to connect to the MCP server associated with the collaboration agent, and then calls its tool with a prompt as a parameter. Then, the collaboration agent uses an MCP client to connect to the MCP server of the solution agent, and calls the tool of the solution agent by passing on the prompt as a parameter. The solution agent computes the solution using an LLM that leverages other internal tools, and returns the proposed solution to the collaboration agent. The remainder of the workflow is the same as in Section 3.1, with the difference that inter-agent communication entails an MCP client connecting to an MCP server for calling a tool wrapping the agent’s behaviour. The source code of the implemented MCP-based system, written in Java and Python and relying on MCP SDK APIs [32], is available in [30]. The collaboration and syntactic supervision agents do not use LLMs. The solution and semantic supervision agents use the qwen2.5-coder:32b LLM. The solution agent, the syntactic supervision agent, and the semantic supervision agent send only the final solution to the collaboration agent. The collaboration agent sends to the calling MCP client logging notifications regarding agent invocations, including input and output messages. Moreover, Langfuse was configured to enable observability, to trace the activity of the collaboration. An alternative implementation based on MCP would avoid direct agent invocation and instead rely on shared communication artifacts, such as mailboxes or task queues, exposed as MCP resources or tools. In this approach, agents would coordinate indirectly by publishing to and consuming from shared resources, with MCP providing the underlying integration infrastructure. This design closely aligns with MCP’s original emphasis on structured access to external resources and could support coordination patterns such as asynchronous messaging and persistent shared state. However, adopting this approach would require conversation management, message correlation, and execution context management to be implemented at the application level rather than being supported by the protocol itself. For this study, we therefore focus on evaluating MCP under its official specification and intended usage model, in order to ensure both a clearer and a fairer comparison with A2A’s protocol-level support for inter-agent communication, while considering infrastructure-mediated coordination as a direction for future work. 4.2 A2A-Based Implementation The source code of the implemented A2A-based system, written in Java and Python and relying on A2A SDK APIs [2], is available in [30]. The architecture of the A2A-based system is illustrated in Figure 2. The collaboration and syntactic supervision agents do not use LLMs. The solution agent and semantic supervision agent use the qwen2.5-coder:32b LLM. To support monitoring and debugging, observability is enabled through Langfuse, which provides detailed logs and traces of agent interactions. The implementation leverages the streaming and task lifecycle management capabilities in A2A to orchestrate communication and manage task execution between agents. When a user sends a prompt, the collaboration agent creates a task with a task ID and context ID, which serve as persistent identifiers throughout the entire workflow. Each agent can update the task by generating a TaskStatusUpdateEvent object containing state information with TaskStatus objects, and human-readable messages with the A2A Message objects. The artifact management system utilises TaskArtifactUpdateEvent objects to send results between agents, with each artifact containing metadata and actual content in multi-part objects. The solution agent produces artifacts containing the generated Emfatic model, and the supervisor agents generate artifacts with validity statuses and feedback. The collaboration agent acts as an orchestrator, and sends status updates at key milestones: agent discovery, agent invocations, result update, retry attempts, and final completion or failure. Figure 2: A2A-based system architecture The collaboration workflow implements retry logic with configurable maximum attempts, where validation failures trigger regeneration cycles with enriched context from supervisor feedback. Throughout this process, the task ID and context ID remain constant, ensuring correlation of messages and artifacts, and enabling the reconstruction of the complete interaction history. The final successful completion is signalled through a TaskStatusUpdateEvent with state set to completed and final set to true, accompanied by consolidated artifacts containing the validated Emfatic code and comprehensive validation and feedback from all participating agents. 5 Evaluation The MCP-based and A2A-based implementations were validated using 30 prompts, of which 10 were straightforward and 20 were of higher complexity. The validation prompts are available in [30]. Listing 1 contains one of the validation prompts, which requests the generation of a library model. Listing 2 presents the solution produced by the solution agent in response to the prompt in Listing 1, which was successfully validated both syntactically and semantically. ⬇ Please generate a model of a simple library management system with three main concepts: Library, Book, and Author. Each Library has a name (String) and contains a collection of Books and a collection of Authors (both containment references). Each Book has a title (String) and a page count (int) and has a non-containment reference to its main Author. Each Author has a name (String) and age (int) and knows which Books they have written (non-containment reference to Books). The system should clearly distinguish between containment and non-containment relationships: A Library owns its Books and its Authors (deleting the Library deletes its Books and its Authors). Authors and Books reference each other but do not manage each other’s lifecycles. Listing 1: User prompt for a library model provided to the collaboration agent ⬇ package LibraryManagement; class Model val Library[*] libraries; class Library attr String name; val Book[*] books; val Author[*] authors; class Book attr String title; attr int pageCount; ref Author author; class Author attr String name; attr int age; ref Book[*] books; Listing 2: Emfatic model generated by the solution agent 5.1 Analysis of Implementation and Coordination Complexity Table 1 presents a comparison between the MCP-based and A2A-based implementations in terms of implementation and coordination complexity. The A2A-based implementation contains a larger codebase, comprising 1898 lines of code compared to 1255 lines for the MCP-based implementation, and thus requiring approximately 51% more lines of code. Note that these figures were obtained by analysing the Python and Java code, excluding configuration files, using cloc [3], a language-aware line counting tool that automatically analyses source code repositories and reports the number of source lines of code per programming language, excluding blank lines and comments. The A2A-based implementation employs a larger number of coordination primitives, using 10 coordination-related abstractions compared to 4 in the MCP-based implementation. In particular, the A2A-based implementation relies on task management, event propagation, structured messaging, and streaming-related primitives, whereas the MCP-based implementation relies on transport initialisation, tool invocation, and logging coordination primitives. Furthermore, the A2A-based implementation traverses a larger number of coordination stages per interaction, requiring 6 coordination stages per interaction compared to 2 in the MCP-based implementation. Note that a coordination stage corresponds to one distinct coordination step required to complete an interaction, where an interaction represents one complete delegation cycle between two agents. The MCP-based implementation involves two stages: transport initialisation and tool invocation. Conversely, the A2A-based implementation involves several stages: agent discovery, task creation, message dispatch, task state progression, artifact propagation, and completion handling. This reflects the richer protocol-level workflow semantics and lifecycle management capabilities provided by A2A. Consequently, the comparatively smaller number of coordination primitives and stages per interaction enables the MCP-based implementation to follow a lighter-weight coordination model with lower orchestration complexity and a smaller coordination failure surface for inter-agent communication workflows. Table 1: Comparison of implementation and coordination characteristics Metric MCP A2A Lines of code 1255 1898 Coordination primitives 4 10 Coordination stages per interaction 2 6 5.2 Analysis of Requirements Fulfilment The MCP-based and A2A-based implementations have been evaluated against the requirements introduced in Section 3.2. As detailed in Table 2, the MCP protocol is evaluated as meeting 5 requirements (R1, R2, R4, R6, R7), partially meeting 1 requirement (R5), and not meeting 1 requirement (R3). Conversely, the A2A protocol is evaluated as meeting 6 requirements (R1, R2, R3, R4, R6, R7), and partially meeting 1 requirement (R5). R1: Agent discoverability MCP enables discoverability through MCP servers exposing tools and capabilities that can be queried by clients, whereas A2A provides explicit discoverability through Agent Cards and Agent Skills. R2: Multi-part messaging MCP tools support structured input and output schemas containing multiple logical parts, whereas A2A messages support different Part types (e.g., text, file, data). Structured information is exchanged between agents without requiring ad-hoc serialisation. R3: Multi-turn conversations A2A supports iterative interactions and clarification requests through task lifecycle states such as input-required. MCP does not provide native task or conversation tracking primitives, requiring servers to explicitly implement their own context tracking mechanisms. R4: Asynchronous and streaming communication MCP supports asynchronous request/response handling, event notifications, and streaming through Server-Sent Events (SSE) and Streamable HTTP, whereas A2A supports streaming and asynchronous operations through SSE and push notifications. R5: Agent observability Neither protocol provides native protocol-level tracing or explicit super-task IDs for observing an entire multi-agent collaboration. However, both implementations integrate external observability mechanisms through callback functions or third-party libraries. R6: Interoperability MCP provides transport-agnostic interoperability through standardised protocol messages and official SDKs, whereas A2A provides interoperability through HTTP-based communication and multiple SDKs. R7: Access control MCP supports access control via server-side mechanisms [31] and SDK APIs, whereas A2A integrates authentication and authorization through standard web mechanisms such as OAuth2 and OpenID Connect. Table 2: Requirement evaluation summary: ✓ met, × is not met, ∼ is partially met Requirement MCP A2A R1: Agent discoverability ✓ ✓ R2: Multi-part messaging ✓ ✓ R3: Multi-turn conversations × ✓ R4: Asynchronous and streaming communication ✓ ✓ R5: Agent observability ∼ ∼ R6: Interoperability ✓ ✓ R7: Access control ✓ ✓ The results indicate that the MCP-based implementation supports agent discoverability, multi-part messaging, asynchronous and streaming communication, interoperability, and access control, while it does not provide native support for multi-turn conversations and only partially supports agent observability. In comparison with the A2A-based implementation, MCP satisfies the requirements in largely the same way, with the notable exception of multi-turn conversations, which are explicitly supported by A2A but not natively supported by MCP, while observability remains only partially supported in both. The key distinction with regard to these requirements concerns multi-turn, stateful task handling: A2A provides explicit protocol-level support for long-running tasks, task states, and input-required interactions, whereas MCP requires these aspects to be realised through explicit orchestration logic implemented in the application layer. 6 Conclusions This paper presented an empirical report on the practical use of MCP and A2A, by implementing a multi-agent collaboration that solves a common software engineering task: given a natural language prompt, generate an object-oriented domain model. The results evidence that MCP can support inter-agent coordination in constrained LLM-based systems through a comparatively lightweight implementation model with lower coordination complexity, although coordination concerns such as conversational state management and task lifecycle handling must be implemented explicitly at the application layer. Conversely, A2A provides richer native support for stateful, multi-turn coordination through protocol-level abstractions for tasks and lifecycle management, but this comes with substantially greater implementation and coordination complexity. Considering the narrow scope of the evaluated coordination pattern, these findings are intended as design observations rather than general claims of protocol suitability across broader classes of MAS. As future work, we plan to investigate dynamic, LLM-driven inter-agent coordination, in which coordination structures are synthesised or adapted at runtime rather than fixed a priori. credits 6.0.1 Acknowledgements This paper was supported by the MOSAICO project (Management, Orchestration and Supervision of AI-agent COmmunities for reliable AI in software engineering) funded by the EU Horizon Research and Innovation Action (Grant Agreement No. 101189664). References [1] A2A Official Specification. Note: [Online]. Available: https://a2a-protocol.org/latest/specification, (Last Accessed: 2026-07-25) Cited by: §2.3. [2] A2A SDKs. Note: [Online]. Available: https://a2a-protocol.org/latest/sdk, (Last Accessed: 2026-07-25) Cited by: §4.2. [3] AlDanial cloc utility for counting lines of code. External Links: Link Cited by: §5.1. [4] N. Aldridge, M. Brooker, and S. Sivasubramanian (2025)Open Protocols for Agent Interoperability Part 1: Inter-Agent Communication on MCP(Website) External Links: Link Cited by: §1. [5] Anthropic (2025) MCP Inspector. External Links: Link Cited by: §4.1. [6] Arize Phoenix. Note: [Online]. Available: https://github.com/arize-ai/phoenix, (Last Accessed: 2026-07-25) Cited by: item R5: Agent observability. [7] A. K. Chopra, M. Baldoni, S. H. Christie V, and M. P. Singh (2025) Azorus: Commitments over protocols for BDI agents. In Proceedings of the 24th International Conference on Autonomous Agents and Multiagent Systems (AAMAS), p. 490–499. Cited by: §2.1. [8] A. K. Chopra, S. H. Christie V, and M. P. Singh (2025) Toolsuite for Implementing Multiagent Systems Based on Communication Protocols. External Links: Document Cited by: §2.1. [9] S. H. Christie V, A. K. Chopra, and M. P. Singh (2023) Kiko: Programming Agents to Enact Interaction Protocols. In Proceedings of the 22nd International Conference on Autonomous Agents and Multiagent Systems (AAMAS), Cited by: §2.1. [10] Collins Aerospace. Note: [Online]. Available: https://w.rtx.com/collinsaerospace, (Last Accessed: 2026-07-25) Cited by: §3.2. [11] S. Colvin (2025) MCP is all you need. Note: AI Engineer World’s Fair 2025 External Links: Link Cited by: §1. [12] V. Dibia, M. Kistler, and M. Naggaga (2025)Can You Build Agent2Agent Communication on MCP? Yes!(Website) External Links: Link Cited by: §1. [13] T. Dinh (2025) LLM-Based Multi-Agent Architecture for Transport Network Automation Using MCP and A2A Protocols. Bachelor’s thesis, Aalto University. Cited by: §1. [14] Eclipse Emfatic. Note: [Online]. Available: https://eclipse.dev/emfatic, (Last Accessed: 2026-07-25) Cited by: §3.1. [15] A. Ehtesham, A. Singh, G. K. Gupta, and S. Kumar (2025) A survey of agent interoperability protocols: Model Context Protocol (MCP), Agent Communication Protocol (ACP), Agent-to-Agent Protocol (A2A), and Agent Network Protocol (ANP). External Links: Document Cited by: §1, §1, §2.1, §2.2, §3.2. [16] T. Finin, R. Fritzson, D. McKay, and R. McEntire (1994) KQML as an agent communication language. In Proceedings of the Third International Conference on Information and Knowledge Management (CIKM), p. 456–463. External Links: Document Cited by: §2.1. [17] Foundation for Intelligent Physical Agents (FIPA) (2002) FIPA ACL Message Structure Specification. Note: FIPA Specification Cited by: §2.1. [18] K. Gholizadeh HamlAbadi, M. Vahdati, F. Laamarti, and A. El Saddik (2025) Agent-to-Agent A2A Protocol Integrated Digital Twin System with AgentIQ for Multimodal AI Fitness Coaching and Personalized Well-Being. In Proceedings of the 33rd ACM International Conference on Multimedia, p. 12483–12491. External Links: Document Cited by: §1. [19] D. Ghosh (2025) Beyond MCP/A2A: Core LLM Limitations and the future of agenfic AI in the construcfion industry. Cited by: §1. [20] D. P. Ghosh (2025) Agentic Ecosystemin Engineering Design: A Framework for Interoperable Legacy Tools and Emergent Collaboration via MCP/A2A Protocols. Cited by: §1. [21] I. Habler, K. Huang, V. S. Narajala, and P. Kulkarni (2025) Building A Secure Agentic AI Application Leveraging A2A Protocol. External Links: Document Cited by: §1. [22] Immersion. Note: [Online]. Available: https://w.immersion.fr, (Last Accessed: 2026-07-25) Cited by: §3.2. [23] C. Jeong (2025) A Practical MCP× A2A Integration Framework for Interoperability in LLM-Based Autonomous Multi-Agent Systems. Journal of Intelligence and Information Systems 31 (3), p. 141–170. Cited by: §1. [24] C. Jeong (2025) A Study on the MCP x A2A Framework for Enhancing Interoperability of LLM-based Autonomous Agents. External Links: Document Cited by: §1. [25] LangChain’s definition of an agent. Note: [Online]. Available: https://blog.langchain.com/what-is-an-agent, (Last Accessed: 2026-07-25) Cited by: §1. [26] Langfuse. Note: [Online]. Available: https://langfuse.com, (Last Accessed: 2026-07-25) Cited by: item R5: Agent observability. [27] Q. Li and Y. Xie (2025) From Glue-Code to Protocols: A Critical Analysis of A2A and MCP Integration for Scalable Agent Systems. arXiv preprint arXiv:2505.03864. External Links: Document Cited by: §1. [28] C. C. Liao, D. Liao, and S. S. Gadiraju (2025) AgentMaster: A Multi-Agent Conversational Framework Using A2A and MCP Protocols for Multimodal Information Retrieval and Analysis. External Links: Document Cited by: §1. [29] Linux Foundation (2025) Agent2Agent (A2A) Protocol Github project. External Links: Link Cited by: §1. [30] MCP and A2A-Based Implementations of the Multi-Agent System and Validation Prompts. Note: [Online]. Available: https://doi.org/10.17605/OSF.IO/YWRFM, (Last Accessed: 2026-07-25) Cited by: §4.1, §4.2, §5. [31] MCP Authorisation. Note: [Online]. Available: https://modelcontextprotocol.io/specification/draft/basic/authorization, (Last Accessed: 2026-07-25) Cited by: item R7: Access control. [32] MCP SDKs. Note: [Online]. Available: https://modelcontextprotocol.io/docs/sdk, (Last Accessed: 2026-07-25) Cited by: §4.1. [33] MermaidJS Class Diagrams. Note: [Online]. Available: https://mermaid.js.org/syntax/classDiagram.html, (Last Accessed: 2026-07-25) Cited by: §3.1. [34] MOSAICO Consortium, I. Atlantique, LIST, Uni. of York, Uni. dell’Aquila, Intrasoft, Immersion, NBG, Collins Aerospace, Unparallel, Qodo, Eclipse Foundation, and F6S (2025) MOSAICO – Management, Orchestration and Supervision of AI-agent Communities. Note: [Online]. Available: https://mosaico-project.eu, (Last Accessed: 2026-07-25) Cited by: §3.2. [35] National Bank of Greece. Note: [Online]. Available: https://w.nbg.gr, (Last Accessed: 2026-07-25) Cited by: §3.2. [36] OpenTelemetry. Note: [Online]. Available: https://opentelemetry.io, (Last Accessed: 2026-07-25) Cited by: item R5: Agent observability. [37] PlantUML Class Diagrams. Note: [Online]. Available: https://plantuml.com/class-diagram, (Last Accessed: 2026-07-25) Cited by: §3.1. [38] A. Ricci, M. Viroli, and A. Omicini (2007) Give agents their artifacts: the A&A approach for engineering working environments in MAS. In Proceedings of the 6th International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS ’07), p. 1–3. External Links: Document Cited by: §2.1. [39] Y. Shoham (1993) Agent-oriented programming. Artificial intelligence 60 (1), p. 51–92. External Links: Document Cited by: §1. [40] M. P. Singh, S. H. Christie V, and A. K. Chopra (2024) Langshaw: Declarative interaction protocols based on sayso and conflict. In Proceedings of the 33rd International Joint Conference on Artificial Intelligence (IJCAI), External Links: Document Cited by: §2.1. [41] M. P. Singh (2000) A social semantics for agent communication languages. In Issues in agent communication, p. 31–45. External Links: Document Cited by: §1. [42] J. Spahr-Summers and D. Soria Parra (2025) Model Context Protocol website. External Links: Link Cited by: §1, §2.2. [43] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks (2008) EMF: Eclipse Modeling Framework. 2 edition, Eclipse Series, Addison-Wesley Professional. External Links: ISBN 978-0-321-33188-5 Cited by: §3.1. [44] V. Tupe and S. Thube (2025) Demonstrating Multi-Agent Collaboration via Agent-to-Agent and Model Context Protocols: An IT Incident Response Case Study. In 2025 IEEE International Conference on Service-Oriented System Engineering (SOSE), p. 1–5. External Links: Document Cited by: §1. [45] UNPARALLEL. Note: [Online]. Available: https://w.unparallel.pt, (Last Accessed: 2026-07-25) Cited by: §3.2. [46] L. Voss (2025) MCP vs ACP vs A2A: Comparing Agent Protocols. Note: MCP Developer Summit External Links: Link Cited by: §1. [47] D. Weyns, A. Omicini, and J. Odell (2007) Environment as a first class abstraction in multiagent systems. Autonomous Agents and Multi-Agent Systems 14 (1), p. 5–30. External Links: Document Cited by: §2.1. [48] M. Wooldridge and N. R. Jennings (1995) Intelligent agents: Theory and practice. The Knowledge Engineering Review 10 (2), p. 115–152. External Links: Document Cited by: §1. [49] Y. Yang, H. Chai, Y. Song, S. Qi, M. Wen, N. Li, J. Liao, H. Hu, J. Lin, G. Chang, W. Liu, Y. Wen, Y. Yu, and W. Zhang (2025) A Survey of AI Agent Protocols. External Links: Document Cited by: §1, §1, §2.1, §3.2. [50] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao (2023) ReAct: Synergizing Reasoning and Acting in Language Models. In Proceedings of ICLR 2023, External Links: ISBN 978-1-71389-925-9 Cited by: item 2.