What you will be able to do
- Tell apart Anthropic-provided client tools, server tools and user-defined tools by who writes the schema and where the code runs
- Decide when an agent's built-in tools are enough and when a custom tool is worth writing
- Explain how a skill's progressive disclosure keeps unused know-how out of the context window
- Choose MCP, a skill, or both for a given need, and explain the context cost of each
Key concept
Connections vs know-how — Tools and MCP servers give Claude something to call: an action that code carries out, locally or in an external system. Skills give Claude something to read and follow: a procedure or reference that loads only when the task needs it. Many real setups need both.
1.Built-in tools first, custom tools for domain actions
You can extend Claude in four ways: tools Anthropic already provides, tools you write yourself, skills that carry know-how, and MCP servers that connect it to outside systems. Choosing wrongly costs you one of two things. Either you write code you didn't need, or you spend context you didn't need to spend. The first split is in tool use itself, which lets Claude call functions that you define or that Anthropic provides.
Anthropic-provided tools come in two kinds, and where the code runs separates them. Server tools such as web_search, web_fetch and code_execution run on Anthropic's infrastructure, so your application has no handler to write. Anthropic-schema client tools such as bash and text_editor work differently. Anthropic writes the schema and trains Claude on it, but your application still runs every call and returns the tool_result. When a tool is "built in", that tells you who designed it. It does not tell you who executes it.
| Kind | Who writes the schema | Who executes the call | Examples |
|---|---|---|---|
| User-defined client tool | You | Your application | get_weather |
| Anthropic-schema client tool | Anthropic | Your application | bash, text_editor |
| Server tool | Anthropic | Anthropic's infrastructure | web_search, web_fetch, code_execution, tool_search |
Start with the built-in tools. Claude Code and the Agent SDK already ship tools for the everyday work of an agent: Read, Edit, Write, Bash, Grep, Glob, WebFetch and others. In the SDK you enable them by name in allowed_tools. Say the job is a one-off refactor that reads files, runs shell commands and searches the codebase. That job needs no new code at all. Bash on its own lets the agent do flexible, general-purpose work on a computer. The built-in list can also be cut down: pass a tools array that lists only the built-ins you want, and the rest stay out of Claude's context.
A custom tool earns its place when the action belongs to your domain and the agent will take it often. A custom tool is a name, a description and an input_schema, and your own code runs each call. The mechanics are taught in [defining and handling custom tools](lesson:8.1). In the Agent SDK, you register custom tools through an in-process MCP server so that Claude can call your functions, reach your APIs and carry out domain-specific operations. An email agent is the standard example. fetchInbox and searchEmails are the actions it takes over and over, so they become tools. Keep that set small. Rather than separate create_pr, review_pr and merge_pr tools, define one tool with an action parameter. Fewer tools give Claude fewer to choose between and less ambiguity when it picks one.
Checkpoint 1 of 8· Check yourself
Anthropic wrote the schema for one of these tools and trained Claude on it, but your application still has to run each call and send back a tool_result. Which one?
text_editor (like bash) is a client tool with an Anthropic-defined schema, so it runs in your application. The other three are server tools that run on Anthropic's infrastructure.
“Client tools (including user-defined tools and tools with Anthropic-defined schemas, such as bash and text_editor) run in your application.”Source: platform.claude.com
Checkpoint 2 of 8· Exam question
A platform team keeps pasting the same multi-step production deployment checklist into chat every time someone ships a release, and the steps sometimes get skipped when typed manually. What is the most appropriate way to address this in Claude Code?
Correct answer: A — Capture the checklist as a Skill invoked with a slash command like /deploy
- A. Correct: a repeated multi-step procedure pasted into chat is the canonical trigger for turning it into a Skill, which loads on demand via /deploy instead of being retyped.
- B. CLAUDE.md is meant for always-on conventions loaded every session; a deployment procedure is a workflow rather than a persistent fact, so it belongs in a Skill instead.
- C. MCP servers connect Claude to external systems and expose tools or resources from those systems; building one just to store static checklist text adds unnecessary infrastructure.
- D. A custom tool wraps a function Claude calls to perform an action or fetch data; simply printing static text is not a tool's purpose and adds needless complexity for no benefit.
2.Skills: know-how that loads only when needed
A skill packages a procedure rather than an action. It is a directory with a SKILL.md file of instructions and metadata, plus optional scripts, templates and reference files, and Claude uses it automatically when it fits the task. Typical contents are a deployment checklist, a code review procedure, or an API style guide. These are things you would otherwise paste into chat at the start of every session.
---
name: pdf-processing
description: Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.
---Only two fields are required: name and description. name can be at most 64 characters, using only lowercase letters, numbers and hyphens. description can be at most 1024 characters. The description does the real work. Claude compares each request against it to decide whether to trigger the skill, so it has to say what the skill does and also when to use it. A description like "PDF helper" fails because it never says when.
Progressive disclosure means a skill loads in stages rather than all at once. At startup the system prompt holds only each skill's name and description. When a request matches a description, Claude uses bash to read SKILL.md from the filesystem, and only at that point does the body enter context. Bundled files load only if those instructions point to them. Scripts are the cheapest part: Claude runs them, and only their output enters context. Their code never does. A skill can therefore bundle a large API reference at no cost until Claude actually opens a file from it.
| Level | When loaded | Token cost | Content |
|---|---|---|---|
| Level 1: Metadata | Always (at startup) | ~100 tokens per Skill | name and description from YAML frontmatter |
| Level 2: Instructions | When Skill is triggered | Under 5k tokens | SKILL.md body with instructions and guidance |
| Level 3+: Resources | As needed | None until accessed | Bundled files; scripts run through bash and only their output enters context |
Skills are triggered in two ways. You can type /<name>, or Claude can match the description to your task. In Claude Code they are plain directories: ~/.claude/skills/ for personal skills and .claude/skills/ for project skills, with no upload step. On the Claude API they run inside the code execution tool's container, so using skills there requires that tool. A skill can direct Claude to call tools and run code, so treat one from an unknown source the way you would treat software you are about to install.
Checkpoint 3 of 8· Put it in order
A user asks Claude to extract the text from a PDF and summarize it, and a custom pdf-processing skill is installed. Put the steps in order.
- 1.Claude completes the task using the SKILL.md instructions
- 2.At startup, the system prompt lists the skill's name and description
- 3.Claude runs cat on pdf-processing/SKILL.md, bringing its instructions into context
- 4.The user asks Claude to extract the text from the PDF and summarize it
- 5.Claude decides form filling isn't needed and leaves FORMS.md unread
The metadata is already in the system prompt before the request arrives. The body loads only once the request matches, and the bundled FORMS.md stays unread because this task doesn't need it.
“Claude determines: Form filling is not needed, so FORMS.md is not read”Source: platform.claude.com
Checkpoint 4 of 8· Fill the gap
Which frontmatter field does Claude match your request against when it decides whether to trigger this skill?
---
name: your-skill-name
? : Brief description of what this Skill does and when to use it
---name and description are the only required fields, and description is the one that decides when the skill fires. It must state both what the skill does and when to use it.
Source: platform.claude.com3.MCP for connections, skills for procedures
Use MCP when Claude has to reach a system it can't otherwise see, and a skill when it needs to know how to do something. MCP is a protocol for connecting to external services, and it gives Claude tools and data access: posting to Slack, querying a database, controlling a browser. A skill gives Claude knowledge, workflows and reference material. A simple test helps. If you keep copying data out of a browser tab that Claude can't see, connect that system as an MCP server. If you paste the same multi-step playbook into chat for the third time, turn it into a skill. Building the server itself is covered in [MCP server development](lesson:8.2).
| Aspect | MCP | Skill |
|---|---|---|
| What it is | Protocol for connecting to external services | Knowledge, workflows, and reference material |
| Provides | Tools and data access | Knowledge, workflows, reference material |
| Examples | Slack integration, database queries, browser control | Code review checklist, deploy workflow, API style guide |
The two also differ sharply in what they cost in context. Everything Claude reads in a turn counts against the [context window budget](lesson:6.1), and tool definitions are part of it. The API builds a system prompt from the tool definitions you pass. Most MCP clients load every tool definition upfront, so an agent wired to thousands of tools reads hundreds of thousands of tokens before it even sees the request. A skill pays about 100 tokens until it is triggered. When the tool list itself is the problem, tool search lets Claude load tools on demand instead of all at once.
The strongest setups combine the two. The MCP server provides the connection, and a skill teaches Claude how to use it well. Take an analytics database. MCP lets Claude run queries against it, but it says nothing about which tables matter or how your team writes joins. A skill holding the schema notes and query patterns covers that, and it loads only when a database question comes up.
Checkpoint 5 of 8· Check yourself
A team wants Claude to run queries against their PostgreSQL database and to follow the team's documented schema conventions and query patterns while doing so. What fits best?
Reaching the database is a connection, so it calls for MCP. The conventions are know-how, so they belong in a skill that loads only when needed. This is the documented Skill + MCP pattern.
“MCP connects to your database, a skill documents your schema and query patterns”Source: code.claude.com
Checkpoint 6 of 8· Exam question
An engineering team already has a working internal Slack bot with OAuth handled by Anthropic's published Slack MCP server. They now want Claude Code to post release notes to a channel. What should they do instead of writing a custom tool from scratch?
Correct answer: A — Connect the existing Slack MCP server so Claude reuses its messaging tools and authentication
- A. Correct: when a maintained MCP server already exists for a service, connecting to it reuses its authentication and tool definitions instead of duplicating that work in a custom tool.
- B. Reimplementing the OAuth flow and API client duplicates work the existing MCP server already solved, adding maintenance burden without adding capability.
- C. A Skill can describe how to use a tool, but it cannot itself authenticate or make network calls, so release notes would never actually reach Slack.
- D. Shelling out with curl bypasses structured tool schemas and error handling, and requires managing credentials manually inside the Bash environment.
4.Choosing among built-in tools, custom tools, skills and MCP
Work through the options in order of cost. First, check whether the built-in tools already cover the job. File reads, edits, shell commands and code search usually are. Next, ask whether Claude needs to reach an external system: if so, connect it over MCP. If Claude can reach everything but keeps getting a procedure wrong, write a skill. Write a custom tool only for a domain action the agent repeats often and that no existing tool expresses cleanly. When a second repository needs the same setup, package it all as a plugin, which is how these features are bundled and distributed.
| Extension | Gives Claude | Wins when | Context cost |
|---|---|---|---|
| Built-in tool (Read, Edit, Bash, Grep) | General file, shell and search actions | The task is reading, editing, running and searching code | Definitions of the tools you leave enabled |
| Custom tool | A domain action backed by your function or API | The agent takes the action often and no built-in expresses it | Its definition, on every request |
| Skill (SKILL.md) | A procedure or reference material | You keep pasting the same playbook or workflow | Description each session; body only when used |
| MCP server | Tools and data from an external system | Claude needs data or actions it can't otherwise reach | Tool definitions, often all loaded upfront |
| Plugin | A packaged bundle of these features | A second repository needs the same setup | Whatever the bundled features cost |
Checkpoint 7 of 8· Match them up
Match each need to the extension that fits it
Tap a term, then the definition that fits it.
Generic file and shell work is what the built-ins already ship for. An outside service needs a connection. A repeatable procedure is know-how. Distributing a setup is the job of a plugin.
“Plugins and marketplaces package and distribute these features”Source: code.claude.com
Checkpoint 8 of 8· Exam question
A fintech startup is building an internal support agent with the Claude Agent SDK. The agent must look up account balances from a proprietary ledger service reachable only through an internal REST gateway with no existing MCP server or public SDK. Which approach best fits this requirement?
Correct answer: A — Define a custom tool that calls the internal REST gateway and register it through an in-process MCP server
- A. Correct: a custom tool wraps the handler logic for calling the proprietary gateway and is registered via create_sdk_mcp_server/createSdkMcpServer, giving Claude a purpose-built function for this internal system.
- B. WebFetch is a general-purpose built-in tool for parsing public web pages; it is not designed for authenticated internal gateway calls with structured request/response handling.
- C. A Skill supplies knowledge or workflow instructions, not a live connection to an external system, so Claude would have no way to actually retrieve real balance data.
- D. No public integration exists for this proprietary internal service, so a community MCP server would not have the credentials or schema to reach it.
Sources7
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Because Anthropic defines the bash and text_editor schemas, Anthropic also executes those tools.Why is that wrong?
They are client tools. Anthropic supplies the schema, but your application runs each call and returns the tool_result. Only server tools such as web_search run on Anthropic's side.
Covered in Built-in tools first, custom tools for domain actions
2.Installing many skills fills the context window, because each skill's instructions are loaded at startup.Why is that wrong?
At startup only each skill's name and description load. The body enters context only once the skill is triggered.
Covered in Skills: know-how that loads only when needed
3.A script bundled in a skill costs context in proportion to its length, because Claude has to read it to run it.Why is that wrong?
Claude runs bundled scripts through bash, and only their output enters context. The script's code itself never does.
Covered in Skills: know-how that loads only when needed
4.MCP and skills are alternatives, so a design has to pick one or the other.Why is that wrong?
They solve different problems and are designed to work together. MCP provides the connection, and a skill holds the know-how for using it.
Covered in MCP for connections, skills for procedures
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Tool use (also called function calling) lets Claude call functions that you define or that Anthropic provides.”
↩︎ Built-in tools first, custom tools for domain actions“Server tools (such as web_search, web_fetch, code_execution, and tool_search) run on Anthropic's infrastructure”
↩︎ Built-in tools first, custom tools for domain actions“Anthropic publishes the schema and trains Claude on it. Your application still executes each call and returns the tool_result.”
↩︎ Exam trap 1“Client tools (including user-defined tools and tools with Anthropic-defined schemas, such as bash and text_editor) run in your application.”
↩︎ Checkpoint - 2.https://platform.claude.com/cookbook/claude-agent-sdk-04-migrating-from-openai-agents-sdkSecondary source
“the SDK ships Read, Edit, Bash, Grep, and more — add them to allowed_tools by name”
↩︎ Built-in tools first, custom tools for domain actions - 3.
“Bash is useful as a general-purpose tool to allow the agent to do flexible work using a computer.”
↩︎ Built-in tools first, custom tools for domain actions“As such, your tools should be primary actions you want your agent to take.”
↩︎ Built-in tools first, custom tools for domain actions - 4.
“Pass a tools array listing only the built-ins you want.”
↩︎ Built-in tools first, custom tools for domain actions“Define custom tools with the Claude Agent SDK’s in-process MCP server so Claude can call your functions, hit your APIs, and perform domain-specific operations.”
↩︎ Built-in tools first, custom tools for domain actions“Use tool search to load tools on demand.”
↩︎ MCP for connections, skills for procedures - 5.
“Fewer, more capable tools reduce selection ambiguity and make your tool surface easier for Claude to navigate.”
↩︎ Built-in tools first, custom tools for domain actions“the API constructs a special system prompt from the tool definitions, tool configuration, and any user-specified system prompt.”
↩︎ MCP for connections, skills for procedures - 6.
“Each Skill packages instructions, metadata, and optional resources (scripts, templates) that Claude uses automatically when relevant.”
↩︎ Skills: know-how that loads only when needed“The description is what Claude matches your request against when determining whether to trigger the Skill”
↩︎ Skills: know-how that loads only when needed“Claude reads SKILL.md from the filesystem using bash. Only then does this content enter the context window.”
↩︎ Skills: know-how that loads only when needed“place them in ~/.claude/skills/ (personal) or .claude/skills/ (project).”
↩︎ Skills: know-how that loads only when needed“Prerequisites: Using Skills through the API requires the code execution tool, whose container Skills run in.”
↩︎ Skills: know-how that loads only when needed“a malicious Skill can direct Claude to invoke tools or execute code in ways that don't match the Skill's stated purpose.”
↩︎ Skills: know-how that loads only when needed“This lightweight approach means you can install many Skills without context penalty: until a Skill is triggered, only its name and description occupy context.”
↩︎ Exam trap 2“When Claude runs validate_form.py, the script's code never loads into the context window.”
↩︎ Exam trap 3“~100 tokens per Skill”
↩︎ Prediction“Claude determines: Form filling is not needed, so FORMS.md is not read”
↩︎ Checkpoint - 7.https://code.claude.com/docs/en/features-overviewOfficial docs
“You typing /<name>, or Claude matching the description to your task”
↩︎ Skills: know-how that loads only when needed“Connect that system as an MCP server”
↩︎ MCP for connections, skills for procedures“You paste the same playbook or multi-step procedure into chat for the third time”
↩︎ MCP for connections, skills for procedures“MCP provides the connection; a skill teaches Claude how to use it well”
↩︎ MCP for connections, skills for procedures“Package it as a plugin”
↩︎ Choosing among built-in tools, custom tools, skills and MCP“Plugins and marketplaces package and distribute these features”
↩︎ Choosing among built-in tools, custom tools, skills and MCP“Description loads each session; full content loads when used”
↩︎ Choosing among built-in tools, custom tools, skills and MCP“MCP provides the connection; a skill teaches Claude how to use it well”
↩︎ Key concept“MCP provides the connection; a skill teaches Claude how to use it well”
↩︎ Exam trap 4“MCP connects to your database, a skill documents your schema and query patterns”
↩︎ Checkpoint - 8.https://www.anthropic.com/engineering/code-execution-with-mcpSecondary source
“Most MCP clients load all tool definitions upfront directly into context, exposing them to the model using a direct tool-calling syntax.”
↩︎ MCP for connections, skills for procedures“In cases where agents are connected to thousands of tools, they’ll need to process hundreds of thousands of tokens before reading a request.”
↩︎ MCP for connections, skills for procedures