Built-in, Custom, Skill, or MCP?

By now you have four different ways to give Claude a new capability. They’ve arrived across the last two chapters and the SDK’s own kit: the built-in tools Anthropic ships, the custom tools you write (chapter 10), the Skills that package a procedure, and the MCP servers that share a capability across apps (chapter 11). They aren’t interchangeable, and the moment you actually build something the question is unavoidable: for this capability, which one? Pick wrong and you rebuild what already ships, or trap a shared service inside one app, or reach for a live tool when what you needed was know-how.

This chapter is the decision itself. What each option is really for, the two axes that separate them, and a guide that makes the choice almost mechanical. The facts are already established in chapters 10 and 11; here we choose between them. (It closes Arc 3.)

The four options, precisely

Each extends Claude, but along a different axis:

• Built-in tools: capabilities Anthropic already provides: web search and code execution (server-side), plus the Agent SDK’s harness tools (Read, Write, Edit, Bash, Glob, Grep, WebFetch). Zero implementation on your part; you enable them and they work. Limited to what Anthropic ships, and they run outside your systems.
• Custom tools: functions you write (chapter 10), executed by your code, reaching your systems and data. Maximum specificity, live in one application, and you own the implementation.
• Skills: packaged procedures and expertise, authored as a SKILL.md plus optional scripts and files, that Claude discovers and invokes when relevant. A Skill teaches Claude how to do something — a house style, a multi-step review process, a domain workflow. It does not expose a live external capability. Discovery-driven: the model reaches for it when the task matches.
• MCP servers — capabilities packaged behind the Model Context Protocol (chapter 11), reusable across applications and maintained independently. Tools, resources, and prompts exposed over a standard protocol that any MCP client can connect to.

The axes that separate them

Two questions cut cleanly through the four:

Capability or knowledge? A tool or MCP server gives Claude a new action — it can now do something it couldn’t (call an API, read a database). A Skill gives Claude new know-how — it now knows how to approach a task, applying a procedure to capabilities it already has. Confusing these is the classic mistake. If you need Claude to reach an external system, that’s a tool or MCP, not a Skill. If you need Claude to follow your process using tools it already has, that’s a Skill, not another tool.

Used here, or reused everywhere? A custom tool lives in one application. An MCP server is built precisely when the same capability must serve several applications and be maintained on its own release cycle. This is the inventory-service case from chapter 11 almost verbatim. An internal inventory service, needed across multiple Claude apps and maintained independently, is an MCP server. Not a custom tool copied into each, and certainly not hard-coded into prompts.

A third axis, implementation effort, follows from these. Built-in tools cost nothing to implement, custom tools cost a function, Skills cost a document, and an MCP server costs a service you build and operate. More reuse and independence buys more setup.

The decision guide

Put together, the choice is almost mechanical:

• Does Anthropic already provide it (web search, code execution, file/shell in the SDK)? Use the built-in tool. Don’t rebuild what ships in the box.
• Is it app-specific logic used only here (call our internal endpoint, read our database)? Write a custom tool.
• Must the same capability serve multiple apps, maintained independently? Build an MCP server — the reusability and lifecycle isolation are the whole point.
• Is it a repeatable procedure or expertise — how to run a code review, apply a house style, follow a domain workflow — that Claude should invoke when relevant? Author a Skill.

The through-line: match the mechanism to what kind of thing you’re adding and how widely it’s shared. A capability used in one app is a custom tool; the same capability shared across many is an MCP server; a procedure is a Skill; and anything Anthropic already provides is a built-in you shouldn’t reinvent.

Combining them

These aren’t mutually exclusive — real systems mix all four. An agent might use a built-in web search, a custom tool for the company’s internal API, an MCP server for the shared inventory service, and a Skill encoding the team’s incident-response procedure, all at once. The real skill is not picking one forever. It’s choosing correctly per capability. For each thing you want to add, ask the two questions — capability or knowledge, here or everywhere — and the right mechanism falls out.

Final thoughts

Four ways to extend Claude, one decision framework. Built-in tools for what Anthropic already provides; custom tools for app-specific actions you own; MCP servers for capabilities reused across apps and maintained independently; Skills for procedures and expertise Claude invokes when relevant. Separate them with two questions: is this a capability or knowledge, and is it used here or everywhere? The scenarios then answer themselves. An internal service for many apps is an MCP server, a house-style workflow is a Skill, a one-app database call is a custom tool, and web search is already built in. Choose per capability, combine freely, and the four-way decision stops being a guess.

Next: Arc 4 opens with LLM fundamentals and thinking — tokens, sampling, non-determinism, and the extended-thinking modes that trade latency for reasoning.