How to Expose 30 Tools Across 3 Services: MCP vs Inline Tools

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

▶ Watch on YouTube & subscribe to The Stack Underflow

Say your platform team owns three microservices — billing, inventory, and shipping — and each one needs to hand Claude a handful of internal operations. Nobody plans for this to become 30 tools. It just happens: someone adds refund_order, someone else adds check_stock, someone else adds create_label, and six months later every request to the model is dragging a pile of function definitions behind it. This is exactly the setup the Claude Certified Architect exam likes to test, because the “obvious” fix — just define more functions — is the wrong one.

The one-sentence version: When tool count and service count both grow, you don’t scale the number of inline function definitions — you standardize the interface with one MCP server per service, so the model always sees one port instead of thirty bespoke wires.

The question

You must let Claude use ~30 internal tools spread across 3 microservices, cleanly and reusably. Best approach?

• A) 30 inline function definitions per request
• B) One MCP server per service
• C) Paste API docs into the system prompt
• D) A bigger context window

Pause here and pick an answer before you keep reading — the point isn’t the letter, it’s whether you can defend it.

The answer

B — one MCP server per service.

Every option here is a different way of trying to answer the same underlying question: how does the model know what it can do? Options A, C, and D all try to solve that by cramming more information into the request. Option B solves it by changing the architecture so the request doesn’t need to carry that information at all.

An MCP server is a standard interface — a single “port” — that sits in front of a service and exposes its capabilities as tools. Instead of the client (Claude, or the harness calling Claude) needing to know the shape of 30 individual functions, it needs to know how to talk to 3 servers, and each server tells the model what it offers. Add a tool to billing next month, and the billing MCP server just advertises one more entry — nothing about inventory or shipping, and nothing in the client, has to change.

WITHOUT MCP — 30 bespoke wires into one client
                                                    ┌──────────┐
  billing:    refund, charge, void, ...(10) ───────▶│          │
  inventory:  check_stock, reserve, ...  (10) ──────▶│  CLIENT  │  ← every new tool = new wiring here
  shipping:   create_label, track, ...   (10) ──────▶│          │
                                                    └──────────┘

WITH MCP — one standard port per service
  ┌───────────────┐
  │ Billing MCP    │──┐
  │ server (10 tls)│  │
  └───────────────┘  │      ┌──────────┐
  ┌───────────────┐  ├─────▶│          │
  │ Inventory MCP  │──┤      │  CLIENT  │  ← sees 3 ports, not 30 functions
  │ server (10 tls)│  │      │          │
  └───────────────┘  │      └──────────┘
  ┌───────────────┐  │
  │ Shipping MCP   │──┘
  │ server (10 tls)│
  └───────────────┘

The mechanism to remember: MCP standardizes the interface, not the tool count. You still have 30 tools — MCP doesn’t shrink your surface area — but they live behind 3 well-defined, discoverable, independently-maintained servers instead of being flattened into one undifferentiated pile the client has to manage by hand. That’s what “cleanly and reusably” in the question stem is pointing at: cleanliness comes from ownership boundaries (each service owns its own MCP server), and reusability comes from the fact that any MCP-speaking client — not just this one agent — can plug into the same three servers without re-implementing anything.

Why the other options fail

• A) 30 inline function definitions per request — this is the naive scaling path, and it’s tempting precisely because it “works” at small numbers. The failure mode shows up as it grows: every request now ships all 30 schemas whether or not they’re relevant, token cost climbs, the model has more irrelevant options to sift through when picking a tool, and there’s no ownership boundary — a change to the inventory service means someone has to go edit the client’s function list by hand. Inline definitions don’t scale with organizational structure; MCP servers do, because each service can own and version its own server independently.
• C) Paste API docs into the system prompt — this confuses documentation with a callable interface. Prose in a system prompt is not a typed, invocable tool; the model has to interpret free text and hope it constructs a correct call, with no schema validation and no structured error path. It also bloats the system prompt permanently, on every single turn, regardless of whether that turn needs billing, inventory, or shipping. This is a scaling and reliability failure dressed up as a shortcut.
• D) A bigger context window — a bigger window doesn’t solve an architecture problem; it just raises the ceiling before the architecture problem becomes visible. You can jam more inline definitions or more pasted docs into a bigger window, but you’re still paying the token cost, still giving the model more irrelevant surface area per call, and still coupling the client to every service’s internals. This is the classic “throw resources at it” distractor the exam uses to test whether you understand why something fails, not just that inline defs are “bad.”

The concept behind it

This question is really testing one architectural instinct: when the number of things an agent needs to do grows, don’t scale by enumeration — scale by interface.

That instinct generalizes past tool counts. It’s the same reason microservices exist instead of one monolith with 30 functions in it, and the same reason USB-C replaced a drawer full of proprietary connectors. MCP (Model Context Protocol) plays that role for agentic systems: it’s a standard way for a model-facing client to discover and call capabilities that live behind a server, without the client needing to know the server’s internals. If you haven’t seen the full picture of how that protocol fits together, MCP Explained on One Diagram is the companion piece to this one.

A few decision rules fall out of this, and they show up repeatedly across the D1 and D2 domains of the CCA exam:

It’s worth being precise about what MCP is not solving here. It doesn’t reduce how many tools exist, it doesn’t make the model smarter about picking the right one, and it doesn’t replace the need for good tool descriptions or scoping. Those are separate, related concerns — how you write a tool description well, how you scope which tools an agent even sees, and whether a given tool belongs inline or behind a server at all — that the exam tests in Domain 2. What MCP fixes specifically is the interface problem: how a growing set of capabilities, spread across a growing set of owners, stays addressable by a client without becoming an ever-growing, hand-maintained wire list.

The tell for “this is an MCP question” versus “this is a tool-design question”: if the stem is about count and service boundaries (30 tools, 3 services, reusable across clients), think MCP-server-per-service. If the stem is about one tool’s shape (a bad description, wrong types, no error contract), that’s a tool-design question, not an exposure-architecture question — even though both fall under “tool use” broadly.

FAQ

Do I need a separate MCP server for every single tool? No — the unit of separation in this question is the service, not the tool. Ten tools that all belong to the billing service can live behind one billing MCP server. You’d split further only if two groups of tools have genuinely different ownership, deployment cadence, or access-control needs — for example, a read-only reporting tool set versus a set of tools that can issue refunds.

Isn’t pasting API docs into the system prompt basically what a tool description does anyway? Not quite. A tool description in a proper tool definition is scoped, structured, and only loaded when relevant to that call — it’s attached to a schema the model can invoke with validated arguments. Pasted API docs in a system prompt are unstructured prose, present on every single turn regardless of relevance, with no schema and no validation path. The information might overlap; the mechanism and the cost profile don’t.

Does MCP help with the model picking the wrong tool out of 30? Indirectly, by making tools discoverable and well-scoped per server, but it isn’t the primary fix. Tool selection accuracy is mostly a function of clear tool descriptions, sensible per-agent scoping (not exposing all 30 tools to every agent), and distinct naming — topics covered in the Domain 2 tool-design tutorials rather than this exposure-architecture question.

Is MCP only useful when multiple clients need the same tools? Reuse across clients is a strong reason to use MCP, but it pays off even with a single client the moment tool count and service count both grow, because it keeps ownership boundaries clean and keeps the client from needing to know each service’s internals.

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 question 2 of the Domain 1 (Agentic Architecture & Orchestration) practice set — the heaviest domain on the exam at roughly 27% of the blueprint (as of mid-2026: Pearson VUE, $125, retakes allowed, 60 questions in 120 minutes, pass score 720/1000 across five domains — verify current numbers on Anthropic’s official pages). Start with the Claude Certified Architect (CCA) Exam Guide for all five domains on one diagram, and pair this page with MCP Explained on One Diagram if the interface concept here is still fuzzy.

Other D1 questions worth working through: The Agent Loop Explained covers what happens when tool results get called but never fed back into reasoning, RAG vs MCP draws the line between retrieval and capability that Q3 in this same set tests, and 40 Tools, Wrong Picks, High Latency: Scoping Tools Per Agent picks up right where this page leaves off — once your 30 tools are cleanly exposed behind MCP servers, the next problem is deciding which agent should even see which subset of them.

Browse all tutorials for the rest of the series.