Home › Study guides › CCDV-F › Domain 8 › Lesson 8.3

CCDV-F · Domain 8 · 10.6% of the exam · Lesson 8.3 · 21 min read

Built-in tools, custom tools, Skills or MCP: choosing the right extension

How to choose between built-in tools, custom tools, Skills and MCP servers by reuse, ownership, where the code runs and security, and how to combine them.

Written against skill 8.3 of the official CCDV-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

8.3.1 Why one assistant needs four kinds of help

Picture a new copywriter's first morning at a marketing agency. Before writing anything useful, they need a browser for this week's market news, a login to the client database, the agency's style handbook and access to the shared drive of logos and photos. Nobody hands those over in the same way. The browser is already on the laptop, IT issues the login, the handbook sits on a shelf until a job needs it, and the shared drive belongs to a team that serves the whole company.

Paloma, a back-end developer at Brightfold, a mid-sized marketing agency, is building that colleague in software: a content assistant on the Claude API that drafts blog posts and launch announcements for clients. Her prototype is a plain model call with a long system prompt, the standing instructions sent with every request. The copy is fluent, but it cites a trend from two years ago, invents a client contact, blends two clients' tone of voice and describes a hero image it has never seen. The model is not at fault: a model call knows only its training data and whatever you put in the request.

The assistant needs four things: current web information, client records from the agency's customer relationship management (CRM) system, each client's brand-voice rules, and the logo and photo library that three other internal apps share. Claude can be extended in four ways, one for each kind of need. Built-in tools are capabilities Anthropic or Claude Code already provides, such as web search. Custom tools are functions you define and your own application runs. Skills are folders of instructions, reference files and scripts that Claude loads when a task calls for them. MCP servers expose tools through the Model Context Protocol (MCP), an open standard, so any compatible application can use them.

8.3.2 Built-in tools: use what already exists

Paloma's first instinct is to write a search_news function that calls a search API and scrapes the result pages. It is a natural reflex, and usually wasted work. Ask first: does a tool for this job already exist?

Built-in tools are capabilities someone else already built and maintains. They come in three kinds, which differ in who runs the code.

Memorise the server-tool row; recognise the other two. For web information, Paloma adds one entry to her request's tools list, {"type": "web_search_20250305", "name": "web_search", "max_uses": 5}, and writes no handler code at all. Anthropic runs the searches, and the answer comes back with citations. She pays $10 per 1,000 searches plus the tokens the results add (tokens are the word pieces the API counts and bills). max_uses caps the searches per request, and allowed_domains or blocked_domains (one or the other) limit where results come from. An organisation administrator can also switch web search off in the Claude Console.

The limit is just as important. A built-in tool reaches only what it was built for. Web search sees the public web, not Brightfold's CRM behind a login. Code execution runs in a sandbox, an isolated container on Anthropic's side with no network access, not inside the agency's network. Claude Code's built-ins act on the machine they run on. None of them becomes an integration with an internal system just because it is built in.

8.3.3 Custom tools: your code in front of your system

Brightfold's CRM holds client contacts, campaign history and each client's approved product claims. No built-in tool can reach it, and only the content assistant needs it. This is the job for a custom tool.

A custom tool is a name, a description and an input schema (a JSON Schema for its arguments) that you send in the request's tools list. When Claude wants it, the response carries a tool_use block with the tool's name and inputs; your code runs the real operation and returns the answer in a tool_result block. Claude never sees the implementation, only the schema and the result.

That is why private systems belong behind custom tools. The CRM key stays in Paloma's back end and never enters a prompt. Her handler checks that the signed-in account manager works on the client before it returns anything, and it trims the record to the fields the draft needs. Think of a bank teller: you ask for your balance, the teller checks who you are and looks it up, and you never get the keys to the vault.

The trade-off is reach. A custom tool is the quickest mechanism to build and change, because it ships with your application, but it lives only in that application. If the agency's social-media scheduler later needs CRM data too, copying the function means two copies to keep in step. That is the signal to move the capability behind an MCP server. In Claude Code and the Claude Agent SDK (Anthropic's library for building agents), the line between a custom tool and an MCP server blurs. Claude Code adds your own tools only by connecting an MCP server. The Agent SDK defines custom tools in an MCP server that runs inside your own process.

8.3.4 Skills: knowledge that loads when it is needed

Brightfold keeps voice sheets for 30 clients, a list of banned phrases and a template for each content format. Paloma pasted all of it into the system prompt, so every request carries every client's rules, and Claude still blends two clients now and then.

A Skill is a folder with a SKILL.md file plus any reference files, templates and scripts the procedure needs. It loads in stages, which Anthropic calls progressive disclosure. The name and description from the file's front matter (the YAML header at the top) are always in Claude's context, the text it sees on a request, at about 100 tokens per Skill. The body of SKILL.md loads only when a request matches the description. Other files load, and scripts run, only when the instructions call for them, and a script's code never enters the context, only its output.

Think of the style handbook on the shelf: the spine says what is inside, you open it only for a relevant job, and you turn only to the chapter for the client at hand. For Paloma, that means the 30 voice sheets stop costing tokens on every request, and a draft for one client never loads another client's sheet.

Here is Paloma's Skill. Look at the description, which tells Claude when to load it, and at step 4, which runs a script for a check that should not depend on judgement.

---
name: brand-voice
description: Client brand voices and Brightfold house style. Use when drafting or editing copy for any Brightfold client.
---

# Writing in a client's voice

1. Read `voices/<client-slug>.md` for the client you are writing for, and no other voice file.
2. Follow `house-style.md`: British spelling, no claims about competitors.
3. Start from the template in `templates/` that matches the format requested.
4. Before returning a draft, run `python scripts/check_voice.py draft.txt <client-slug>`
   and fix every phrase it flags.

Where a Skill runs depends on the surface. On the API, you upload it once through the Skills API, which shares it with everyone in your API workspace, and list it in a request's container, with the code execution tool enabled. It then runs in the code execution sandbox, with no network access. In Claude Code, it is a folder in .claude/skills/ for the project or ~/.claude/skills/ for you, with the same network access as any program on that computer. Skills do not sync between surfaces.

A Skill is not a connection: an API Skill cannot call the CRM. Nor is it enforcement: Claude reads the instructions and applies them, so a rule that must always hold belongs in tool code. And treat a third-party Skill like software you install, because it can direct Claude to run code.

8.3.5 MCP servers: one integration for many applications

The shared digital asset library holds logos, product photos and licensed stock images, and Arvid's team owns it. When the social-media scheduler became the second app to need it, the team replaced per-app integrations with an MCP server, which the design team's brief builder, the scheduler and the client portal all use today. Paloma could still write her own search_assets custom tool against the library's API. It would sit outside the server, with its own credentials and its own idea of what "licensed for social media" means, and it would break the next time that API changed.

The Model Context Protocol is an open standard for connecting AI applications to external systems. An MCP server exposes tools, and can also offer resources (data) and prompts (reusable templates). Any MCP client can use it: Claude Code (a committed .mcp.json shares it with the whole team), the Claude apps as a connector, the Agent SDK, and your own API application. Think of a standard wall socket. The utility maintains the supply once, and any appliance with the right plug can draw on it; nobody rewires the house for a new lamp.

For her API application, Paloma uses the MCP connector, a Messages API feature in beta. Her request adds an mcp_servers entry with the server's URL (and an OAuth access token if the server requires one) and an mcp_toolset entry in tools. It also sends the mcp-client-2025-11-20 beta header, which opts in to the feature. The API connects to the server and calls its tools, so she writes no MCP client code. The toolset also lets each application enable only what it needs: Paloma turns on search_assets and get_asset and leaves archive_asset disabled.

The price is a service someone must build, deploy, secure and run. Arvid's team pays it once for four apps. For a capability only one application will ever use, it is pure overhead, and a custom tool is the better start.

8.3.6 Choosing and combining

The question this skill tests is which mechanism fits a given need, and the requirement words decide it. Read the table by rows: each is a dimension to check against a scenario.

Memorise the Reuse and Where-it-runs rows; on their own they decide most choices. The decision takes three questions, in order:

1. Knowledge or action? If Claude needs to know HOW to do something and reaches nothing live, it is a Skill.
2. Already built? If a built-in covers the need, such as current public information or sandboxed analysis, enable it.
3. Who else needs it? A private capability that one application uses is a custom tool. One that several applications share, or that another team owns, is an MCP server.

The mechanisms also combine. A common pairing is a Skill with tools: the tool or MCP server provides the connection, and the Skill teaches Claude to use it well. Paloma adds one line to her Skill: check an image's usage rights with get_asset before suggesting it. Here is the request that wires all four together. Look at the container, mcp_servers and four tools entries. Only get_client_profile ever comes back to Paloma's code as a tool_use block: Anthropic runs the search and the Skill's sandbox, and the API calls the MCP server itself.

response = client.beta.messages.create(
    model=MODEL, max_tokens=4096, messages=messages,
    betas=["mcp-client-2025-11-20"],                  # the MCP connector is in beta
    container={"skills": [{"type": "custom", "skill_id": BRAND_VOICE_ID,
                           "version": "latest"}]},    # SKILL: loads when relevant
    mcp_servers=[{"type": "url", "name": "asset-library",
                  "url": "https://assets.brightfold.example/mcp",
                  "authorization_token": asset_token}],
    tools=[
        {"type": "web_search_20250305", "name": "web_search", "max_uses": 5},  # BUILT-IN
        {"type": "code_execution_20250825", "name": "code_execution"},  # sandbox the Skill runs in
        get_client_profile,                           # CUSTOM: your back end runs it
        {"type": "mcp_toolset", "mcp_server_name": "asset-library",  # MCP: shared server
         "default_config": {"enabled": False},        # allowlist: only two tools
         "configs": {"search_assets": {"enabled": True}, "get_asset": {"enabled": True}}},
    ],
)

8.3.7 The exam traps

Almost every mistake here puts a need in the wrong mechanism.

• ✗ Assuming a built-in tool can reach internal systems. ✓ Web search sees the public web and code execution runs in Anthropic's sandbox. A private system needs a custom tool or an MCP server.
• ✗ Writing your own search or scraping tool when web search covers the need. ✓ Enable the server tool. Anthropic runs and maintains it, and max_uses and domain lists keep it in bounds.
• ✗ Copying the same custom tool into every application that uses a shared system. ✓ Put the integration behind one MCP server owned by the system's team, so one fix reaches every client.
• ✗ Building an MCP server for a capability only one application will ever call. ✓ Start with a custom tool, and move it behind MCP when a second application needs it.
• ✗ Pasting a long playbook into every system prompt, or serving static guidance through a tool. ✓ Package procedure and reference material as a Skill, which loads only when relevant.
• ✗ Treating a Skill as a security boundary or a way to reach a system. ✓ A Skill guides; limits and credentials belong in tool or server code, and API Skills have no network access.

8.3.8 Put it together: give each need its mechanism

You now have every piece: what each mechanism provides, who owns it, where its code runs, and the three questions that choose between them. To make the boundaries stick, build a small version of Paloma's assistant, then ask one mechanism to do another's job. The MCP connector needs a server at a public HTTPS address, so the build covers the other three; the combined request above shows where the fourth plugs in.

Three neighbouring skills go deeper into the pieces you chose. Tool implementation (8.1) covers the descriptions, schemas and error handling that make a custom tool reliable. MCP server development (8.2) is how a team like Arvid's builds and deploys a server such as the asset library's. And Claude hooks (7.3) turn a rule that must always hold into code that runs before a tool call in Claude Code and the Agent SDK, which a Skill never can.

Key takeaways

• ✓ Four mechanisms extend Claude, each for a different need: built-in tools, custom tools, Skills and MCP servers.
• ✓ Built-in tools already exist: server tools such as web search run on Anthropic's infrastructure and Claude Code's built-ins act on the local machine, but none of them is built to reach your private systems.
• ✓ A custom tool is your code in front of your system: it holds the credentials, enforces the rules and lives in one application.
• ✓ A Skill packages knowledge, procedure and scripts that load in stages when relevant; it gives no live access and enforces nothing.
• ✓ An MCP server is one integration that any MCP client can use, maintained by the system's owner, at the cost of running a service.
• ✓ Decide by what the need is and who else needs it, and combine mechanisms freely, often with a Skill that teaches Claude to use the tools.

Check your understanding

4 questions written for this lesson, then one from the CCDV-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Tool use with Claude
• Web search tool
• Agent Skills
• Using Agent Skills with the API
• MCP connector
• Extend Claude Code
• The CCDV-F exam guide, summarised