10.5 Agentic Customization: Built-in Tools, Custom Tools, Skills & MCP

Agentic Customization: Built-in Tools, Custom Tools, Skills & MCP

Exam Blueprint Focus: Agentic Customisation (4.1%) is the largest sub-skill in the Tools and MCPs domain — bigger than MCP Server Development at 2.1%. It tests one decision: given a capability you want Claude to have, which extension mechanism do you reach for? Four mechanisms exist, they overlap, and choosing the wrong one is the failure mode the exam probes.

The Four Mechanisms

1. Server tools — Anthropic executes them

Declared by type and returned with results already filled in. Your application writes no handler code:

{
  "model": "claude-opus-5",
  "max_tokens": 1024,
  "tools": [{ "type": "web_search_20260209", "name": "web_search" }],
  "messages": [{ "role": "user", "content": "What's the latest on the Mars rover?" }]
}

The server-tool family covers web search (cited results, $10 per 1,000 searches), web fetch (full page and PDF retrieval, no additional charge beyond tokens), code execution (sandboxed Python and bash, billed by container time with a free monthly allowance), the advisor tool (a faster executor model consults a higher-intelligence advisor mid-generation), and the tool search tool (discover and load tools on demand when you have thousands of them).

Choose a server tool when Anthropic already provides the capability. Writing your own web-search tool to reimplement web_search is the classic wasted effort.

2. Anthropic-schema client tools — Anthropic defines, you execute

Anthropic publishes the schema and trains Claude on it, but the code runs in your environment and you return the tool_result. This family covers the bash tool, the text editor tool, the memory tool (store and retrieve across conversations in files you control), the computer use toolset, and the browser use toolset.

The advantage over a custom tool is that Claude has been trained on the exact schema, so calling reliability is higher than for a tool you invent. The obligation is that you sandbox the execution: a bash tool call is a real shell command in your infrastructure.

3. Custom tools — you define both

A tool with a name, description, and JSON input_schema. Use these for anything specific to your domain or systems: lookup_customer_record, issue_refund, search_internal_wiki. Add strict: true to guarantee that Claude's tool calls match your schema exactly.

4. Agent Skills — instructions, not code

A Skill is a folder containing a SKILL.md file with YAML frontmatter and a markdown body, optionally alongside reference material and executable scripts. Skills are not tools: they add no entry to the tools array and Claude does not call them with arguments the way it calls a function. A Skill is a procedure Claude reads.

---
name: release-verification
description: Verifies a release candidate before tagging - use when preparing a release
allowed-tools: Bash(pnpm test:*) Bash(git tag *)
---

## Steps
1. Run the full test suite and confirm zero failures.
2. Check the changelog covers every merged PR since the last tag.
3. Verify the version bump matches the change type.

The defining mechanic is progressive disclosure: only the description sits in context so Claude knows the Skill exists, and the body loads only when the Skill is invoked — automatically when the description matches the request, or manually as /release-verification. That is what makes a 400-line procedure affordable when the same content in CLAUDE.md would be paid for on every turn of every session.

Skills live in .claude/skills/<name>/SKILL.md (project, committed) or ~/.claude/skills/<name>/SKILL.md (personal). Useful frontmatter fields: allowed-tools pre-approves tools for that turn, disable-model-invocation: true makes a Skill manual-only, user-invocable: false makes it Claude-only, paths limits when it auto-activates, and context: fork runs it in an isolated subagent.

5. MCP servers — capability as a separate service

An MCP server exposes tools, resources, and prompts over stdio or Streamable HTTP. The point is reuse across clients: one Jira MCP server serves Claude Code, your own Messages API application, and any other MCP client, without any of them importing your code. From the Messages API you can reach a remote MCP server through the MCP connector without building a client yourself.

---

The Decision Table

Two distinctions the exam leans on:

• Skill vs. tool. A tool is a function Claude calls with structured arguments and gets a result from. A Skill is a procedure Claude reads and then follows, using whatever tools it already has. "Check the weather" is a tool. "How this team ships a release" is a Skill.
• Skill vs. CLAUDE.md. Both are instructions. CLAUDE.md is always in context and should hold persistent facts; a Skill is on demand and should hold procedures. The moment a CLAUDE.md section is only relevant sometimes, it belongs in a Skill.

Managing Tool Sprawl

Every tool in tools costs input tokens on every request — name, description, and full JSON schema — plus the automatic tool-use system prompt (354 tokens on Claude Sonnet 5, 286 on Claude Opus 5 with tool_choice auto). Forty tools is not just a token bill; it also degrades selection accuracy, because near-duplicate descriptions make the choice genuinely ambiguous.

Three mitigations:

1. Dynamic registration. Attach only the tools the current user's role and the current task can use. A read-only user never sees issue_refund.
2. The tool search tool. When you genuinely have thousands, let Claude discover and load them on demand instead of declaring them all up front.
3. Cache the tool definitions. tools sits first in the cache prefix (tools → system → messages), so a stable tool array reads back at 0.1x. The corollary is the trap: changing any tool definition invalidates the entire cache, including system and message breakpoints.

Common Traps

1. Reimplementing a server tool. Writing a custom search_web handler when web_search exists.
2. Modelling a procedure as a tool. A "run our release checklist" tool with a free-text argument is a Skill wearing a costume.
3. Putting an occasional procedure in CLAUDE.md. It loads every session, spends tokens every turn, and dilutes adherence to everything else in the file.
4. Building an MCP server for a single application. MCP's value is reuse across clients; for one app a custom tool is less machinery.
5. Declaring every tool the organisation owns. Token cost on every request plus worse tool selection.
6. Forgetting that Anthropic-schema client tools still execute in your infrastructure. bash and text_editor need the same sandboxing as any tool you wrote yourself.