Does MCP handle multi-turn agent coordination without application code?

The paper builds an MCP-based and an A2A-based multi-agent implementation of the same software engineering task and checks each against requirements drawn from prior literature and industry-partner discussions: agent discoverability, multi-part messaging, multi-turn conversations, asynchronous communication, observability, interoperability, and access control. Its conclusion is that MCP "can support inter-agent coordination in constrained LLM-based systems" through "a comparatively lightweight implementation model with lower coordination complexity." The MCP build supported discoverability, multi-part messaging, asynchronous and streaming communication, interoperability, and access control. It did not natively support multi-turn conversations and only partially supported observability.

The reported difference between the protocols is narrow. On most requirements MCP meets them "in largely the same way" as A2A, and observability is only partially supported in both, so neither protocol closes that gap. What separates them is "multi-turn, stateful task handling": A2A gives "explicit protocol-level support for long-running tasks, task states, and input-required interactions," whereas MCP needs these "realised through explicit orchestration logic implemented in the application layer." The lightness of MCP is therefore a transfer of cost. Conversational state management and task lifecycle handling do not disappear; they move from the protocol to whoever builds the system.

This is an implementation-level counterpart to Can agent protocols be efficient, versatile, and portable simultaneously?, which classifies MCP-style protocols as rigid-schema and stateless and A2A-style protocols as session-stateful. Here the classification shows up as a builder's burden: a stateless protocol pushes state into application code. It also sits beside, without contradicting, Why do protocol-based tool integrations fail in production workflows?. That note reports run-to-run failures from ambiguous tool selection in a production workflow. This excerpt reports requirement coverage, not reliability, so the two measure different things. On discovery, the excerpt says both protocols support discoverability but not how or at what scale, so it does not speak to the semantic discovery problem in Can semantic capability vectors replace manual agent routing?.

The excerpt gives requirement-level verdicts (supported, partial, not native) and nothing else. It does not state how many agents or which models were used, how large the application-layer state code became, or any failure rate. It covers one task, and "constrained" is not defined in the passages available. "Lower coordination complexity" is asserted in the abstract without a stated metric. What follows at that strength: a builder choosing MCP for inter-agent work should expect to write the conversation-state and task-lifecycle logic themselves, and the lightweight advantage is most plausible where interactions are short enough that this logic stays small. Whether it holds for long-running, input-required workflows is a question this excerpt raises rather than answers.