What You Need to Know
Four mechanisms give a Claude application something it lacks. Built-in tools are capabilities Anthropic provides: the platform defines the schema and, for the server-executed ones, also runs them. Custom tools are functions you define and your own code executes. Skills are packaged procedural knowledge: a SKILL.md file with YAML frontmatter, optionally bundled with reference files and executable scripts, which Claude loads when relevant. MCP servers expose a capability over a standard protocol, so several clients can connect to one implementation. This sub-skill is choosing between the four.
Take a newsagent extending its Claude assistant. It wants four things. The assistant should read cover prices from a publisher's public website. It should look up customer accounts and delivery rounds in the shop's own database. It should write monthly account statements to the shop's house rules, which run to several pages and matter on about one job in five. And it should respect a rule about which unpaid accounts may be closed without the owner checking. The account lookup will also soon be needed by a second application: the app the delivery staff carry on their rounds. Each requirement has a different home.
Built-In Tools: What They Buy and What They Cost
A built-in tool needs no code, no handler and no deployment. Built-in tools cover common needs such as searching the web, fetching a page and running code in a sandbox. The server-executed ones leave no execution to manage either. The API runs the call internally, and its result block arrives in the same assistant turn. So when a built-in tool fits, it is the cheapest correct answer. When it does not fit, it is the fastest wrong one. Building your own version of a capability the platform provides adds maintenance you did not need. The newsagent's price lookup fits: the publisher's site is public, and the platform already fetches pages. A custom fetcher would be work the shop did not need.
What built-in tools cost is reach. A server-executed tool is the platform's capability. It runs in the platform's environment, under the platform's constraints. Nothing connects that environment to a database on your private subnet. The newsagent's accounts sit on the shop's own network, so web fetch cannot query them. Reaching an internal system needs code running somewhere that system is reachable. That means a custom tool or an MCP server, and nothing else on the list.
As of September 2026 the built-in list also includes a browser. The browser use tool (browser_toolset_20260801) is an Anthropic-defined client toolset. Claude works through a page's structure and screenshots. Your application runs every call against its own browser, and nothing runs on Anthropic's side. The docs draw its boundary clearly. Choose it when the task stays inside webpages and means acting on them, or when pages build their content with JavaScript. Web fetch and web search are lighter for reading pages. Computer use is for a task that needs a whole desktop. The newsagent only reads its price pages, so web fetch is enough.
Anthropic-Provided Is Not Anthropic-Executed
Built-in does not mean server-executed. The Tool reference splits Anthropic-provided tools in two. Server tools execute on Anthropic's infrastructure. Client tools have a schema Anthropic defines, but your application handles execution. Both count as built in, because you did not write the schema. Only the first kind runs on Anthropic's side.
Several familiar Anthropic-schema tools sit on the client side, and your own process runs them. So "built-in tools run on Anthropic's servers" is unsafe as a universal rule. Relying on memory of which list a named tool sits in is unsafe too, because the membership of both lists is dated and it moves. The capability boundary, meaning what a tool can reach, is the stable ground.
Skill or Tool: Ask What Is Missing
The docs define Skills as "modular capabilities that extend Claude's functionality" that Claude "uses automatically when relevant". That wording does not mean a Skill gives Claude a new capability to call. A Skill changes how Claude does something it can already do. So one question separates a Skill from a tool: what is the model missing?
If the model lacks information it cannot reach, or an action it cannot perform, it needs a tool. A records lookup, a database write and a job trigger are all tools. No volume of instruction substitutes. A Skill that describes a private system's schema, query conventions and field meanings in full still does not perform the lookup. Instructions are not access. On the Claude API this limit is absolute. Skills there "run in a sandboxed container with no network access and no runtime package installation". A Skill cannot fetch the newsagent's customer accounts, however precisely it documents the database.
If the model can already do the task but does it inconsistently, in the wrong format or against the wrong conventions, it is missing knowledge. A Skill packages that knowledge so it is applied without taking up room in every request. House reporting conventions, a document template, a review checklist and a written procedure a team keeps re-pasting are all knowledge. The newsagent's statement rules are knowledge. The assistant can already write a statement; it does not follow the shop's layout every time.
The two wrong assignments mirror each other. One builds "a tool that returns the checklist". The sign it is wrong: the model can already do the task and only does it inconsistently. The other writes "a Skill that documents the system thoroughly" for a lookup. The sign it is wrong: no amount of instruction supplies access.
A Skill and a tool are usually two halves of one requirement
Teaching the two as rivals leads people to hunt for the single best mechanism when the task needs an assignment. At the newsagent, the tool fetches a customer's account and the Skill governs how the statement about it is written. An agent with one and not the other fails in a way the missing half would have fixed. An answer that gives every requirement in a mixed list the same mechanism is almost always wrong on that uniformity alone.
Progressive Disclosure Is the Argument
Progressive disclosure is what makes Skills cheap to install. It is also why a Skill beats pasting a procedure into every prompt. Claude loads a Skill's full instructions only when needed. The docs set out three levels:
| Level | When loaded | Token cost | Content |
|---|---|---|---|
| Metadata | Always, at startup | ~100 tokens per Skill | name and description from the YAML frontmatter |
| Instructions | When the Skill is triggered | Under 5k tokens | The SKILL.md body |
| Resources | As needed | None until accessed | Bundled files; reference files load when read, scripts run through bash and only their output enters context |
So an installed but untriggered Skill costs roughly a hundred tokens. That reframes the comparison. The choice is not really Skill against tool at all. It is a Skill against carrying several pages of house conventions on every request. For the newsagent, that means the statement rules riding along on every request, including the four jobs in five that never touch them.
The description is the trigger. It "is what Claude matches your request against when determining whether to trigger the Skill, so it must say both what the Skill does and when to use it". A description that says only what the Skill does will sit there unused. The example below says both. It comes from an acoustics consultancy, whose Skill carries its report conventions. The newsagent's statement rules would read the same way.
---
name: insulation-report-conventions
description: House conventions for writing sound-insulation test reports - section order, how to express single-number quantities, which caveats are mandatory, and the sign-off block. Use when drafting, revising or reviewing an insulation test report.
---
# Sound-insulation report conventions
## Section order
1. Instruction and site
2. Test arrangement, including the separating element and both room volumes
...The fields have fixed limits. name is at most 64 characters, uses lowercase letters, numbers and hyphens only, has no XML tags, and cannot contain the reserved words "anthropic" or "claude". description must be non-empty, at most 1024 characters, and free of XML tags.
Where a Skill runs differs by surface, and the differences bear on the answers here. On the Claude API a Skill requires the code execution tool and a skill_id in the container parameter. Custom Skills there are shared workspace-wide. The call below, again for the consultancy, shows both parts:
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-opus-5-5",
max_tokens=4096,
container={"skills": [{"type": "anthropic", "skill_id": "pdf", "version": "latest"}]},
# One of three current code execution versions as of September 2026; use
# code_execution_20260120 or later if you also need programmatic tool calling.
tools=[{"type": "code_execution_20250825", "name": "code_execution"}],
messages=[{"role": "user", "content": "Produce the insulation report for job 4471 as a PDF."}],
)In Claude Code, Skills are filesystem-based in ~/.claude/skills/ or .claude/skills/ and have full network access. On claude.ai they are per-user and uploaded as zip files. The docs are explicit that "Custom Skills do not sync across surfaces". A Skill uploaded to one surface is not available on another.
Custom Tool or MCP Server: Reuse and Ownership
A custom tool runs under your credentials, inside your network. It can reach anything your code can reach. You own it entirely, which is both the benefit and the cost. An MCP server is versioned and owned independently of any single application. For one application, both can do the same job, so capability cannot decide between them. Three facts in the requirement decide it.
- How many applications or surfaces need this capability, now and shortly?
- Should it be maintained independently of any one application's release cycle?
- Who owns the underlying system, and should they own the integration to it?
One application, one team, and nothing else will ever need it: a custom tool is simpler, has no deployment story, and is the right choice. Several surfaces, or a system whose owning team should own its integration: an MCP server.
An MCP server has real costs, and they have to be counted. A reader who learns only its benefits ends up answering MCP to everything. A remote server is a service. It has an availability expectation, an access-control story and an operational owner. Choose it for a capability exactly one application will ever use, and you buy all of that for no reuse.
The strongest signal is a second consumer, actual or imminent. The newsagent's account lookup already has one on the way, the delivery app, so it belongs on an MCP server from the start. Had no second application been planned, a custom tool inside the assistant would have done, and the later move is cheap. It relocates the same implementation behind a protocol, so "we would have to rebuild it" is a false objection.
The Four Postures That Recur
Four wrong moves come round again and again. Real developers have proposed each one in real meetings. Each is a reasonable idea applied to the wrong problem.
Pasting the data into the context on every request. The plan is to export the records nightly, inject the extract and skip the integration. An export is a snapshot, so it is stale by construction for a system whose value is its current state. The newsagent's extract would miss any delivery a customer paused that morning. It spends context on every call, including the majority that need none of it. It grows with the size of the data, not the size of the question. Pasting data gives no live access and wastes context. Live access needs a tool or an MCP server.
Hard-coding the procedure into every application's system prompt. This works until there are three applications. Then there are three copies. They drift, and nobody knows which is authoritative. The whole procedure is also carried on every request, including those that never touch it. MCP makes the same drift argument about integrations. Applied to knowledge, the answer has the same shape: one authoritative place, loaded when relevant.
Assuming a built-in tool can reach an internal service. The reasoning runs: the tool already fetches things over HTTP, so surely it can fetch this. It cannot. A server-executed tool such as web fetch is the platform's capability, running in the platform's environment.
Reaching for fine-tuning. Fine-tuning is a genuine technique. It is expensive and slow, and it is aimed at the wrong class of problem when the issue is knowledge packaging or tooling. It changes how a model behaves on a distribution of inputs. It does not grant access to a system. It does not keep a procedure current when the procedure changes next quarter.
Running the Decision
Ask four questions, in order. The first or the second settles most cases.
- Does the platform already provide this? Searching the public web, fetching a page and running code in a sandbox are covered. As of September 2026, so is acting on webpages in a browser your application runs. If the requirement matches one, the built-in tool is the cheapest correct answer, and building anything is work you did not need.
- Does the model need to DO something in a system, or to KNOW how to do something it can already do? Doing means a tool. Knowing means a Skill. This question separates a records lookup from reporting conventions in the same set of requirements.
- If it is a tool, will more than one application or surface need it, and does another team own the underlying system? Yes to either points at an MCP server. No to both points at a custom tool.
- If it is knowledge, is it procedural and only occasionally relevant? Then a Skill loads it on demand instead of carrying it in every prompt.
Run the newsagent through it. The publisher's price page passes question one, so the platform covers it and a fetcher would duplicate work. The account lookup is a doing job, so it is code running where the database is reachable. Question three turns on the delivery app: that second consumer is imminent, so the lookup goes on an MCP server now. The statement layout is knowing, procedural and needed on one job in five, so it is a Skill. The rule about closing unpaid accounts is a policy. The tool surface expresses it and the harness enforces it, which 8.1 and Domain 7 cover between them.
They Compose; They Do Not Compete
Real agents use several mechanisms at once. A typical agent has a built-in capability for the public web and two or three custom tools for the systems only that application touches. One MCP server holds a capability a sister team also needs. A Skill or two carry the conventions that shape the output. They fit together because each answers a different question.
Skills compose with each other too. As of September 2026 one API request can carry up to 20 Skills in its container. So an Anthropic pre-built Skill such as xlsx can sit beside a custom Skill holding the house layout rules and template. The Skills guide's own example pairs the Excel Skill with a custom DCF analysis Skill. A new custom Skill version is a complete snapshot. Revising the template therefore means uploading the Skill's full file set again.
A Skill and a tool are not alternatives. A custom tool and an MCP server are alternatives only briefly. The same capability moves from one to the other when a second consumer appears.
In the exam
This sub-skill is a decision, and the items ask you to make it. Learn each mechanism in a sentence, then spend your preparation on choosing. The commonest way to lose marks is to arrive with four memorised definitions and no sequence to run them through. The hardest items list three or four requirements in one stem and ask for an assignment. They place one or two arguable requirements deliberately. Running the four questions per requirement gets them all. A candidate with only definitions stalls on the second and reaches for the option that assigns everything to one mechanism. That uniformity is the sign the option is wrong.
Skill against tool is the distinction tested most reliably. Both near-misses, the checklist tool and the documenting Skill, are deliberately attractive. The name and description limits are examinable in their own right. The four recurring postures make good distractors for the reason given above: each is a reasonable idea misapplied.
The exam guide states the built-in boundary in one clause of its published rationale for the Domain 8 sample: built-in tools "do not automatically reach arbitrary internal APIs". Carry that clause in as a sentence. Any option claiming a platform-provided fetch or search capability can reach an internal service is wrong, however it is worded. The same sample supplies the other half: reaching an internal system needs a custom tool or an MCP server. The guide also kills the pasting posture in its own words: pasting data gives no live access and wastes context. It rejects the internal-service assumption explicitly too.
For custom tool against MCP server, the guide's own sample keys the MCP server on reuse and ownership. When a stem states a second consumer or independent maintenance, an option arguing that a custom tool could do the same thing answers a question the stem did not ask. When a stem is about where information lives or what the model can call, fine-tuning answers neither question.
Two refinements decide most questions here. Built-in does not mean server-executed, and the membership of every list moves between releases. Answer from the capability boundary first. Where a tool runs only matters when the question says so, in the stem or in the options. Don't assume a location it leaves out, and don't rely on today's list of built-in tools.
Dated Facts
The membership of every one of these lists moves between releases. Learn the boundaries, which are stable, and treat any specific inventory as a dated snapshot. The domain quick reference carries the inventory with its date; this lesson teaches the boundary. An item that hinges on whether a named tool exists today, or on a venue it never states, is testing something that may be false next quarter.
Exam Traps
Accepting an option that serves an internal API through a platform-provided tool, on the reasoning that the tool already fetches things over HTTP.
Built-in tools are the platform capability, not a general-purpose client for your network. The exam guide rejects this in one clause of its own published rationale: built-in tools do not automatically reach arbitrary internal APIs. Reaching an internal system needs code executing where that system is reachable, which is a custom tool or an MCP server.
Choosing a Skill that documents a private system thoroughly enough for Claude to perform the lookup.
A Skill supplies knowledge, not capability, and instructions cannot make the model able to perform an action it has no means to perform. On the Claude API the Skill container has no network access at all, so the boundary is not a matter of degree. The mirror-image near-miss is equally wrong: a tool built to return a checklist the model could already apply.
Answering a stem that names a second consumer, or independent maintenance, with the option arguing that a custom tool can do the same thing.
It can, and that is irrelevant. When the stem states reuse or ownership as the requirement, capability is not the deciding fact and the option that raises it is answering a different question. This is exactly the shape of the guide's own Domain 8 sample. The reverse error is just as costly: choosing MCP for a capability exactly one application will ever use buys a deployment and an availability expectation for no reuse.
Reading Anthropic-provided as Anthropic-executed, and picking the option that says a built-in tool runs on Anthropic infrastructure.
Anthropic ships two kinds: server tools it executes, and client tools whose schema it defines and whose execution is yours. Several familiar built-in tools sit on the client side. Answer from the capability boundary first, don't assume where a tool runs unless the question says, and don't rely on today's list of built-in tools, because it changes between releases.
Practice Scenario
An acoustics consultancy is extending its Claude-based assistant with four things. It must look up sound-insulation test records in the consultancy's own database. It must apply the consultancy's house reporting conventions, which run to several pages, matter on roughly one job in five and should not load in full on the other four. It must fetch and read pages from a public standards site. And the test-record lookup will shortly also be needed by a second application that a partner acoustics practice is building. Which assignment fits?
Build Exercise
Four Requirements, Four Mechanisms, and One You Were Wrong About
What you'll learn
- How to run the four-question decision sequence against a real requirement list
- Why a Skill cannot substitute for a tool that reaches a private system
- How progressive disclosure makes a Skill cheaper than a procedure in every prompt
- What actually changes when a second consumer appears for a custom tool
- List four things you want a Claude application of yours to do, chosen so at least one is an action in a private system, one is a procedure your team keeps re-pasting, and one is something the platform probably already provides
Why: The sequence is only a skill once it has been run against requirements you already understand, where you can check the answer against what you know about your own systems.
You should see: Four one-line requirements, visibly different in kind.
- Assign a mechanism to each before writing any code, and write one sentence per assignment naming which question in the sequence decided it: platform-provided, do-versus-know, second consumer, or occasional procedural knowledge
Why: The exam tests the justification rather than the label, and an assignment you cannot defend from the requirement is a guess.
You should see: Four assignments, each with a one-sentence defence naming a question.
- Package the procedure as a Skill, with a description saying both what it does and when to use it. Confirm it triggers on a request that needs it and stays out of the way on one that does not
Why: The description is the trigger, and watching it fire and not fire is the only way to feel the difference between a description of what and a description of when.
You should see: The Skill loading on the matching request and not loading on the other one.
- Implement the action as a custom tool inside one application, then write down precisely what would have to change if a second application needed it next month, and whether that change is a rewrite or a relocation
Why: The second consumer is the sharpest signal in a stem, and having done the move once makes the false rebuild objection obvious when a distractor raises it.
You should see: A short list of what moves and what stays: the same implementation, a protocol boundary, a deployment and an owner.
- Check the one you were most confident about against the current docs: is the capability you assumed the platform provides actually provided, and does it execute on Anthropic infrastructure or on yours
Why: The inventory moves between releases and built-in is not a synonym for server-executed, so this last check is the habit that keeps a dated fact from becoming a wrong answer.
You should see: Either a confirmation or a corrected assignment, with the date you checked it.
Sources
- Agent Skills — Anthropic, the definition, progressive disclosure and its three levels, the field constraints, the per-surface runtime constraints and the no-sync rule
- Skill authoring best practices — Anthropic, writing a description that triggers
- Using Agent Skills with the API — Anthropic, the code execution tool, the container parameter with skill_id, combining pre-built and custom Skills, and versions as complete snapshots
- Tool reference — Anthropic, the split between Anthropic-executed server tools and Anthropic-schema client tools
- Browser use tool — Anthropic, a client toolset your application runs, and when to choose it over web fetch, web search and computer use
- Code execution tool — Anthropic, the three current tool versions
- Server tools — Anthropic, what server-side execution does and does not require of you
- MCP connector — Anthropic, reaching a shared MCP server from the Messages API
- Equipping agents for the real world with Agent Skills — Anthropic, the architecture behind Skills and where they fit alongside tools
- Architecture overview — Model Context Protocol, one implementation serving many clients
- Claude Certified Developer Foundations Exam Guide — Domain 8, Agentic Customization — Anthropic