MCP Agent Pipelines

• MCP agent pipelines are a structured execution model where an LLM-driven host leverages JSON-RPC 2.0 to separate reasoning from execution.
• They integrate dynamic tool discovery, multi-agent coordination, and shared state management to enhance runtime efficiency and scalability.
• Robust security and error recovery are achieved through identity propagation, audit logging, and layered control strategies across distributed systems.

Model Context Protocol (MCP) agent pipelines are structured workflows in which an LLM-driven host or agent discovers, selects, and invokes external capabilities through MCP’s client-server interface, typically over JSON-RPC 2.0, while carrying forward structured state through Tools, Resources, and Prompts (Ouyang et al., 7 Sep 2025). Across recent work, the concept has expanded from single tool invocation to encompass multi-agent coordination, runtime tool retrieval, repository-to-service conversion, declarative workflow execution, brokered production control planes, and shared-context collaboration, all under the broader goal of separating reasoning from execution without abandoning interoperability (Tiwari et al., 26 Sep 2025, Parmar, 13 Mar 2026, Jayanti et al., 6 Jan 2026).

1. Protocol substrate and baseline architecture

The baseline MCP stack is consistently described as a host–client–server arrangement around an LLM-driven agent. In one influential security framing, the host/application embeds the model in an end-user product and manages execution state; the model provider / aligned LLM selects tools and proposes parameters from a context that includes tool names, natural-language descriptions, schemas, server-provided prompts, and prior-turn state; the MCP client / SDK parses protocol messages and constructs requests; the MCP server / tool execution side exposes tools and resources and returns outputs that re-enter the model’s context; the transport / network carries JSON-RPC-like traffic; and the registry / marketplace / supply-chain layer governs how servers and tools are discovered, installed, versioned, updated, and trusted (Rostamzadeh et al., 8 Apr 2026). This decomposition is important because it treats an MCP pipeline not as a single API call, but as a distributed control path with distinct ownership and trust boundaries.

At the protocol level, MCP is described as a JSON-RPC 2.0 client-server protocol with three core primitives: Tools, Resources, and Prompts (Ouyang et al., 7 Sep 2025). In a vision-systems framing, MCP is further described as a schema-bound execution model for agent-tool interaction, where tools advertise typed schemas, the agent reasons over those schemas plus context state, selects and invokes tools, writes outputs into structured context objects, and chains downstream tools when compatibility holds (Tiwari et al., 26 Sep 2025). A standard end-to-end MCP workflow therefore runs from discovery or installation of a server, through registration of tool metadata and schemas into the host/client environment, to model planning, tool selection, client-side marshaling, server-side execution, and reinsertion of results into the host and model context for further multi-turn or multi-tool action (Rostamzadeh et al., 8 Apr 2026).

2. Coordination topologies and shared-context collaboration

The literature does not treat MCP pipelines as purely linear call chains. A design-pattern survey argues that MCP-based multi-agent pipelines are better understood as structured communication systems combining Mediator, Observer, Publish-Subscribe, and Broker patterns, with architectural variants including centralized orchestration, decentralized shared-context exchange, hierarchical control, and hybrid adaptive forms (Sarkar et al., 26 May 2025). A separate multi-agent framework organizes MCP-mediated systems into sequential pipelines, branching pipelines, iterative feedback loops, hierarchical orchestration, and some forms of peer-based distributed collaboration, with MCP serving as the context-and-capability substrate that makes stage-to-stage handoff possible without forcing all state into a single model prompt (Krishnan, 26 Apr 2025).

One response to the limitations of stateless orchestration is Context-Aware MCP (CA-MCP), which introduces a Shared Context Store (SCS). In this design, the central LLM becomes a long-term planner that interprets the user request, decomposes the task, selects relevant MCP servers, and seeds the SCS with goals, parameters, constraints, and an execution outline. MCP servers become stateful reactors that monitor the SCS for relevant triggers, read current context, perform work, and write intermediate outputs back into the shared store, while the LLM re-engages primarily for final synthesis (Jayanti et al., 6 Jan 2026). The paper explicitly contrasts this with traditional MCP, where the LLM remains the continuous micro-orchestrator and servers are stateless executors.

A separate line of work identifies another coordination limit: MCP and A2A both assume a single controlling principal. MPAC is proposed for cases in which independent principals’ agents must coordinate over shared state, such as engineers’ coding agents editing the same repository or agents from different organizations negotiating a joint decision. The protocol introduces explicit coordination semantics across Session, Intent, Operation, Conflict, and Governance, makes intent declaration a precondition for action, represents conflicts as first-class structured objects, and supports human-in-the-loop arbitration through a pluggable governance layer (Qian et al., 10 Apr 2026). This suggests that, beyond single-owner tool invocation, MCP agent pipelines increasingly require explicit semantics for shared-state coordination, conflict handling, and authority boundaries.

3. Tool discovery, indexing, and ecosystem construction

As MCP ecosystems scale, a substantial part of the pipeline shifts upstream from execution to discovery and indexing. MCPZoo aggregates 90,146 distinct MCP servers from six public sources and verifies 14,206 of them as runnable and interactable, with unified metadata and a unified remote access configuration for deployed servers (Wu et al., 17 Dec 2025). MCP-Flow automates marketplace crawling, server deployment, tool extraction, data synthesis, and model training; in its reported corpus it collects and filters data from 1166 servers and 11536 tools, producing 68733 high-quality instruction-function call pairs and 6439 trajectories (Wang et al., 28 Oct 2025). Together these systems reframe pipeline design around the practical problems of server discovery, deduplication, liveness checking, and realistic experimentation over heterogeneous MCP backends.

A more agent-centered solution is ScaleMCP, which treats MCP servers as the single source of truth and keeps retrieval storage synchronized through hash-based CRUD over tool name, description, and parameters (Lumer et al., 9 May 2025). Its runtime innovation is to expose an MCP Retrieval Tool to the LLM itself, allowing the agent to search for new tools dynamically, add them into memory, and re-query during multi-turn interaction rather than being confined to a fixed top-$k$ set chosen before invocation (Lumer et al., 9 May 2025). The same paper proposes Tool Document Weighted Average (TDWA), a weighted embedding strategy over tool-document components such as tool name or synthetic questions, as a more controllable alternative to simple concatenation (Lumer et al., 9 May 2025).

The tool ecosystem is also being expanded from the supply side. Code2MCP addresses the “last-mile” bottleneck of converting ordinary repositories into MCP services by using a seven-stage, LangGraph-based, multi-agent pipeline that begins with a repository URL and produces an MCP service plus documentation, tests, and audit artifacts (Ouyang et al., 7 Sep 2025). Its key implementation pattern is a closed-loop Run–Review–Fix cycle: the system generates mcp_service.py, adapter.py, and test_mcp_basic.py, executes the test harness, analyzes failure traces, proposes a minimal edit at the adapter boundary, regenerates artifacts, and retries until success or budget exhaustion (Ouyang et al., 7 Sep 2025). In this way, MCP agent pipelines now encompass not only using tools, but also discovering, indexing, and generating them.

4. Execution strategies: orchestration, workflow compilation, and code execution

A major divide in the literature is between context-coupled and context-decoupled execution. In traditional MCP, tool metadata, schemas, intermediate outputs, and reasoning traces are pushed into the model’s context window, creating a turn-by-turn loop of discovery, reasoning, one-tool invocation, output ingestion, and replanning (Felendler et al., 17 Feb 2026). In Code Execution MCP (CE-MCP), by contrast, the model generates a single executable program containing tool calls, control flow, data transformations, and output formatting; this program then runs in an isolated execution environment where MCP tools are exposed as callable functions, and only final results or errors are returned to the model (Felendler et al., 17 Feb 2026). The paper formalizes this as the distinction between context-coupled and context-decoupled models and argues that CE-MCP reduces token usage and execution latency while expanding the attack surface (Felendler et al., 17 Feb 2026).

A different execution strategy appears in the MCP Workflow Engine, which separates intelligence from execution by having an agent reason once to produce a declarative workflow blueprint—a JSON document with parameterized templates, loops, parallel branches, and data piping—and later execute that blueprint through a single run_workflow tool call (Parmar, 13 Mar 2026). The system formalizes the MCP Mediator pattern: an MCP server that simultaneously acts as a client to downstream MCP servers (Parmar, 13 Mar 2026). Its workflow DSL contains five primitives—call, loop, parallel, pipe, and collect—and it stores each completed step’s output at steps.<stepId> so that later steps can reference prior results without re-entering an LLM planning loop (Parmar, 13 Mar 2026).

In the paper’s production-scale Kubernetes CMDB synchronization task, the engine orchestrates 67 steps across 2 MCP servers, 38 namespaces, 13 worker nodes, and 22 distinct resource types, completes a graph with 1,200+ nodes and 2,800+ relationships in under 45 seconds, and reduces per-execution token cost by over 99% with zero agent involvement at run time (Parmar, 13 Mar 2026). The broader implication is that MCP pipelines now span a continuum: turn-by-turn tool orchestration, declarative workflow interpretation, and compiled executable workflows, each shifting the boundary between reasoning, state management, and execution.

5. Security, identity, and production control planes

Security work on MCP pipelines emphasizes that the attack surface begins well before tool execution. A defense-placement taxonomy divides MCP into six enforcement layers—Model Provider / LLM Alignment, MCP Host / Application, MCP Client / SDK, MCP Server / Tool Execution, Transport / Network, and Registry / Marketplace / Supply-chain—and argues that threats should be assigned to the earliest architectural boundary where meaningful prevention is feasible (Rostamzadeh et al., 8 Apr 2026). This framing highlights three especially security-relevant surfaces beyond prompt-only LLM applications: pre-execution artifacts, shared or persistent context, and execution-time side effects (Rostamzadeh et al., 8 Apr 2026). A deployment-scale audit of vision-centric MCP servers reinforces the point by reporting 78.0% schema-format misalignment, 89% missing runtime schema validation, 87% undeclared coordinate conventions, 55% undocumented memory retention logic, 89.0% untyped tool connections, and 41.0% privilege escalation or data leakage risk (Tiwari et al., 26 Sep 2025).

Several papers respond by adding explicit control planes. SMCP extends MCP with unified identity management, robust mutual authentication, ongoing security context propagation, fine-grained policy enforcement, and comprehensive audit logging, using a trusted registry, policy engine, and correlated identifiers such as sessionId and callChainId to make chained tool use policy-aware and auditable (Hou et al., 1 Feb 2026). CABP, proposed as part of a production deployment study, extends JSON-RPC with identity-scoped request routing via a six-stage broker pipeline: token extraction, claim validation, ACL resolution, context injection, response sanitization, and audit emission (Srinivasan, 12 Mar 2026). The same study introduces ATBA, which allocates per-tool timeout budgets proportional to $p_{99}$ latency estimates while reserving 10% of the planner budget for overhead, and SERF, which turns tool failures into machine-readable categories such as INVALID_INPUT, RESOURCE_EXHAUSTED, and UPSTREAM_FAILURE so that agents can recover deterministically rather than improvisationally (Srinivasan, 12 Mar 2026).

At a lighter-weight systems boundary, MCP Bridge exposes multiple MCP servers through a unified REST API and adds a three-level risk model: standard execution, confirmation workflow, and Docker isolation (Ahmadi et al., 11 Apr 2025). In practice, these lines of work converge on the same principle: MCP protocol compliance alone does not provide production reliability or security; pipelines require explicit identity propagation, budget management, structured error semantics, policy enforcement, and auditability around the raw tool-call path (Srinivasan, 12 Mar 2026, Ahmadi et al., 11 Apr 2025).

6. Empirical record, trade-offs, and open problems

The empirical literature shows that MCP pipeline design choices materially affect efficiency and quality. In CA-MCP, TravelPlanner execution time drops from 41.99 s to 13.52 s, completeness rises from 0.764 to 1.000, and LLM calls fall from 5 to 2; on REALM-Bench Wedding Logistics, execution time falls from 8.52 s to 2.26 s, makespan drops from 330.0 minutes to 180.0 minutes, and coordination score rises from 0 to 1 (Jayanti et al., 6 Jan 2026). In MPAC, a controlled three-agent code review benchmark reports a 95 percent reduction in coordination overhead and a 4.8 times wall-clock speedup versus a serialized human-mediated baseline, with speedup attributed to eliminating coordination waits rather than compressing model calls (Qian et al., 10 Apr 2026). In Code2MCP, repository-to-service conversion averages 8.3 minutes versus an estimated 2.4 hours manually, for an average speedup of about 17.8× (Ouyang et al., 7 Sep 2025).

On the tool-selection side, MCP-Flow reports that fine-tuned small models can exceed frontier proprietary systems on real-world MCP function calling. In the 10-tool setting, MCP-Flow Qwen3-4B reaches AST 81.2 / 78.2 / 59.8 on Seen / Unseen Tool / Unseen Server, compared with GPT-4o at 58.8 / 62.0 / 50.8; in the 100-tool setting, MCP-Flow Qwen-4B averages Tool 81.7, Param 82.1, and AST 67.0, exceeding GPT-4o at Tool 72.3, Param 66.9, and AST 53.8 (Wang et al., 28 Oct 2025). The same study shows GAIA gains when MCP-specialized function calling is inserted into a broader agent: Qwen3-4B rises from SR 10.68 to 21.36, GPT-4o from 29.13 to 33.98, and Claude-4-Sonnet from 55.34 to 57.28 (Wang et al., 28 Oct 2025).

Taken together, these results suggest that the central research problem is no longer merely how to let an LLM call a tool, but how to manage discovery, coordination, execution, and governance across rapidly expanding MCP ecosystems. Open problems identified across the literature include richer schema type systems and compositional semantics, stronger runtime validation, direct support for identity propagation and structured error recovery in the protocol itself, privacy-preserving context sharing, larger-scale benchmarking for multi-agent coordination, and broader support for dynamic, cross-organizational, or multi-principal workflows (Tiwari et al., 26 Sep 2025, Srinivasan, 12 Mar 2026, Krishnan, 26 Apr 2025). A plausible implication is that future MCP agent pipelines will be increasingly layered: standardized at the protocol boundary, but differentiated by their control planes for retrieval, coordination, execution, and security.