MCP-Flow: Automating & Securing Tool Execution

• MCP-Flow is a dual-use concept that defines both an automated pipeline for tool discovery and synthesis, and a broader architectural flow linking natural language to external tool execution.
• It automates server crawling, data synthesis with schema-based instructions, and rigorous filtration to build a high-quality dataset for improving LLM tool invocation.
• The system demonstrably boosts tool selection and function-call accuracy while addressing security, governance, and execution challenges in heterogeneous MCP environments.

MCP-Flow is a term used in recent Model Context Protocol research in two closely related senses. In the narrow sense, it denotes an automated, web-agent-driven pipeline, dataset, and model suite for improving LLM agents’ use of real-world MCP tools through large-scale server discovery, data synthesis, filtration, fine-tuning, and retrieval augmentation (Wang et al., 28 Oct 2025). In the broader systems and security literature, it denotes the end-to-end path by which tool metadata, user intent, model decisions, tool invocations, intermediate outputs, and system-side actions propagate across MCP hosts, clients, servers, transports, and registries (Li et al., 5 Jul 2025, Rostamzadeh et al., 8 Apr 2026, Hou et al., 8 May 2026). Both usages concern the same underlying object: the operational flow that connects natural-language intent to external tool execution in heterogeneous MCP environments.

1. Terminological scope and conceptual boundaries

Within the MCP literature, the most direct use of the name appears in "MCP-Flow: Facilitating LLM Agents to Master Real-World, Diverse and Scaling MCP Tools" (Wang et al., 28 Oct 2025), where MCP-Flow is presented as a scalable training foundation rather than only a benchmark. The stated motivation is that prior MCP work suffers from three bottlenecks: coverage that is too small, data collection that is manual or semi-manual, and evaluation-only designs that do not produce training data.

Other papers use the term more generically. The privilege-management study frames MCP flow as the path by which user intent is translated by an LLM into tool invocations that ultimately trigger file, network, system, or memory access on a local machine (Li et al., 5 Jul 2025). The defense-placement taxonomy describes MCP security as a flow problem across a distributed protocol stack, extending from registry and supply chain through discovery, context assembly, model decision, tool selection, transport, server execution, and tool response (Rostamzadeh et al., 8 Apr 2026). The bidirectional data-flow analysis paper treats MCP-Flow as a trust-boundary data-flow problem in two directions: requester-controlled input reaching sensitive operations, and untrusted external or sensitive internal data returning through MCP-visible outputs and influencing downstream behavior (Hou et al., 8 May 2026).

A common misconception is that the term has a single fixed meaning. The literature does not support that reading. The narrow usage names a specific automated pipeline and dataset (Wang et al., 28 Oct 2025); the broader usage names an architectural and security abstraction over MCP execution paths (Li et al., 5 Jul 2025, Rostamzadeh et al., 8 Apr 2026, Hou et al., 8 May 2026). By contrast, unrelated uses of the acronym MCP in other domains, such as minimax concave penalty in graph Laplacian learning, refer to a different acronym altogether (Zhang et al., 2020).

2. Automated discovery, deployment, and synthesis pipeline

As a concrete system, MCP-Flow is organized around two stages: automated server discovery and tool collection, followed by scalable data synthesis and filtration (Wang et al., 28 Oct 2025). Server discovery crawls seven marketplaces or sources: Smithery, Glama, MCP.so, MCPHub, PulseMCP, DeepNLP, and PipeDream. Rather than relying on website-specific parsers, the pipeline uses Playwright as an MCP-compatible web agent. The agent navigates marketplace homepages, extracts server listings, opens server detail pages, and extracts a configuration file or page snapshot. The prompt explicitly requests JSON-only output containing server names and descriptions. The design is also incremental: after the initial crawl, future updates require incremental crawling of new servers only.

Deduplication is performed at the server level using tool descriptions rather than names or providers. The stated rule is that if two servers expose the same list of tool descriptions, they are treated as the same server. After deduplication, each server is locally deployed through the MCP client. For stdio servers, launch occurs with npm or uvx; for SSE servers, connection occurs via URL. From each successfully deployed server, the pipeline extracts tool name, tool description, and tool input schema or parameters. Servers requiring API keys, personal workspaces, or special software dependencies are not fully automatable and are excluded from trajectory generation if they cannot be deployed.

Data synthesis proceeds from the tool side. For each tool, the model generates 5 distinct instructions using curated examples, with the explicit constraint that every instruction must require the target tool and should not directly mention the tool name or server name. A slot-fill revision stage then treats each required parameter as a slot: if the instruction lacks a slot value, a valid value is generated and the query is rewritten for fluency, with regex-based cleanup for placeholders such as file names, URLs, and directories. To increase difficulty and linguistic variation, the pipeline applies WizardLM-style evolution with random transformation directions and depth set to 2. Given the instruction, the ground-truth tool, and the input schema, GPT-4o is then prompted to produce the formal MCP function call. Finally, the system sends the function call to the locally deployed MCP server, collects the tool response, and has an assistant model summarize the result into a final answer, yielding a full trajectory containing user instruction, tool selection, function call, tool response, and assistant response (Wang et al., 28 Oct 2025).

This design makes MCP-Flow more than a static corpus. It is a regeneration pipeline that couples marketplace crawling, executable deployment, schema-grounded synthesis, and trajectory materialization into a single workflow.

3. Filtration, dataset structure, and training protocol

MCP-Flow applies four filtration stages to maintain dataset quality (Wang et al., 28 Oct 2025). The first is embedding-similarity filtration: instruction–description pairs with cosine similarity above 0.8 are removed because they make tool selection trivial. The second is tool-invocation filtration: GPT-4o and DeepSeek-V3 are asked to identify the labeled tool from a set containing the labeled tool plus two random distractor tools; if both models fail, the sample is discarded. The third is quality-score filtration: DeepSeek-V3 acts as judge, and samples with quality score below 6/10 are removed. The fourth is trajectory filtration, applied more aggressively because tool responses can be invalid due to unavailable servers, API-key requirements, missing software, or temporary failures; invalid trajectories are discarded using DeepSeek-V3 as judge.

The resulting corpus contains 1,166 servers, 11,536 tools, 68,733 instruction–function call pairs, and 6,439 trajectories (Wang et al., 28 Oct 2025). The split counts are Train 52,169, Seen test 5,216, Unseen tool 5,249, and Unseen server 6,099. To avoid contamination, splitting is performed per marketplace: servers are first split 12:1 to create unseen-server; within seen servers, tools are split 11:1 to create unseen-tool; within the remaining data, a 10:1 split yields train and seen-test. The expected overall proportion is approximately 10:1:1:1 for train, seen-test, unseen-tool, and unseen-server.

The training configuration targets both open and closed models. Small open models are fine-tuned with LoRA using LLaMA-Factory and DeepSpeed ZeRO stage 0, typically for 1 epoch, with 10 candidate tools in the main experiments. Closed models are supported through retrieval augmentation. In that setting, the system retrieves the top-$k=5$ semantically similar samples using Sentence-Transformers embeddings and cosine-similarity ranking via Faiss-GPU (Wang et al., 28 Oct 2025).

The benchmark metrics reflect executable tool use rather than free-form plausibility. Tool accuracy measures whether the predicted tool name matches the ground truth. Parameter accuracy is defined as recursive comparison of parameter names with all-or-nothing evaluation and no positional alignment requirement. AST, adopted from BFCL, requires exact function-name match and valid parameter values. For agentic evaluation on GAIA, the paper reports success rate, average number of assistant messages, and Weighted Step, where step count is weighted by token pricing (Wang et al., 28 Oct 2025).

4. Empirical performance and effect on agentic behavior

The principal empirical claim is that MCP-Flow materially improves MCP tool selection and function-call generation (Wang et al., 28 Oct 2025). In the 10-tool setting, Qwen3-4B + MCP-Flow reaches 99.2 Tool / 91.8 Param / 81.2 AST on seen test, 98.6 / 91.4 / 78.2 on unseen tool, and 98.4 / 72.2 / 59.8 on unseen server. Llama3.1-8B + MCP-Flow reaches 98.6 / 91.0 / 81.6 on seen test, 99.0 / 91.2 / 77.6 on unseen tool, and 99.4 / 77.0 / 65.2 on unseen server. The paper states that strong closed models such as GPT-4o and Claude-4-Sonnet often remain below 60% AST accuracy on real-world MCP tools in some settings.

Performance degrades as the candidate tool set grows, but the degradation is less severe for MCP-Flow-trained models. In the 100-tool setting, averaged over three test splits, MCP-Flow (Qwen3-4B) reports 81.7 Tool / 82.1 Param / 67.0 AST, compared with GPT-4o at 72.3 / 66.9 / 53.8, Claude-4-Sonnet at 68.3 / 63.3 / 51.6, and ToolACE-8B at 60.9 / 51.9 / 35.9 (Wang et al., 28 Oct 2025). The paper also reports that tool accuracy saturates relatively quickly in scaling analysis, whereas AST continues to benefit from more data.

Retrieval augmentation improves closed models as well. MCP-Flow is used as a retrieval database for GPT-4o and Claude-4-Sonnet, and the paper reports consistent gains in function-call generation, especially for those two models (Wang et al., 28 Oct 2025). Even so, the retrieval-augmented closed models generally remain weaker than MCP-Flow-fine-tuned small models on unseen-server cases.

The same pattern appears at the agent level on GAIA. MCP-Flow is used to generate the initial function call for the agent, after which normal agent execution continues. Qwen3-4B improves from a base success rate of 10.68 to 21.36; GPT-4o improves from 29.13 to 33.98; Claude-4-Sonnet improves from 55.34 to 57.28 (Wang et al., 28 Oct 2025). The paper attributes these gains to increased tool-use tendency, reduced reliance on internal-knowledge-only answers, avoidance of wasted attempts on unavailable servers, and lower inference cost.

This evidence situates MCP-Flow as a training and initialization mechanism for large, real-world tool ecologies rather than a narrow function-calling benchmark.

5. Workflow orchestration, execution architectures, and evaluation of MCP-flow competency

The broader literature extends MCP-Flow from dataset construction to runtime architecture. A central systems observation is that current MCP hosts are context-heavy: every API call resends a large system prompt, tool schema, and interaction history, so prompt tokens dominate total usage (Ding et al., 20 Oct 2025). In a 90-day OpenRouter trace and a controlled benchmark using instrumented Cline v3.14.0, MCP-enabled workflows exhibit completion-to-prompt ratios that are 2x to 30x lower than general OpenRouter traffic. The same study recommends enabling parallel tool calls, reducing prompt serialization overhead, and implementing lightweight checkpointing, loop detection, and robust abort mechanisms because failed tool loops can produce runaway token growth (Ding et al., 20 Oct 2025).

One architectural response is the MCP Workflow Engine, which decouples intelligence from execution by compiling one-time agent reasoning into a declarative JSON workflow blueprint (Parmar, 13 Mar 2026). The engine formalizes the MCP Mediator pattern: an MCP server that simultaneously acts as a client to downstream MCP servers. It exposes create_workflow, run_workflow, list_workflows, get_workflow, validate_workflow, and delete_workflow, and supports five step primitives: call, loop, parallel, pipe, and collect. In evaluation on a Kubernetes CMDB synchronization task spanning 67 orchestrated steps across 2 MCP servers, 38 namespaces, 13 worker nodes, and 22 distinct resource types, the engine reduces per-execution token cost by over 99%, completes a full cluster graph comprising 1,200+ nodes and 2,800+ relationships across 20 relationship types in under 45 seconds, and achieves deterministic, idempotent execution with zero agent involvement at run time (Parmar, 13 Mar 2026).

A more radical variant is Code Execution MCP, or CE-MCP, which shifts orchestration from context to code (Felendler et al., 17 Feb 2026). Traditional MCP is described as context-coupled: tool metadata, user input, intermediate reasoning, and tool outputs all compete for the same context window. CE-MCP is context-decoupled: the agent discovers tools, generates a single executable program, and runs that program in an isolated runtime so that intermediate state remains in the sandbox and only the final result is returned. Using MCP-Bench across 10 representative servers, the paper reports that CE-MCP substantially reduces token usage, latency, and interaction turns, while also introducing a vastly expanded attack surface (Felendler et al., 17 Feb 2026).

Benchmarking work operationalizes MCP-flow competency directly. MCP-Atlas evaluates whether an agent can discover the right tools among distractors, parameterize them correctly, orchestrate 3–6 tool calls across multiple servers, and synthesize a final answer grounded in tool outputs (Bandi et al., 31 Jan 2026). The benchmark contains 36 real MCP servers, 220 tools, and 1,000 tasks, with a public 500-task subset. Tasks pass if claim-level coverage is at least 0.75, and the paper reports that Claude Opus 4.5 reaches a 62.3% pass rate and 78.5% mean coverage, while Tool Usage accounts for 56.7% of failed tasks on average and “No tools called” alone accounts for 36.0% of failures (Bandi et al., 31 Jan 2026).

World-model augmentation further extends the notion of flow from reactive execution to predictive planning. MCP-Cosmos integrates a generative World Model into the MCP agent loop through a Bring Your Own World Model strategy so that candidate tool actions can be simulated before real execution (Ganapavarapu et al., 9 May 2026). On 24 curated MCP-Bench tasks covering 2-server and 3-server scenarios and more than 300 trajectories, the paper reports that SPIRAL-Exec + gpt-oss-120b WM reaches 44.8% Overall, compared with 36.1% for ReAct baseline; the same work introduces Execution Quality and notes that many world-model agents score around 89–100, whereas the ReAct baseline scores 38.9 (Ganapavarapu et al., 9 May 2026).

Taken together, these results suggest that MCP-Flow is not only a data-generation program but also a design axis for how tool reasoning, control state, and execution authority are partitioned between model context, orchestration substrate, and runtime.

6. Security, governance, and unresolved issues

The security literature treats MCP-Flow as a primary attack surface. The privilege-management measurement study analyzes 2,562 real-world MCP applications spanning 23 functional categories and finds that network-resource threats affect 1,438 servers, system-resource threats affect 1,237, file-resource threats affect 613, and memory-resource threats affect 25 (Li et al., 5 Jul 2025). Developer Tools are the most API-intensive category with 626 total API calls, followed by API Development with 511 and Other with 497; the 0–10 star group contains 1,837 total API calls, far more than any higher-star group. The paper argues that MCP ecosystems lack a robust privilege model and calls for a privilege management framework, least-privilege API usage, comprehensive auditing, platform-adaptive access control, dynamic permission models, and automated trust assessment (Li et al., 5 Jul 2025).

The attack surface is not only operational but architectural. MCP-DPT organizes threats across six MCP layers—Model Provider / LLM Alignment, MCP Host / Application, MCP Client / SDK, MCP Server / Tool Execution, Transport / Network, and Registry / Marketplace Supply-chain—and maps 49 attacks to primary and secondary defense layers (Rostamzadeh et al., 8 Apr 2026). Its main empirical claim is that existing defenses are uneven and predominantly tool-centric. The paper notes that ToolHive achieves 100% registry coverage; MCP-Guardian and ToolHive each reach 50% server-execution coverage; MCIP-Guardian and MCP-Guard lead model-alignment coverage at 44%; and transport or network coverage is almost entirely absent, with MCP-Gateway as the notable exception at 50% (Rostamzadeh et al., 8 Apr 2026). This supports the claim that many MCP failures stem from architectural misalignment rather than isolated implementation bugs.

Static analysis of unsafe propagation gives the same conclusion at the code level. MCP-BiFlow recovers MCP-specific entrypoints, models request-side and return-side taint semantics, and performs bidirectional interprocedural taint analysis (Hou et al., 8 May 2026). Against 32 confirmed vulnerability cases, it identifies 30, for 93.8% recall, outperforming CodeQL, Semgrep, Snyk Code, and MCPScan. Across 15,452 real-world MCP server repositories, it produces 549 overlap-compressed candidate clusters; manual review confirms 118 vulnerability paths in 87 servers (Hou et al., 8 May 2026). The paper’s claim is that generic source-sink analyzers fail because they do not recover publication and dispatch patterns or treat protocol-visible returns as a trust boundary.

Cryptographic misuse constitutes an additional dimension of MCP-flow risk. MICRYSCOPE analyzes 9,403 MCP servers, identifies 720 with cryptographic logic, and reports that 19.7% of those exhibit misuses (Yan et al., 3 Dec 2025). The paper states that Smithery Registry has 42% insecure servers, Python has a 34% misuse rate, and Developer Tools plus Data Science & ML account for over 50% of all misuses. Case studies include leaked API keys, DES/ECB tools, and MD5-based authentication bypasses (Yan et al., 3 Dec 2025).

The MCP-Flow paper itself also lists practical limitations of data-driven tool mastery (Wang et al., 28 Oct 2025). API-key or personalized servers remain difficult to automate; software-specific servers can require manual installation; adversarial servers are a concern in public marketplaces; tool choice among similar tools remains difficult; and less formalized tool descriptions can cause execution failures. A plausible implication is that future MCP-flow research will need to combine large-scale training data with stronger runtime governance, provenance controls, and capability management rather than relying on description-level supervision alone.