What you’ll be able to do
- Place a need on the built-in → custom → Skill → MCP ladder
- Recognise the tool-overload threshold and its real fix
- Distinguish packaged instructions from executable integration
- Resist mechanisms applied at the wrong scope
What you need to know
The extension ladder
- Built-in tool — the platform already provides it. Use it.
- Custom tool — one application's bespoke need, no reuse planned.
- Skill — packaged instructions and procedures. Guides behaviour; does not execute an integration.
- MCP server — must be discoverable and reusable across multiple clients and teams.
Distractors in these questions are almost never nonsense mechanisms. They're real mechanisms at the wrong scope — a full MCP server for a one-off script, or a copy-pasted custom tool for something six teams need. Ask what scope the scenario actually describes.
Skill versus tool, precisely
The cleanest distinction: a tool executes something and returns a result. A Skill packages instructions and procedures the model follows — a house style guide, a review checklist, a documented workflow.
If the answer to "what does this do when invoked?" is "runs code and returns data," it's a tool. If it's "tells the model how to approach this kind of task," it's a Skill.
Tool overload — the other misrouting cause
Lesson 8.1 covered misrouting caused by descriptions that don't differentiate. There's a second cause with a completely different fix.
Past roughly four or five tools per agent, selection accuracy degrades on decision complexity alone — not because any two are confusable, but because the choice space itself has grown. The tell is degradation across the board rather than between a specific pair.
Rewriting twenty-two descriptions does nothing for this. The fix is structural: split the toolkit across subagents, each holding a coherent subset, or narrow what any single agent is given.
get_patient with get_appointment, routing correctly to the other four. That's a description problem — a specific, reproducible pair.Agent B has 22 tools and picks slightly wrong ones across the whole set with no clear pattern. That's overload. Same symptom word, opposite remedies.
Where agentic customization sits
All four rungs coexist in a mature system: built-in tools for platform capabilities, a handful of custom tools for genuinely bespoke needs, Skills for repeatable procedures, and MCP servers for anything shared across teams. The skill being tested is placing a new need on the right rung rather than defaulting to the one you built last time.
Key concept
Built-in, custom tool, Skill, MCP server — each is right at one scope. Skills guide, tools execute. And misrouting has two causes: confusable descriptions below the overload threshold, decision complexity above it.
Practice scenario
Work it through, then open this
Wrong diagnosis. Scattered degradation past roughly 4-5 tools is decision complexity, not ambiguity — no amount of description polish touches it. Split the toolkit across subagents, each holding a coherent subset, or narrow what any single agent is given.
Build exercise — Diagnose which misrouting problem you have
Advanced · 30 min
What you’ll learn
- Separating confusable descriptions from toolkit overload
- Placing a capability on the built-in / custom / Skill / MCP ladder
-
Count the tools your agent holds. Then run 15 queries with a known correct target and log what actually got called.
- Why: The count and the failure pattern together tell you which of the two problems you have.
- You should see: Either a specific confusable pair, or scattered errors across the whole set.
-
If the failures cluster on a pair, rewrite those two descriptions with explicit boundaries. If they’re scattered across many tools, split the toolkit across subagents instead.
- Why: Description polish fixes ambiguity. It does nothing for decision complexity past roughly 4-5 tools.
- You should see: The right fix moves the number; the wrong fix leaves it flat, which is itself the confirmation.
-
Take one capability you were about to build and place it on the ladder: built-in, custom tool, Skill, or MCP server. Justify the rung from scope alone.
- Why: Distractors in these questions are real mechanisms at the wrong scope, not nonsense options.
- You should see: A justification mentioning how many apps and teams need it — that’s what moves you up the ladder.
Exam traps
Building an MCP server for a single application’s one-off need
A real mechanism at the wrong scope. MCP earns its cost when multiple clients and teams need discoverability.
Rewriting descriptions when the toolkit is simply too large
Across-the-board degradation past 4-5 tools is decision complexity. Split across subagents instead.
Treating a Skill as an executable integration
Skills package instructions and procedures. If it runs code and returns data, it is a tool.
Copy-pasting a custom tool across six applications
Once several teams need it, that is the MCP threshold. Copies drift and each one has to be maintained.