8.3 Choosing the Right Agentic Customization Mechanism

The first two lessons in this domain covered two specific extension mechanisms in depth: custom tools and MCP servers. This lesson steps back and puts all four options Anthropic gives you side by side, because the recurring exam theme across the whole domain is choosing the mechanism that actually fits a requirement — not defaulting to whichever one you reached for last.

Work through a scenario with these four questions, in this order, and the correct mechanism nearly always falls out cleanly:

• 1.Does a built-in already do it? If Anthropic already ships the capability (web search, code execution, computer use), use it — rebuilding it yourself is wasted effort.
• 2.Is it app-specific, living with one application? Use a custom tool — there's no reuse requirement to justify anything heavier.
• 3.Is it reusable procedure or knowledge, with no separate running service needed? Use a Skill — packaged instructions Claude loads when relevant.
• 4.Must it be shared across several apps and maintained independently, possibly remotely? Use an MCP server — that combination of requirements is what MCP exists for.

Notice that each question, if answered "yes," stops the search — you don't need to keep evaluating options once one of these fits. This ordering also mirrors effort: reach for the cheapest option that satisfies the requirement, the same discipline that governs pattern selection across the rest of the Claude architecture space.

Built-in tools are the least-effort option, but only within a fixed, Anthropic-defined capability set. They do not automatically reach into an arbitrary internal system just because a built-in tool exists in the same general category. A company's own inventory database, ticketing system, or proprietary API is never something a built-in tool can query on your behalf — crossing into an internal system always requires either a custom tool (if it's app-specific) or an MCP server (if it needs to be shared and independently maintained).

This ceiling is exactly where the domain's most-repeated exam trap lives: a scenario describes an internal REST API, and one of the wrong answers suggests "just use a built-in tool, since built-ins can reach any internal REST API." That's false every time it appears. Built-ins have fixed capabilities; internal systems are, by definition, outside that fixed set.

The subtlest distinction in this domain is between a Skill and an MCP server, because both are described as "reusable." The discriminator is whether there's a running service behind the capability. A Skill is packaged instructions — and optionally scripts or reference resources — bundled as a `SKILL.md` that Claude loads into context when it's relevant to the current task. Nothing is running continuously; it's knowledge and procedure, not a live endpoint. An MCP server, by contrast, is an actual standing service: it's running somewhere, advertising tools/resources/prompts, and handling calls in real time.

So: reusable domain know-how with no running service required — a step-by-step procedure for formatting a specific type of report, or house style rules for a certain kind of document — is a Skill. A capability that needs to be reached over a live connection, shared across multiple applications, and maintained as its own independently versioned thing — that same inventory API from Lesson 8.2 — is an MCP server. Reaching for an MCP server when all you actually needed was packaged know-how is over-engineering; reaching for a Skill when you actually need a live, callable service will simply not work, because a Skill has no way to execute a real action against a live system on its own.

Applying the four-question heuristic from 8.3.2 to concrete scenarios makes the pattern stick: