Master Prompts vs. Multi-Agent + MCP Pipelines

What MCP and multi-agent pipelines actually do

MCP (Model Context Protocol) is an open standard — originally from Anthropic — for connecting AI models to external tools. It runs over JSON-RPC 2.0: the model requests a tool call, the host application forwards it to the MCP server, the server executes it and returns the result, and the model reads that result and decides what to call next. Tools can be databases, APIs, file systems, search engines, or custom services.

A multi-agent pipeline layers orchestration on top: one AI model (the orchestrator) decides which sub-agents to invoke, those agents call their own tools via MCP, pass results back up, and the orchestrator assembles a final answer. It's powerful for genuinely open-ended tasks — but every layer costs tokens and adds a failure point.

Token cost is where this compounds. By default, the host application puts every connected MCP tool's full schema into the model's context on every inference call — name, description, parameter types, the works. Ten tools means ten schemas in context whether the model uses them or not. Experienced teams mitigate this with tool filtering (scoping which schemas are exposed per request) or deferred loading, where the model searches for tools and only the ones it needs are loaded. Both genuinely work, but now you're maintaining that routing logic on top of the pipeline you already built. Without it, the overhead is real and measurable — especially once you're running multiple agents, each with their own tool sets.

Estimates based on typical unoptimized production pipelines with 3 agents and 8–12 MCP tools. Tool filtering can reduce schema overhead; orchestrator and routing costs remain.

When multi-agent + MCP is genuinely the right choice

Pipelines earn their place. There are tasks where the overhead is worth every token:

• Input too large for one context window: Even with context windows of up to 1M tokens, large document corpora, codebases, or multi-source aggregations may not fit. Chunking across calls or agents is the right solution.

• The AI must decide what step comes next: Conditional branching can be pre-defined — if X, call tool A, else call tool B. Genuine agency is needed only when the branch conditions themselves can't be anticipated at design time: the model encounters something unexpected and reasons its way to the next step.

• Parallel work that has to be coordinated: Many sub-tasks running at once whose results depend on each other or must be merged mid-run. Independent work — 50 separate reports — doesn't need this: run the same master prompt 50 times concurrently.

• Iterative refinement by design: A write → critique → revise loop where each pass reads the previous output. That's inherently multi-step.

If your task genuinely hits one of these, build the pipeline. The question is whether you've checked first.

What most production AI features actually look like

Customer risk reports. Compliance summaries. Course outlines. Supplier evaluations. Email personalizers. Product descriptions. The majority of AI features shipped in production follow the same pattern: structured input goes in, structured output comes out, and the shape of that output can be described as a JSON schema before the AI ever runs.

Those tasks don't require an orchestrator to decide what to do. They don't need MCP tools to fetch data — the app already has the data. The developer already knows what variables are needed and what the output should look like. That knowledge belongs in the prompt, not in an agent loop.

What's inside a CyWire master prompt

A CyWire master prompt downloads as a single JSON file. When your server loads it, everything needed to run the feature is already there:

{
  "full_prompt_text": "You are a financial risk analyst...\n\nClient: {account_name}\nIndustry: {industry}\nRisk score: {risk_score}\n---\n[task instructions, output format, quality guardrails, constraints]",

  "variables": {
    "account_name": { "type": "string", "required": true },
    "industry":     { "type": "enum",   "required": true, "options": ["finance","healthcare","retail",...] },
    "risk_score":   { "type": "number", "required": true, "validation": { "min": 0, "max": 100 } },
    "notes":        { "type": "string", "required": false }
  },

  "output_schema": {
    "type": "object",
    "properties": {
      "risk_level":          { "type": "string", "enum": ["low","medium","high","critical"] },
      "summary":             { "type": "string" },
      "risk_factors":        { "type": "array",  "items": { "type": "string" } },
      "recommended_actions": { "type": "array",  "items": { "type": "string" } }
    },
    "required": ["risk_level","summary","risk_factors","recommended_actions"]
  },

  "schema_strict": true,
  "metadata": { "version_number": 4 }
}

The full_prompt_text is a fully assembled system prompt — six structured sections (identity, industry context, task instructions, output format, quality and safety rules, constraints) joined together, with {variable} slots for runtime data. buildPrompt() runs entirely on your server: it validates required variables against the type definitions, fills the slots with your actual values, and catches any unresolved placeholders before anything reaches the AI.

What gets sent to the AI provider is the compiled prompt text (with variables substituted in), the output schema via output_config, and nothing else. The variable type definitions, validation rules, and version metadata stay local. The version number gets saved with the result in your own database — so every generated record stays traceable to the exact prompt that produced it.

Token cost: same task, two approaches

A complete master prompt JSON can run 50–70K characters — variable type definitions, validation rules, schema, examples, metadata. Most of that never reaches the LLM. What your AI provider actually receives is only the compiled full_prompt_text: buildPrompt() fills the {variable} slots with your runtime data and passes only that resolved text plus the output schema. The full_prompt_text alone is typically 14–20K characters — roughly 4,000–6,000 tokens of actual task content sent to the LLM. A multi-agent pipeline for the same task spends that much on infrastructure before any task content even loads:

The entire master prompt call — full feature spec, your runtime data, structured output — costs roughly what a pipeline's routing overhead alone costs before any actual work starts. And unlike pipeline context that accumulates across agent hops, this is a clean slate every time.

Why splitting one document across agents drifts

Token count isn't the only cost of breaking content into steps. When a report, course, or proposal is built section by section — one agent or one call per section — every new section needs the sections before it. Without them, it loses the direction set at the start: tone shifts, terms get redefined, facts contradict earlier ones, and the goal drifts.

So each step has to carry everything above it, and the load grows the further down the chain you go. Section six needs sections one through five plus the original brief. Summarizing earlier sections cuts tokens, but every summary drops detail — and lost detail is exactly where drift starts.

That's why a CyWire master prompt compiles the full brief — every section's instructions, rules, and your data — and sends it in a single pass. The model sees the whole picture once and writes every section against it: fewer tokens, and sections that stay consistent with each other. The limit is output length: if the finished document is longer than one response allows, split it and pass the earlier sections forward.

Latency, consistency, debugging — how else they differ

Where a single prompt isn't enough

A master prompt is single-pass by design. For most tasks that's exactly what you want. For a few, it's a real constraint:

• Input exceeds context limits: Current models support context windows of up to 1M tokens, which covers most real-world inputs. But large codebases, long document collections, or multi-source aggregations can push past that. Chunking across multiple calls is the right move.
• The task is genuinely open-ended: If the AI needs to evaluate intermediate results and decide what step comes next, that's agent territory. The line: if the developer can pre-define the steps, that's a prompt. If the AI has to figure them out, it's an agent.
• Coordinated parallel work: Each master prompt call handles one task. Running many calls concurrently against the same prompt works fine — but if those analyses need shared state or have to coordinate mid-run, an agent framework handles that better.
• Iterative refinement is the point: If the output of one AI call must feed into the next — a critique loop, a revision cycle — that's inherently multi-step. Two sequential master prompts (generate, then critique) is often simpler than a full pipeline, but it's still two calls.

When you do build a pipeline: master prompts slot in

If your task genuinely requires an MCP server or agent pipeline, CyWire master prompts compose into it cleanly. The master prompt becomes the instruction layer for what a specific MCP tool does — tested prompt text, typed variables, and output schema drop directly into the tool handler. The pipeline handles connectivity and routing; the master prompt defines what the LLM is told to do and what structured data comes back.

The promptVersion returned from buildPrompt() should travel with every result. When a prompt is updated, you can trace exactly which version produced which output — even across a multi-step agent run.

import { z } from 'zod'
import { buildPrompt } from '../ai/prompt'
import { PROMPTS } from '../ai/prompt-registry'

// MCP tool: master prompt is the AI instruction layer
server.registerTool(
  'analyze-customer-risk',
  {
    description: 'Generate a structured customer risk report',
    inputSchema: { account_name: z.string(), risk_score: z.number(), industry: z.string() },
  },
  async (input) => {
    // buildPrompt validates variables, fills {slots}, catches anything missed
    const { promptText, promptVersion, outputSchema } =
      await buildPrompt(PROMPTS.riskReport, input)

    const res = await fetch('https://api.anthropic.com/v1/messages', {
      method: 'POST',
      headers: {
        'x-api-key': process.env.ANTHROPIC_API_KEY!,
        'anthropic-version': '2023-06-01',
        'content-type': 'application/json',
      },
      body: JSON.stringify({
        model: 'claude-sonnet-5-5',
        max_tokens: 16000,
        system: promptText,
        messages: [{ role: 'user', content: 'Return only the structured JSON result.' }],
        output_config: { format: { type: 'json_schema', schema: outputSchema } },
      }),
    })

    const data = await res.json()
    // Thinking can run first; read the text block, not content[0]
    const text = data.content.find((block: { type: string }) => block.type === 'text').text
    const result = JSON.parse(text)

    // promptVersion travels with the result — agent runs stay traceable
    return {
      content: [{ type: 'text', text: JSON.stringify({ promptVersion, result }) }],
    }
  }
)

The master prompt supplies the intelligence. The MCP tool supplies the connectivity. Changing the prompt doesn't require changing the tool definition — they're separate concerns. The example above uses Anthropic — the same pattern applies for OpenAI. See the Integration Guide for both provider implementations.

What to take away

By default, every connected MCP tool's schema loads into context on every request — used or not. Three agents and ten tools, and you've already spent 6,000–20,000 tokens before your task starts. A CyWire master prompt sends the compiled system prompt with your data filled in, the output schema, and nothing else. That's 4,000–6,500 tokens total — often less than what the pipeline spends just setting up. And when one document is split across agents, each step has to carry the sections before it or it drifts, so the load grows with every section. A single pass writes them all from the same context.

The decision rule is simple: if you can describe the output as a JSON schema before the AI runs, write a master prompt. One call, schema-enforced result, version number saved with every record. When the AI genuinely has to figure out what step comes next — dynamic tool selection, open-ended reasoning, input too large for a single context window — build the pipeline.

And when you do need a pipeline, master prompts slot directly into MCP tool handlers. The compiled prompt becomes the intelligence layer for what that tool does. The pipeline handles routing; the master prompt defines what your LLM receives and what structured data comes back. They're not competitors — one is infrastructure, the other is the feature.