Building Multi-Tool MCP Workflows: Advanced Patterns

I’ve been building production workflows with the Model Context Protocol (MCP) for 18 months now, starting with simple single-tool weather bots and working my way up to 12-step due diligence pipelines for venture capital firms. For those new to MCP, it’s an open standard that lets LLMs connect consistently to external tools, APIs, and data sources, so you don’t have to reinvent integration logic every time you add a new capability to your workflow. That consistency makes it easy to start building multi-tool pipelines, but the standard leaves most workflow design choices up to the developer— which is where most teams run into hidden complexity.

When I first started, I thought multi-tool workflows were just “call one tool, pass the output to the next, repeat.” It wasn’t until I shipped my first big client project that I learned how much complexity hides under the surface, and how specific patterns separate the 50% success rate proof-of-concepts from the 98% success rate production workflows. In this guide, I’ll walk through the advanced patterns I’ve tested and refined after fixing dozens of broken workflows, including practical tradeoffs for each approach, runnable code examples, and the embarrassing gotcha that taught me most of these lessons the hard way.

Chaining Multiple Tools: Linear vs Parallel Patterns

Chaining is the foundation of any multi-tool MCP workflow, but there’s more to it than just sequential calls. The two most common fixed chaining patterns are linear (sequential) and parallel (fan-out/fan-in), each with clear tradeoffs that fit different use cases.

Linear chaining runs one step at a time, where each step depends on output from the previous step. It’s simple to implement, easy to debug, and has predictable execution order that makes logging and error tracking straightforward. It’s the best choice for workflows where every step builds directly on the last, like processing a user support ticket: first pull the user’s account info, then pull their past tickets, then pull the current open ticket details, then generate a response. The downside? It’s slow when you have multiple independent steps that don’t need to wait for each other, adding unnecessary latency that can hurt user experience or slow down batch processing jobs.

Parallel chaining runs independent steps at the same time after a shared dependency, cutting end-to-end latency significantly. The tradeoff is higher complexity: you have to handle partial failures, avoid rate limit triggers, and sync state across multiple in-flight calls. When done right, it can cut total workflow runtime by half or more; when done wrong, it can get your API keys blocked and crash your entire pipeline.

Many teams new to MCP also ask about fully dynamic LLM-driven chaining, where the LLM decides what tool to call next after every step, rather than following a fixed pre-defined path. This is extremely flexible for open-ended tasks like research where you don’t know how many steps you’ll need ahead of time. For example, a due diligence workflow might add an extra step to pull patent data if the founder mentions a new proprietary technology in their background check. The tradeoffs here are significant, though: dynamic chaining can lead to infinite loops where the LLM calls the same tool repeatedly with no progress, it's harder to debug because the path changes every run, and it adds more LLM inference calls that increase cost and latency. I only use dynamic chaining for open-ended exploratory research workflows, and I always add a hard cap on the maximum number of steps (usually 15-20, which is more than enough for almost any use case) to prevent runaway costs and infinite loops. For most production business workflows with a clear expected output, fixed chaining patterns like linear or parallel are almost always more reliable and cheaper.

Below is a runnable example of both fixed patterns using the official MCP TypeScript SDK, for a workflow that pulls company data for investment analysis:

```typescript

import { Client } from "@modelcontextprotocol/sdk/client/index.js";

import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

import pLimit from 'p-limit';

// Initialize MCP client connected to our tool server

const client = new Client({ name: "mcp-workflow-demo", version: "1.0.0" }, {});

const transport = new StdioClientTransport({ command: "node", args: ["dist/tool-server.js"] });

await client.connect(transport);

// Cap concurrent calls at 3, leaving 2 extra slots for other workflows

const limit = pLimit(3);

// Linear chaining example: all steps run sequentially

async function runLinearChain(companyTicker: string) {

// Step 1: Get company profile first (need company ID for all other calls)

const profileResult = await client.callTool({

name: "get_company_profile",

arguments: { ticker: companyTicker }

});

const profile = JSON.parse(profileResult.content[0].text);

const companyId = profile.id;

// Step 2: Get income statement (depends on company ID)

const incomeResult = await client.callTool({

name: "get_income_statement",

arguments: { company_id: companyId, years: 5 }

});

const income = JSON.parse(incomeResult.content[0].text);

// Step 3: Get latest news (also depends on company ID)

const newsResult = await client.callTool({

name: "get_latest_news",

arguments: { company_id: companyId, days_back: 30 }

});

const news = JSON.parse(newsResult.content[0].text);

return { profile, income, news };

}

// Parallel chaining example: independent steps run after shared dependency

async function runParallelChain(companyTicker: string) {

// Step 1: Still sequential, because we need company ID for all other calls

const profileResult = await client.callTool({

name: "get_company_profile",

arguments: { ticker: companyTicker }

});

const profile = JSON.parse(profileResult.content[0].text);

const companyId = profile.id;

// Step 2: Run independent steps in parallel with concurrency control

const [incomeResult, newsResult] = await Promise.all([

limit(() => client.callTool({

name: "get_income_statement",

arguments: { company_id: companyId, years: 5 }

})),

limit(() => client.callTool({

name: "get_latest_news",

arguments: { company_id: companyId, days_back: 30 }

}))

]);

const income = JSON.parse(incomeResult.content[0].text);

const news = JSON.parse(newsResult.content[0].text);

return { profile, income, news };

}

```

In my testing, this simple change to parallelize two independent steps cut end-to-end latency by 42% for this workflow. But I learned the hard way about the hidden tradeoffs: I once got an API key blocked for 2 hours after I parallelized 10 concurrent calls to the SEC EDGAR API, which had a documented 5 concurrent request limit I forgot to respect. The fix is simple: add a concurrency limiter to cap parallel calls to stay under your API’s rate limit, which I already included in the example above. The only tradeoff here is a tiny increase in latency compared to unconstrained parallelism, which is a tiny price to pay to avoid getting locked out of your API for hours. I always cap parallel concurrency at 70-80% of the documented rate limit to leave headroom for other workflows sharing the same API key.

Conditional Tool Execution: Explicit vs LLM-Guided

Most complex workflows don’t follow a fixed path. You only need to call a specific tool if a previous step meets a condition: if a company is private, pull private revenue estimates instead of public financials; if news sentiment is negative, run a regulatory search; if a founder has a history of failed startups, pull additional background on their previous ventures.

There are two common approaches to conditional execution, each with clear tradeoffs:

1. **Explicit code conditionals**: Use hard-coded logic to check structured output from previous steps and pick the next tool. This is 100% consistent, fast, requires no extra LLM call, and is easy to test. The downside is it can’t handle fuzzy, unstructured conditions that rely on subjective judgment.
2. **LLM-guided conditionals**: Ask the LLM to evaluate a condition and decide whether to run the next tool. This is flexible enough to handle fuzzy conditions like “do these news articles mention a leadership scandal that would impact investment risk?” The downside is it adds an extra LLM inference call, adds cost and latency, and has a small chance of inconsistent classification or hallucination.

My rule of thumb is to use explicit conditionals whenever the condition can be captured with structured data. If you have a clear `is_public` boolean on your company profile, use an explicit `if/else` to pick the right financial tool. Only use LLM-guided conditionals when the condition is unstructured and can’t be easily hard-coded. I also always add a default case for LLM-guided conditionals: if the LLM returns something unexpected (like “mixed” when you asked for three options), fall back to a safe default instead of crashing the whole workflow. For example, I almost always default to running the extra step when the output is unclear, rather than skipping it, because missing a red flag is almost always worse than adding a few minutes of processing time.

Below is a runnable example combining both approaches:

```typescript

async function runConditionalWorkflow(companyTicker: string) {

const profileResult = await client.callTool({

name: "get_company_profile",

arguments: { ticker: companyTicker }

});

const profile = JSON.parse(profileResult.content[0].text);

let financialData;

// Explicit conditional: clear boolean flag from structured profile data

if (profile.is_public) {

const result = await client.callTool({

name: "get_income_statement",

arguments: { company_id: profile.id, years: 5 }

});

financialData = JSON.parse(result.content[0].text);

} else {

const result = await client.callTool({

name: "get_private_revenue_estimates",

arguments: { company_id: profile.id, years: 3 }

});

financialData = JSON.parse(result.content[0].text);

}

// LLM-guided conditional: fuzzy sentiment check for unstructured news data

if (profile.latest_news_preview) {

const sentimentEval = await client.complete({

prompt: `Evaluate the overall sentiment of these news articles about ${profile.name}: ${profile.latest_news_preview}. Only answer "positive", "neutral", or "negative".`

});

const sentiment = sentimentEval.completion.trim().toLowerCase();

// Only call regulatory search if sentiment is negative, default to run on unexpected output as a safety precaution

if (sentiment === "negative" || !["positive", "neutral"].includes(sentiment)) {

const regulatoryData = await client.callTool({

name: "search_regulatory_filings",

arguments: { company_name: profile.name, months_back: 12 }

});

financialData.regulatory_issues = JSON.parse(regulatoryData.content[0].text);

}

}

return { ...profile, financial_data: financialData };

}

```

I’ve had my own share of mistakes with LLM-guided conditionals: I once had an LLM classify 3 neutral news articles as negative because one mentioned the company missed a minor revenue target that was already priced into the stock, leading to an unnecessary 10-minute regulatory search that doubled the cost of that workflow. That’s a tradeoff I always weigh now: the flexibility of LLM-guided conditionals comes with a small but consistent risk of incorrect classification, so I only use it when there’s no better alternative.

Error Recovery Patterns for Production

Most multi-tool MCP workflows fail not because of bad logic, but because they don’t handle inevitable tool errors. Transient errors like rate limits, network timeouts, and 500 errors are common, and even permanent errors can be worked around with the right pattern. I’ve never shipped a production workflow that doesn’t use at least two of these four core error recovery patterns, each with clear tradeoffs:

1. **Retry with exponential backoff for transient errors**: Retry only temporary failures, not permanent errors like invalid API keys or bad input. Tradeoff: too many retries increase latency and can make rate limiting worse.
2. **Fallthrough to alternative tools**: If your primary tool fails, use a secondary backup tool. Tradeoff: you have to maintain multiple integrations, and backup tools are often more expensive or less accurate than the primary.
3. **Fail open vs fail closed**: Fail open means if an optional step fails, proceed with partial results. Fail closed means stop the entire workflow if any step fails. Tradeoff: fail open gives better user experience for non-critical workflows, but can produce incomplete or low-quality outputs. Fail closed is better for compliance or financial workflows where bad data is worse than no data.
4. **Step-level rollback**: For write workflows (like updating a CRM or creating support tickets), roll back completed steps if a later step fails. Tradeoff: adds significant complexity, and requires all tools to be idempotent (safe to run multiple times without creating duplicates).

I only implement step-level rollback for write workflows that touch production systems; for read-only research workflows like due diligence, it’s never worth the extra complexity. For fail open/fail closed, I set it per step, not per workflow: in a due diligence workflow, the company profile step is required (fail closed, because nothing works without it), but the latest news step is optional (fail open, because you can still generate a useful summary without it). For compliance-focused clients, I even set financial data steps to fail closed no matter what, because including inaccurate financial data can create legal risk that’s far worse than delaying the report.

Below is a runnable implementation of retry with recovery and fallback that I use in production:

```typescript

import { exponentialBackoff } from "exponential-backoff";

async function callToolWithRecovery<T>(

client: Client,

toolName: string,

args: Record<string, unknown>,

fallbackToolName?: string,

maxRetries = 3,

failOpen = false

): Promise<T | null> {

try {

const result = await exponentialBackoff(

async () => {

const res = await client.callTool({ name: toolName, arguments: args });

// Handle MCP standard error format

if (res.isError) {

const errorMsg = res.content[0].text as string;

// Only retry transient errors

if (errorMsg.includes("rate limit") || errorMsg.includes("timeout") || errorMsg.includes("500")) {

throw new Error(errorMsg); // Trigger retry

}

// Don't retry permanent errors

throw new Error(`Permanent tool error: ${errorMsg}`);

}

return res;

},

{ numOfAttempts: maxRetries, startingDelay: 1000 }

);

return JSON.parse(result.content[0].text) as T;

} catch (error) {

// Fall back to backup tool if primary fails after all retries

if (fallbackToolName) {

console.warn(`Primary tool ${toolName} failed, falling back to ${fallbackToolName}: ${(error as Error).message}`);

const fallbackResult = await client.callTool({ name: fallbackToolName, arguments: args });

if (!fallbackResult.isError) {

return JSON.parse(fallbackResult.content[0].text) as T;

}

}

// Return null for fail open, rethrow for fail closed

if (failOpen) return null;

throw error;

}

}

// Usage example

async function runResilientCompanyWorkflow(companyTicker: string) {

// Required step: fail closed

const profile = await callToolWithRecovery(

client,

"get_company_profile",

{ ticker: companyTicker },

"get_alternative_company_profile"

);

// Optional step: fail open

const news = await callToolWithRecovery(

client,

"get_latest_news",

{ company_id: profile.id, days_back: 30 },

"get_news_alternative",

3,

true

);

return { profile, news };

}

```

This pattern cut my workflow failure rate by 70% after I implemented it. The key tradeoff I’ve found is that filtering errors to only retry transient ones is non-negotiable: I used to retry everything, and once had a workflow retry an invalid API key error 10 times, adding 30 seconds of unnecessary latency before failing. Filtering errors takes 10 extra lines of code, and it eliminates almost all of that useless latency.

State Management Across Calls

MCP is designed to be stateless by default, which means each tool call is independent. For multi-step workflows, that means you have to manage state yourself to track completed steps, store intermediate results, and feed context to the LLM for each step. There are three common state management patterns, with clear tradeoffs:

1. **In-memory state**: Store state in the process memory for short-lived workflows. Pros: no extra infrastructure, simple to implement. Cons: loses state if the process crashes, can’t resume, doesn’t work for long-running workflows or distributed systems.
2. **Persisted state**: Store state in an external store like Redis or a database. Pros: survives restarts, can resume partial workflows, works across multiple workers. Cons: adds infrastructure complexity, adds latency from database calls, requires state versioning for workflow changes.
3. **Incremental context pruning**: As you add more results to the context window after each step, the context can grow to exceed the LLM’s token limit, increasing cost and causing errors. Pruning removes old, irrelevant context to keep the total size under the limit. Pros: avoids token limit errors, reduces cost. Cons: pruning too aggressively can remove critical context, leading to bad outputs.

I never use in-memory state for any workflow that runs longer than 10 seconds, for reasons I’ll cover in the gotcha below. For pruning, I use a simple rule that reduces the risk of losing critical context: always keep the original user query and the output of core required steps, and only prune redundant verbose data like duplicate news entries or extra financial line items. I also never delete raw data from state, even if I prune it from the context window— if the LLM needs it later, I can always pull it back into context.

Below is a runnable example of persisted incremental state management with pruning that I use in production:

```typescript

import Redis from "ioredis";

import { countTokens, truncateTokensFromStart } from "gpt-tokenizer";

// Initialize Redis for persisted state

const redis = new Redis(process.env.REDIS_URL);

// Get or initialize workflow state, with versioning for migrations

async function getWorkflowState(workflowId: string) {

const stored = await redis.get(`mcp-workflow:${workflowId}`);

if (stored) {

const parsed = JSON.parse(stored);

// Migrate old state schemas if needed when you update your workflow

if (!parsed.version) {

parsed.version = 2;

parsed = addMissingFieldsToOldState(parsed);

}

return parsed;

}

return {

version: 2,

currentStep: "start",

completedSteps: [],

results: {},

context: ""

};

}

// Save updated state with context pruning

async function saveWorkflowState(workflowId: string, state: any, maxContextTokens = 120000) {

const currentTokens = countTokens(state.context);

if (currentTokens > maxContextTokens) {

// Keep only the most recent 80% of the limit, preserve the original query at the start

const keepTokens = Math.floor(maxContextTokens * 0.8);

const originalQuery = state.context.split("\n---")[0];

const prunedContext = truncateTokensFromStart(state.context, keepTokens);

// Reattach the original query so it's never pruned

state.context = `${originalQuery}\n\n${prunedContext}`;

}

// Expire after 1 day to clean up old workflows and avoid filling Redis

await redis.set(`mcp-workflow:${workflowId}`, JSON.stringify(state), "EX", 86400);

}

// Usage in workflow

async function runResumableWorkflow(workflowId: string, companyTicker: string) {

let state = await getWorkflowState(workflowId);

if (!state.completedSteps.includes("get_profile")) {

state.results.profile = await callToolWithRecovery(

client,

"get_company_profile",

{ ticker: companyTicker }

);

state.context += `\n--- Step 1 (Company Profile) ---\n${JSON.stringify(state.results.profile)}`;

state.completedSteps.push("get_profile");

await saveWorkflowState(workflowId, state);

}

// Additional steps follow the same pattern, only running if not already completed

return state;

}

```

This pattern works for both short and long-running workflows, and the overhead of saving state after each step is negligible for most use cases. The state versioning step is something I added after running into issues with outdated state schemas breaking resumable workflows when I pushed updates, and it’s saved me dozens of support hours.

My Big Gotcha: The Night I Learned All These Patterns

Ten months ago, I built my first production multi-tool MCP workflow for a VC client that needed to do end-to-end due diligence on 20 early-stage startups for a partner screening round. I tested it with 10 sample startups, it worked perfectly every time, I deployed it, and the client kicked off the 20 workflows before leaving for the day.

Halfway through the run, 12 of the 20 workflows disappeared entirely. No error message, no log, nothing. I got a panicked Slack at 8pm from our customer success manager saying the client had a partner meeting at 9am the next day, and if we didn’t deliver the summaries, they were going to cancel their $50k/year contract. I spent 4 hours panicking and debugging, and finally figured out what happened: I’d used in-memory state for all workflows, and our cloud provider had auto-scaled down the server during a low traffic period, killing all running processes. All partial work was lost.

That wasn’t even the worst part. When I restarted the workflows, I’d forgotten to add a concurrency limiter to the 10 parallel founder background calls per workflow, which triggered the LinkedIn API’s rate limit, so all 12 workflows failed immediately after restart. I ended up staying up all night, writing a quick hack to persist state to a local file on my laptop, adding a manual concurrency limiter that ran one workflow at a time, and checking each one for errors until 5am. I delivered the final summaries 2 hours before the client’s meeting, but I didn’t sleep for almost 24 hours, and I was so wired I couldn’t sleep even after the meeting ended.

I showed up to the 7am sync with the client, red-eyed and running on gas station coffee, ready to apologize for the delay. To my surprise, the client was impressed that we’d delivered on time even after the outage, and they ended up expanding their contract with us six months later. That said, I never want to repeat that experience, so every new workflow I build now goes through a checklist that’s directly pulled from that failure. That night of sleep loss taught me more about building production MCP workflows than 6 months of testing. The core lessons from that failure are exactly the patterns I’ve shared in this article: never use in-memory state for any workflow that runs longer than a minute, always add concurrency limits for parallel calls, always persist state after every completed step so you can resume, and always add error recovery for rate limiting. I’ve never had that kind of failure since, because I now build all my workflows with these patterns baked in.

Full Real-World Example: VC Due Diligence Workflow

After that failure, I rebuilt the workflow using all the patterns above. The final end-to-end workflow combines chaining, conditional execution, error recovery, state management, and performance optimization, and has a 98% success rate in production today. One pattern I added that’s cut my workflow cost and latency by 35% on average is caching repeated tool calls. Most multi-tool workflows reuse common data: if you’re doing due diligence on 20 startups in the same sector, you’ll often pull the same founder background data or market