Agentic AI Design Patterns Using MCP Tool Calls

Discovery is the precondition for everything that follows. An agent cannot plan, parallelize, or reflect until it knows what tools exist and, more importantly, what those tools can actually do.

Here is what the initialization sequence actually looks like: the agent calls tools/list, the server returns metadata including names and natural-language descriptions, those descriptions are loaded into the agent's context, and from that point forward the agent issues tools/call with arguments matching the schema. Simple on the surface. The complexity is buried in one place most teams don't take seriously until they've shipped something that misfires repeatedly.

Those natural-language descriptions are not documentation. They are the signal the model reasons against when deciding which tool to call and with what arguments. I've watched teams spend weeks tuning prompts and model parameters while leaving their tool descriptions as first-draft placeholders. The tool descriptions were the actual problem. Vague descriptions produce worse calls in ways that are maddeningly difficult to attribute because the failures look like model errors, not schema errors.

There is one inversion worth understanding because it regularly surprises people: MCP supports server-side sampling, meaning a server can proactively request an LLM completion from the client. The server initiates, not the agent. This allows tool-side logic to involve LLM reasoning without the orchestrating agent being aware it is happening. Powerful, yes. Also a reliable source of opacity in systems where nobody thought to look for it.

The fundamental decision the agent makes in every cycle is: given the current goal and the available tool list, which tool, with which arguments, right now? Everything below is really a different policy for answering that question, in different orders, with different degrees of planning, and with different responses to whatever the tool returns. The tool call itself is the constant. The policy is what varies.

The basic tool-use loop: ReAct and what it looks like in MCP

ReAct is not complicated. Thought, action, observation. Repeat until an exit condition fires: a conclusive answer is reached, a maximum iteration count is hit, or an unrecoverable error terminates the loop.

In MCP terms, each "Action" is a tools/call. Each "Observation" is the tool result the server returns. The "Thought" is the reasoning the model produces before committing to the next call. The pattern was originally a 2022 prompting technique, and its mapping onto MCP's tools primitive is almost perfectly clean, which is why it remains the default starting point for most teams.

Why does it exist at all? Because models hallucinate tool actions and fabricate outputs when reasoning and action aren't separated. Interleaving observation with reasoning keeps the agent grounded in what actually happened rather than what it predicted would happen. That grounding is the functional value, and it is easy to underestimate until you've watched an agent confidently proceed through five steps based on an observation it invented.

One thing the tutorials don't tell you: verbose chain-of-thought reasoning is often stripped in production for latency reasons, not for correctness. The reasoning still happens; it is just less narrated. You are paying for those reasoning tokens whether they appear in a log or not. This surprises teams when they first look at their inference bills.

The cost structure is worth being direct about. Each reasoning loop requires an additional model call, so latency and cost grow linearly with loop depth. And if one tool result is wrong or malformed, that error enters the reasoning context and can cascade. A bad observation at step two can quietly corrupt everything from step three onward, and the model will proceed with total confidence.

ReAct is not a workflow. It is the baseline reasoning discipline from which workflows are composed. Its cost structure is precisely what motivates every pattern that comes after.

When you know the plan upfront: ReWOO and fixed-sequence tool calls

ReWOO makes a specific bet: if you know the plan before you start, you do not need to reason between steps. A Planner produces the full tool-call sequence upfront; Workers execute it without interleaved reasoning; the "Thought" tokens between calls disappear. Token reduction is dramatic, often cutting usage by five to ten times compared to an equivalent ReAct trace, according to the original research.

In MCP terms, the Planner produces a sequence of tools/call invocations at planning time. Execution from that point is deterministic. No re-inspection of tools/list mid-run. The plan is the plan.

This is the right pattern for high-confidence, repeatable workflows: batch data analysis, structured report generation, any high-throughput pipeline where the tool landscape is stable and the task structure is well understood before deployment. The throughput advantages are real and measurable.

The fragility is equally real. If the Planner's initial sequence is wrong, there is no self-correction mechanism. A wrong plan executes completely and incorrectly, or hard-fails partway through. ReWOO does not forgive surprises, and depending on what your tools actually do, that is not a theoretical problem.

The engineering implication that matters most: ReWOO moves risk from runtime to design time. Thorough pre-deployment testing of tool schema contracts is not a best practice here; it is the actual safety mechanism. Because there is no in-loop reasoning to catch a bad tool result before it propagates, guardrails at the tool-result boundary become essential. You are checking outputs at the edge, rather than relying on the agent to notice something went wrong.

Running tool calls in parallel: the fan-out pattern and its latency payoff

Fan-out is the pattern that becomes obvious once you have tasks that are genuinely independent of each other. A coordinator dispatches multiple tools/call invocations simultaneously, then aggregates results when all branches return. Wall-clock latency is bounded by the slowest branch, not the sum of all branches. That is the entire value proposition.

MCP's stateful session model supports this naturally: each parallel call maintains its own session state independently. The coordinator is not managing shared mutable state across branches; each branch is isolated from the others.

Two distinct shapes appear in practice. One sends the same task to multiple servers for redundancy or consensus, useful when result reliability matters more than cost. The other dispatches N different specialized subtasks simultaneously, which is more common. A research workflow querying a document store, a structured database, and an external API at the same time is the canonical example of the second shape.

Fan-out breaks in predictable places. Branches with dependencies on each other cannot run in parallel; the pattern requires genuine independence, and discovering mid-implementation that your subtasks are actually interdependent is an unpleasant surprise that I have seen delay production deployments by weeks. Aggregation logic is also non-trivial when branches return conflicting or heterogeneous results. And the coordinator's wait strategy matters more than most teams realize: fail-fast and partial-result aggregation are fundamentally different correctness postures, not just different latency tradeoffs.

Orchestrating multiple agents through MCP: the supervisor pattern at scale

The supervisor pattern places a central orchestrator at the top of the hierarchy. The orchestrator receives the goal, decomposes it into subtasks, delegates to specialized worker agents, and aggregates their outputs. Each worker is itself an MCP-connected agent, calling its own tools against its own servers within its own session.

At small scale this is elegant. At production scale, two problems emerge with reliable regularity.

The context window problem first. At four or more workers, accumulated context frequently exceeds model window limits. This is not an edge case; it is an architectural constraint you can plan for if you acknowledge it exists before you're staring at it in production. Mitigations include summarization at the worker boundary before results are returned, selective context passing, and hierarchical aggregation where sub-orchestrators manage subsets of workers. None of these is free, and each introduces its own failure surface.

Then cost scaling. Workflows that appear inexpensive in testing can become substantially more expensive at production volume, because the orchestrator makes multiple LLM calls on top of every worker call: decomposition, delegation, and aggregation each consume tokens. The compounding effect at high execution volumes is worth modeling before you commit to the architecture, not after.

Pinterest's 2026 MCP deployment illustrates the pattern at enterprise scale: approximately 66,000 monthly tool invocations from 844 active users, domain-specific servers for data platforms including Presto, Spark, and Airflow, a central registry for server discovery, and human-in-the-loop approval for high-risk operations. Block's deployment shows a different shape: their open-source Goose agent connecting to Snowflake, GitHub, Jira, Slack, Google Drive, and internal APIs, with employees reporting 50 to 75 percent time savings on common tasks.

The registry detail in the Pinterest deployment is easy to skip over and genuinely important. Every MCP server a worker uses needs a registry entry the orchestrator can reason about. An unregistered server is an identity the orchestrator cannot account for and cannot govern. That gap tends to stay invisible until something goes wrong.

Sequential pipelines and when a fixed order is the right answer

A sequential pipeline executes agents or tool calls in a predefined linear chain. Each step consumes the previous step's output. Order is fixed at design time. In MCP terms, tool calls are issued one at a time in a specified sequence, shared state passes between steps, no branching, no parallel dispatch.

The canonical use case is document processing: parse, extract, validate, summarize. Each step has a clear input contract, and the output of one step is the only valid input to the next. The structure matches the problem's natural topology, which is precisely why it works.

Sequential pipelines survive in production alongside far more sophisticated patterns for reasons that become obvious after you've spent time debugging something more complex. Deterministic ordering makes debugging tractable; you always know which step produced a given intermediate result. Each tool schema acts as a typed interface between steps, and if the schema is well-designed, failures are localized rather than propagating silently. Operational cost is predictable in a way that orchestrator-worker patterns simply are not.

The failure modes are symmetric with these strengths. A step that produces invalid output breaks all downstream steps with no self-correction. Any task where step order cannot be determined at design time needs a more adaptive pattern; forcing a sequential pipeline onto an ambiguous problem produces a system that fails precisely on the cases that matter most.

Sequential pipelines are often the right starting point before teams reach for orchestration. The upgrade path is well-defined. The path back down, from a complex orchestrator to a pipeline, is expensive in ways that are hard to anticipate until you're already committed.

Using MCP tool calls to implement self-correcting agents through reflection

Reflection is the pattern where an agent evaluates its own output. After producing a result, the agent enters a critic mode: it assesses the work against explicit criteria, identifies deficiencies, and produces a revised version. The critic can be the same model operating under a different prompt, or a separate agent with a specialized evaluation role.

What makes MCP-based reflection different from pure chain-of-thought self-critique is concrete and consequential: the critic agent can itself issue tool calls. It can validate a generated SQL query against a live schema. It can check a file's content against a specification. It can run a test and observe whether it passes. Reflection is not purely internal reasoning; it can be grounded by actual external state. That grounding is what makes the result trustworthy rather than merely plausible, and it is a meaningful distinction when the output is going somewhere that matters.

In multi-agent architectures, a reflection step is often placed after a worker completes and before results are passed to the orchestrator. This localizes quality control. Catching a worker error at the boundary is substantially better than letting the orchestrator discover it after aggregation, when identifying the source becomes a real exercise.

The cost consideration is unavoidable. Reflection adds at least one additional model call, often two if critique and revision are treated as separate passes. It should be reserved for outputs where quality failure has high downstream cost. Applying it uniformly regardless of output criticality is a direct path to unsustainable inference costs, and I have seen teams learn this the hard way after a surprisingly large bill.

The layering that works: controls at the tool-result layer before the critic sees the result, and controls at the output layer after reflection completes. These are two distinct checkpoints. Neither substitutes for the other. A bad tool result the critic never examines, and a revised output that passes reflection but fails a downstream schema check, are different failure modes requiring different mitigations.

Human-in-the-loop as an active interrupt in MCP workflows, not a final approval gate

The conventional mental model of human-in-the-loop is a gate at the end: the agent completes its work, a human reviews the output, approves or rejects. That model is insufficiently dynamic for MCP-connected agents operating in complex, stateful environments. The more accurate framing is the interrupt: a signal that fires mid-execution when the agent encounters a constraint it cannot resolve autonomously.

Three distinct invocation scenarios appear in production. Ambiguity resolution: the agent discovers mid-task that the goal is underspecified, and rather than proceeding on an assumption that turns out to be wrong, it surfaces the ambiguity and waits for clarification. Risk escalation: the agent is about to execute a high-consequence, irreversible tool call, and it is configured to require human authorization before proceeding. Pinterest's deployment is instructive here; high-risk operations required approval as a matter of explicit policy, not as a fallback for edge cases. Error recovery: the agent has received a tool result it cannot interpret or act on, and autonomous retry strategies have been exhausted.

What these three scenarios share is timing. The interrupt fires during execution, not after. This distinction matters because an agent that completes a long workflow and then presents its output for human review has already taken all the intermediate actions. Those actions are logged. Some are reversible. Some are not. The interrupt model preserves optionality at the moment when it is actually most valuable.

The practical implementation question is how the agent communicates the interrupt without blocking the entire system indefinitely. In MCP-connected workflows, this typically means the agent writes its current state and the nature of the interrupt to a durable store, signals the human through whatever notification mechanism exists, and resumes when a response is received. The session state that MCP maintains becomes the continuity mechanism. The agent picks up where it left off rather than restarting from scratch.

The deeper point is that human judgment and agent execution are not sequential stages. They are concurrent resources the workflow can invoke at different points for different reasons. Treating human-in-the-loop as a final approval gate is appropriate for low-stakes workflows. For anything operating in production with real consequences, the interrupt model is more honest about what autonomous agents actually need and when they need it.