What You Need to Know
Four mechanisms give a Claude application something it lacks. Built-in tools are capabilities that Anthropic provides. The platform defines their schema. For the server-executed ones, the platform also runs them. Custom tools are functions you define and your own code executes. Skills are packaged procedural knowledge. A Skill is a SKILL.md file with YAML frontmatter (a block of YAML at the start of the file), optionally bundled with reference files and executable scripts. Claude loads a Skill when it is relevant. MCP servers expose a capability over a standard protocol, so several clients can connect to one implementation. This sub-skill is about choosing between the four.
This lesson uses one made-up example throughout: a helpdesk software company that wants to extend the Claude assistant its support staff use. It wants four things. The assistant should read service status from a cloud provider's public status page. It should find customer accounts and open tickets in the company's own database. It should write monthly service reports that follow the company's own rules. These rules are several pages long, and they matter on about one job in five. And it should respect a rule about which unpaid accounts may be closed without a manager checking. A second application will also soon need the account lookup: the internal app that the billing team uses. Each requirement belongs in a different place.
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 company's status lookup fits: the provider's status page is public, and the platform already fetches pages. A custom fetcher would be work the team did not need.
The cost of built-in tools is a limit on what they can 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 company's accounts are on its own private network, so web fetch cannot query them. To reach an internal system, you need code that runs in a place where 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: a set of tools whose schema Anthropic defines and that your application runs. Claude works with a page's structure and screenshots. Your application runs every call against its own browser, and nothing runs on Anthropic's side. The docs state clearly when to use it. Choose it when the task acts on webpages and stays inside 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 company only reads the status page, 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 into two groups. Server tools execute on Anthropic's infrastructure. Client tools have a schema Anthropic defines, but your application executes them. 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 are on the client side, and your own process runs them. So it is unsafe to assume that every built-in tool runs on Anthropic's servers. Depending on memory of which list contains a named tool is unsafe too. The reason is that the membership of both lists is true only on a given date, and it changes. The capability boundary is what a tool can reach. That boundary is stable.
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 amount of instruction replaces a tool. A Skill that describes a private system's schema, query conventions and field meanings in full still does not perform the lookup. Instructions do not give access to a system. 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 company'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 that Claude applies it without using space in every request. A business's own reporting conventions, a document template, a review checklist and a written procedure that a team pastes again and again are all knowledge. The company's report rules are knowledge. The assistant can already write a service report. It does not follow the company's layout every time.
The two wrong assignments are opposites. One wrong assignment builds "a tool that returns the checklist". The sign that 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 that it is wrong: no amount of instruction supplies access.
One requirement usually needs both a Skill and a tool
Teaching the two as alternatives makes people search for the single best mechanism, but the task needs an assignment. At the helpdesk company, the tool fetches a customer's account and the Skill controls how the assistant writes the report about that account. An agent with one and not the other fails in a way that the missing mechanism would have fixed. Suppose an answer gives the same mechanism to every requirement in a mixed list. That uniformity alone almost always makes the answer wrong.
Progressive Disclosure Is the Argument
Progressive disclosure, which loads a Skill's full instructions only when needed, makes Skills cheap to install. It is also the reason that a Skill is better than pasting a procedure into every prompt. The docs describe 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. This fact changes the comparison. The choice is not really Skill against tool at all. It is a Skill against carrying several pages of the business's own conventions on every request. For the helpdesk company, that means the report rules go with every request, including the four jobs in five that never use them.
The description decides whether the Skill is triggered. 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 Skill with a description that says only what the Skill does will stay unused. The example below says both. It is the helpdesk company's Skill, which holds its report rules.
---
name: service-report-conventions
description: House conventions for writing monthly customer service reports - section order, how to express response times, which caveats are mandatory, and the sign-off block. Use when drafting, revising or reviewing a service report.
---
# Service report conventions
## Section order
1. Customer and reporting period
2. Ticket counts, including the open tickets at the start and end of the month
...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 (each product that can run Skills, such as the Claude API), and the differences affect 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, for the same company, 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 service report for account 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 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?
When one application and one team need it, and nothing else ever will, a custom tool is the right choice. It is simpler and has no deployment to plan. For several surfaces, or a system whose owning team should own its integration, use an MCP server.
An MCP server has real costs, and they have to be counted. A reader who learns only its benefits will answer MCP to every question. A remote server is a service. It has an availability expectation, an access-control design and an operational owner. If you choose it for a capability that exactly one application will ever use, you accept all of those costs and get no reuse.
The strongest signal is a second consumer, actual or imminent: another application that needs the same capability. The company's account lookup already has an imminent second consumer: the billing app. So the lookup belongs on an MCP server from the start. If no second application had been planned, a custom tool inside the assistant would have been enough, and the later move is cheap. The move puts 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 appear 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 by its nature it is stale for a system whose value is its current state. The company's extract would miss any ticket a customer opened that morning. The extract uses context on every call, including the majority of calls 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. The copies drift: they become different from each other, and nobody knows which copy is authoritative. Every request also carries the whole procedure, including requests that never use it. The case for MCP makes the same argument about drift between integrations. For knowledge, the answer has the same form: one authoritative place, which is loaded when relevant.
Assuming a built-in tool can reach an internal service. The reasoning is: 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. It runs in the platform's environment.
Choosing fine-tuning. Fine-tuning is a genuine technique. It is expensive and slow. When the issue is packaging knowledge or tooling, fine-tuning targets the wrong class of problem. 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? The platform covers searching the public web, fetching a page and running code in a sandbox. As of September 2026, it also covers acting on webpages in a browser that 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 question indicates an MCP server. No to both indicates 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.
Apply the four questions to the helpdesk company. The provider's status page gets a yes to question one, so the platform covers it and a fetcher would duplicate work. The account lookup needs the model to do something in a system, so it is code that runs where the database is reachable. Question three depends on the billing app. That second consumer is imminent, so the lookup goes on an MCP server now. The report layout is knowledge, 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 (the set of tools the assistant can call) expresses the policy and the harness (your own code around the model) enforces it. 8.1 and Domain 7 cover these two parts 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 that only that application uses. One MCP server holds a capability that another team in the same organisation also needs. A Skill or two carry the conventions that shape the output. They fit together because each answers a different question.
Several Skills can also be used together. As of September 2026 one API request can carry up to 20 Skills in its container. So one request can carry an Anthropic pre-built Skill such as xlsx and a custom Skill that holds your organisation's layout rules and template. The Skills guide's own example pairs the Excel Skill with a custom DCF analysis Skill. DCF (discounted cash flow) is a method for valuing a company. 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 questions 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 in which to apply them. The hardest questions list three or four requirements in one scenario and ask for an assignment. They place one or two arguable requirements deliberately. If you run the four questions for each requirement, you answer all of them correctly. A candidate with only definitions stalls on the second and picks the option that assigns everything to one mechanism. That uniformity is the sign that the option is wrong.
Skill against tool is the distinction tested most reliably. The two almost-right options, the checklist tool and the documenting Skill, are deliberately attractive. The name and description limits are examinable on their own. The four common mistakes make tempting wrong answers for the reason given above: each is a reasonable idea misapplied.
The exam guide states the built-in boundary in one clause. That clause is in its published rationale for the Domain 8 sample: built-in tools "do not automatically reach arbitrary internal APIs". Remember that clause as one sentence for the exam. Any option that claims a platform-provided fetch or search capability can reach an internal service is wrong, however the option is worded. The same sample states the second part: reaching an internal system needs a custom tool or an MCP server. The guide also rejects pasting data 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 makes the MCP server the correct answer because of reuse and ownership. Suppose a question states a second consumer or independent maintenance. Then an option that argues that a custom tool could do the same thing answers a question that the scenario did not ask. When a question is about where information is stored or what the model can call, fine-tuning answers neither question.
Two refinements decide most questions here. Built-in does not mean server-executed. The membership of every list changes between releases. First answer from what each mechanism can and cannot do. Where a tool runs only matters when the question says so, in the question text or in the options. Do not assume a location that the question leaves out, and do not depend on today's list of built-in tools.
Dated Facts
The membership of every one of these lists changes between releases. Learn the boundaries, which are stable, and treat any specific inventory as correct as of its date. The domain quick reference carries the inventory with its date. This lesson teaches the boundary. Suppose a question depends on whether a named tool exists today, or on where a tool runs when the question never states this. That question tests something that may be false next quarter.
Exam Traps
Choosing a platform-provided tool to reach an internal API because it already fetches over HTTP
A server-executed tool such as web fetch runs in the platform's environment, which cannot see your private network. The exam guide says built-in tools do not automatically reach arbitrary internal APIs. Use a custom tool or MCP server, where the system is reachable.
Choosing a Skill that documents a private system thoroughly enough for Claude to perform the lookup
A Skill supplies knowledge, not capability. On the Claude API its container has no network access, so documenting the system cannot make the lookup possible. Give Claude a custom tool or MCP server that can reach it.
Arguing that a custom tool can do the same job when a second application needs the capability
Capability does not decide it when the requirement is reuse or independent maintenance; a custom tool can do the job either way. The guide's Domain 8 sample places the MCP server there. For a single application, MCP adds a deployment for no reuse.
Reading Anthropic-provided as Anthropic-executed
Anthropic ships server tools it executes and client tools whose schema it defines but whose execution is yours. Answer from the capability boundary, assume no location the question leaves out, and do not rely on today's list of built-in tools, which changes between releases.
Practice Scenario
An expense management software company is extending its Claude-based assistant with four things. It must look up expense-claim records in the company's own database. It must apply the company's own reporting conventions, which are several pages long, 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 tax authority site. And the claim-record lookup will shortly also be needed by a second application that a partner accounting firm 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: You learn the sequence only when you run it 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 does not load on one that does not
Why: The description decides whether the Skill is triggered, and watching it load and not load is the only way to see 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 strongest signal in a question, and having done the move once makes the false rebuild objection obvious when a wrong option 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 list of tools changes between releases and built-in is not a synonym for server-executed, so this last check is the habit that stops a fact that was true only on an earlier date 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