Same Tool, Three Agents: Inline Tool or MCP Server?

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 18)

▶ Watch on YouTube & subscribe to The Stack Underflow

Your billing team ships a refund_order tool inline, hard-coded into their agent’s tool list. Three months later, the support team needs the same capability, so someone copies the function into their agent too. Then the fraud-review team needs it a third time. Now there are three implementations of “refund an order” living in three codebases, owned by nobody in particular, and the first time a refund-limit rule changes, exactly one of those three copies gets updated. This is not a hypothetical — it’s the default failure mode of inline tools the moment more than one agent needs the same capability, and it’s exactly what Domain 2 of the Claude Certified Architect exam is testing when it asks you to choose between “inline” and “MCP server.”

The one-sentence version: When a capability is reused across multiple agents, teams, or sessions, put it behind one MCP server so there is a single source of truth — inline copies are guaranteed to drift the moment more than one person maintains them.

This is practice question 5 of 10 in the Domain 2 set — Tool Design & MCP Integration, roughly 18% of the Claude Certified Architect exam. Pause, pick an answer, then read on for the mechanism.

The question

A capability will be reused across three agents and two teams, and must stay consistent. MCP server or inline function?

• A) Inline, copied per agent
• B) An MCP server all three consume
• C) Paste it in each system prompt
• D) A bigger model

Pause the video (or this page) and pick your answer before you keep scrolling.

The answer

B — an MCP server all three agents consume. The moment a capability crosses agent boundaries and team boundaries, the question stops being “how do I call this tool” and becomes “who owns the one correct definition of this tool.” An inline function answers that question badly by construction: it lives inside a single agent’s codebase, so as soon as a second agent needs it, someone copies the code, and now there are two things that can disagree.

An MCP server answers it correctly: it’s a standalone process exposing the capability once, over a standard protocol, that any agent — regardless of who wrote it or which team owns it — can connect to and call. There is exactly one implementation, one schema, one set of business rules. Every consumer sees the same behavior because there is only one behavior to see.

Here’s the mechanism, matching the beat-sheet from the practice set this question comes from:

THE DECISION DIAMOND

  Is this capability reused across
  multiple tools / agents / teams / sessions?
              │
      ┌───────┴───────┐
      │               │
     YES              NO
      │               │
      ▼               ▼
  ONE MCP SERVER   inline is fine —
  (standardize)    a simple local one-off


REUSE PATH — inline copies (WRONG)          REUSE PATH — one MCP server (RIGHT)
──────────────────────────────────          ────────────────────────────────────
  Agent A ── refund_order() copy 1               Agent A ─┐
  Agent B ── refund_order() copy 2                        ├──►  MCP SERVER
  Agent C ── refund_order() copy 3               Agent B ─┤     refund_order
                                                  Agent C ─┘     (ONE impl,
  Refund limit changes.                                          ONE schema,
  Team updates copy 1 only.                                      ONE set of
  Copies 2 and 3 silently                                        business rules)
  drift out of sync. ✗                           Refund limit changes.
                                                  Update the server once.
                                                  All three agents see the
                                                  new rule immediately. ✓

Notice what’s actually different between the two paths: it isn’t what the tool does — refund_order does the same thing either way. What changes is where the truth lives. In the inline version, truth is distributed across N copies of source code, each editable independently, with no mechanism forcing them to stay in sync. In the MCP version, truth lives in exactly one place — the server — and every agent is a client pointing at that same source. “Reuse across agents/teams/sessions” is the trigger condition; “one server, many clients” is the fix.

Why the other options fail

• A) Inline, copied per agent. This is the setup the question describes as already going wrong. Copy-per-agent works fine for exactly one agent and stops working the instant a second one exists, because now two people (or two future commits) have to remember to change both copies every time the business logic changes. In practice, one gets updated and the others don’t — which is worse than having no shared capability at all, because it looks consistent while quietly being three different tools with the same name.
• C) Paste it in each system prompt. This doesn’t even solve the consistency problem — it makes it worse and adds a second problem on top. You still have N copies (now N copies of prompt text instead of N copies of code), so the drift issue is identical. And pasted-in-the-prompt logic isn’t callable, testable, or independently versioned the way a real tool is; it’s a description of a capability, not the capability, and it burns context tokens in every single agent’s prompt for no functional benefit.
• D) A bigger model. A larger or more capable model has no bearing on where the source of truth for a business capability lives. This option is a distractor built to catch the reflex of “throw more model at the problem” — but reuse-and-consistency is an architecture question, not a capability question. A frontier model calling three drifting inline copies still gets three different answers, because the disagreement is in the code, not in the reasoning.

The concept behind it

Generalize past refund_order: MCP earns its keep specifically at the seams — the points where a capability needs to cross a boundary that inline code can’t cross cleanly. Those boundaries are usually one of three things: multiple agents that need identical behavior, multiple teams that need to agree on one implementation, or multiple sessions/users that need a persistent, centrally-governed service rather than a function baked into one process.

If none of those boundaries exist — one agent, one team, a genuinely local one-off — inline is not wrong, it’s just simpler, and simplicity has real value. The exam-relevant judgment call is knowing which side of the line you’re on:

That last row is worth dwelling on. An MCP server doesn’t just deduplicate code — it collapses the update problem from “find and change N places” to “change one place, all clients pick it up.” That property compounds the more consumers you add: with three agents it’s an annoyance to keep in sync manually; with thirty it’s operationally impossible without something MCP-shaped standing behind the capability.

This is also the same underlying logic behind the auth/multi-tenancy version of this trade-off: when a tool needs per-user OAuth against a SaaS API across many tenants, centralizing that in an MCP server isn’t just tidier, it’s the only place tokens, scopes, and audit trails can live without leaking into every inline call site that touches them. Reuse-across-agents and centralize-auth-and-governance are two faces of the same decision: does this capability need one authoritative home, or is a local copy good enough?

It’s worth being precise about what MCP is actually standardizing here, because it’s easy to overstate. MCP doesn’t change tool selection (that’s the description’s job) or the shape of a single call (that’s the schema’s job) — it changes where the implementation and its state live relative to the agents that call it. A well-described, well-typed tool can still be the wrong architectural choice if it’s inline and three teams depend on it; conversely, MCP won’t fix a badly written tool description or a loose schema. The decision in this question is orthogonal to — and sits alongside — the other Domain 2 questions about descriptions, schemas, and error contracts. Get the “where does this live” call right first, and those other disciplines apply cleanly on top of it.

FAQ

Does every tool need to be an MCP server “just in case” it gets reused later? No — that’s premature standardization, and it has a real cost in operational overhead (a process to run, deploy, and monitor) for a benefit you may never need. Start inline for a genuinely single-agent, single-team capability. Move it behind an MCP server when a second consumer actually shows up, or when you can see one coming with enough certainty that the migration cost now is cheaper than the drift risk of doing it inline twice.

What if the three agents are all owned by the same team — does MCP still matter? Yes, arguably it matters even in that case, because the consistency problem is about code paths, not organizational reporting lines. Three agents owned by one team can still drift if each has its own copy of the function; the fix is the same — one server, multiple clients — even though “two teams” isn’t in play. The question’s “two teams” detail sharpens the stakes but isn’t the only trigger; multiple agents alone is enough to justify it.

Is an MCP server always a separate network service, or can it run locally? MCP servers can run locally over stdio (common for developer tools on one machine) or remotely over HTTP (common for shared, multi-user capabilities like the refund example here). The protocol is the same either way — what matters for this question is that there’s one implementation multiple clients connect to, not where that implementation’s process happens to run.

How is this different from just publishing the function as a shared library? A shared library still requires every consumer to import a specific version, and nothing forces Agent A, B, and C to be on the same version at the same time — you’re back to potential drift, just at the dependency-pinning layer instead of the copy-paste layer. An MCP server is called at runtime over the protocol; there’s no local version to fall out of sync, because there’s no local copy at all.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This is Q5 of the Domain 2 practice set — as of mid-2026 the CCA-F runs on Pearson VUE, costs $125, allows retakes, and the exam itself is 60 questions in 120 minutes with a passing scaled score of 720/1000 across five domains; verify these logistics on Anthropic’s official pages before you register. For the full map of all five domains, start with the Claude Certified Architect (CCA) Exam Guide, and if the MCP mechanism itself is still fuzzy, MCP Explained on One Diagram covers what actually happens on the wire before you weigh it against inline.

Staying inside Domain 2, this question pairs with 40 Tools, Wrong Picks, High Latency: Scoping Tools Per Agent — both are about the same underlying move, grouping and standardizing tools behind MCP servers rather than letting them sprawl — and with Per-User OAuth Across Many Tenants: MCP Authentication at Scale, which is the auth-and-governance flavor of this exact reuse decision. If you haven’t started Domain 2 from the top, Why Does Claude Pick the Wrong Tool? covers the description-level failure that sits one layer below this architectural one. Browse all tutorials for the rest of the series.