CCDV-F 8.3 — Agentic customization

Choosing a mechanism

What does the agent actually need?

A common capability
Built-in toolsearch, fetch, code execution
Act on your system
Custom toolyou write and run the handler
Know your procedure
Skillinstructions, scripts, references
Shared integration
MCP serverone server, many applications

Work down the branches in order. The first question is nearly always decisive, and the cheapest option that satisfies the constraint is the right one.

Built-in tools: use what exists

The documentation groups the supplied tools two ways, and the split is about execution. Server tools run on Anthropic's infrastructure and return their results directly: web search, web fetch, code execution, the advisor tool, the tool search tool, and the MCP connector itself. Anthropic-schema client tools have a schema Anthropic defines but run in your application — the memory, bash, text editor, computer use and browser use tools. 8.1 covers that distinction in full.

The tradeoff is simple enough to state in a sentence: you get a maintained, well-described capability for nearly no engineering, and you give up control over how it works. Some carry usage pricing beyond tokens — web search is charged per search, code execution by compute time. And a server tool cannot reach anything only your network can see, which rules it out for most internal integrations. The mistake to avoid is writing your own web-scraping tool because it feels more serious; the corresponding mistake is assuming code execution can query your warehouse.

Custom tools: the agent acts on your systems

A custom tool is a function you define and your harness executes. It is the right answer whenever the agent must do something in a system you own, inside your network, under your credentials, with your audit trail. Everything in 8.1 is the how; what belongs here is the cost side of the decision.

Custom tools are the most controllable option and the least portable. Every definition sits in the request prefix and costs input tokens on every call, whether or not it is used — plus a few hundred tokens of system overhead simply for having a tools parameter at all. They live inside one application: a second application wanting the same capability either imports your code or reimplements it. And the model sees them all the time, so a large set of narrow tools creates exactly the ambiguity that makes an agent pick the wrong one. Where a tool set has grown very large, the tool search tool exists to discover and load tools on demand rather than presenting them all up front.

Skills: procedural knowledge, loaded on demand

An Agent Skill is a folder of instructions, scripts and resources that an agent can discover and load when it becomes relevant. At its centre is a SKILL.md file: YAML frontmatter carrying at minimum a name and a description, then markdown instructions. Supporting files sit alongside — a reference document, examples, a scripts/ directory — and the skill points to them so the agent knows when to open them.

The idea that makes skills different is progressive disclosure. Only the metadata is loaded at startup, so the agent knows the skill exists and roughly when it applies. The body of SKILL.md loads when the skill looks relevant. Further files load only when the instructions send the agent to them. A hundred skills therefore cost roughly a hundred short descriptions of context, not a hundred documents — which is why skills scale where stuffing procedures into the system prompt does not. The guidance is to keep SKILL.md short, under about 500 lines, and push detail into supporting files.

Progressive disclosure

loaded only as far down as needed

Level 1 · metadataname and description at startup
Level 2 · SKILL.mdloaded when the skill looks relevant
Level 3 · referencesreference.md, examples — on demand
Level 3 · scriptsexecuted, never read into context

Compare this with a tool definition, which is in the prefix on every single request. A skill's cost when it is not being used is one line.

In Claude Code a skill lives in .claude/skills/<name>/SKILL.md for a project, ~/.claude/skills/ for a user, or inside a plugin, and can be invoked by name as a slash command or auto-invoked when its description matches the request. The frontmatter gives useful control: disable-model-invocation makes a skill user-only, which the best-practice guidance recommends for anything with side effects such as deploying or committing; allowed-tools pre-approves the tools a routine workflow needs; and context: fork runs the skill in a subagent with its own window, which is 6.1's isolation pattern packaged. Skills follow an open standard and are portable across platforms, so the same folder can be used by more than one agent product.

The limits matter as much as the strengths. A skill is instructions, not access: it cannot reach a system the agent has no tool for. It is advisory rather than enforced — the agent reads it and generally follows it, which is fine for a procedure and wrong for a control, and anything that must not happen belongs in permissions or a hook (7.3). And it is only as good as its description, because that one line is what the agent uses to decide whether to open it at all.

Worked example · A consultancy standardises its financial models

An analytics consultancy has a house method for building a three-statement financial model: a naming convention, a sanity-check list, a template workbook and a Python script that validates the output. Analysts using Claude each get slightly different results, and the partners want consistency without hiring someone to police it.

Diagnose what is missing. Claude can already read spreadsheets and write Python. Nothing here needs access it lacks — it needs to know the firm's method. That points at a skill rather than a tool.
Write the skill. SKILL.md holds the method in about 150 lines, with reference.md for the naming convention and checks.md for the sanity list, and the validation script in scripts/.
Point at the files. The instructions say when to open each supporting file, so they load only when relevant instead of on every session.
Describe it well. The description names the trigger — building or reviewing a three-statement model — because that line decides whether Claude ever opens the skill.
Commit it to the repository. Under .claude/skills/, so every analyst gets it with a git pull and improvements arrive by pull request.
Keep the guardrail separate. Sending a model to a client requires a partner's approval, which is not in the skill: it is a permission rule, because a skill is advice and this is a control.

Takeaway: No code was written, nothing was deployed, and the firm's method became something every session can follow. That is the shape of a problem a skill solves.

MCP servers: one integration, many consumers

An MCP server is the same capability as a custom tool, published behind a standard protocol so that any host can use it. 8.2 covers authoring; the tradeoff for this task statement is about ownership and reach. The case for a server is plural consumers: three applications, or Claude Code plus a product plus a colleague's script, or a capability another team maintains that you would rather not rebuild. The case against is that for a single application it is strictly more machinery — a process to deploy, a transport, authentication, versioning and an on-call rotation — for a capability a function call would have provided.

Same capability, two packagings

Custom tool

A function inside one application
No deployment, no transport, no auth layer
Reuse means copying code
You control dispatch, errors and approvals directly

MCP server

A service any MCP host can connect to
Needs hosting, auth, versioning, monitoring
Reuse is configuration, not code
Also offers resources and prompts, not just tools

Nothing about what the agent can do differs. What differs is who else can use it and who is on the hook when it breaks.

Two constraints decide many exam items. Reaching a server from the Messages API means the MCP connector, which takes remote HTTPS servers only and exposes tools only — so a design resting on MCP prompts or resources does not survive that route. And installing a third-party server is a supply-chain decision: the specification says tool descriptions and annotations should be treated as untrusted unless the server itself is trusted, and those descriptions land in your model's context.

	Built-in	Custom tool	Skill	MCP server
Gives the agent	A ready capability	An action in your system	Knowledge and procedure	A shared capability
Who runs it	Anthropic, or you	Your harness	The agent, as instructions	The server's host
Context cost	Its definition	Definition on every request	One line until used	Its tools' definitions
Engineering	Almost none	Moderate	Writing, not coding	A deployed service
Reuse elsewhere	Everywhere	Copy the code	Portable folder	Configuration
Enforces anything	No	Yes, in the handler	No — advisory	Yes, in the server

They compose more often than they compete

The four are layers, not rivals, and good designs use several. A skill can tell the agent how to use a set of MCP tools correctly — the procedure and the access, each in the mechanism that fits it. A custom tool can wrap a built-in one to add your own limits and logging. An MCP server's tools arrive in Claude Code namespaced as mcp__<server>__<tool>, which means they are addressed by permission rules exactly like built-in tools, so an approval pattern covers all of them uniformly. And plugins are the packaging layer: a plugin bundles skills, and its skills are invoked with a plugin prefix, which is how a team distributes a working set rather than a pile of files.

Worked example · An IT department gets four requests in one week

A platform team supporting Claude-based tooling receives four requests. They deliberately solve each with the smallest mechanism that works, and write down why.

“It should check vendor websites for security advisories.” Public web content, no private access, nothing bespoke. The built-in web search and fetch tools, enabled. No code.
“It should open tickets in our internal service desk.” An action, on a system inside the network, needing service-desk credentials — and only this one application needs it. A custom tool in the harness, with an approval gate on ticket creation.
“Everyone writes incident reports differently.” Not access, but method. A skill holding the house format, the severity definitions and an example report, committed to the repository so it improves by pull request.
“Three teams all want to query the warehouse.” Plural consumers, one system, and the data team is willing to own it. An MCP server over Streamable HTTP with per-team scopes — configuration for each consumer rather than three integrations.
What they refused. A proposal to turn the service-desk tool into an MCP server “for consistency” was declined: one consumer, no second host, and it would have added a deployment to maintain.
What they combined. The incident-report skill tells the agent to use the service-desk tool to fetch the timeline, so the procedure and the access stay in the mechanism that fits each.

Takeaway: Four requests, four different answers, one rule: the cheapest mechanism that satisfies the constraint in the sentence. The constraint is usually who else needs it, or what the agent cannot currently reach.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Building an MCP server for a capability one application needs	Write a custom tool; promote it to a server when a second consumer actually appears.
Writing a custom tool for something a built-in tool already does	Use web search, web fetch or code execution unless you need control they do not offer.
Encoding a procedure as a dozen narrow tools	Put the procedure in a skill and give the agent the few tools it needs to carry it out.
Relying on a skill to prevent something	Skills are advisory; a control belongs in permission rules, a hook, or in the tool handler itself.
Assuming every MCP feature is available from the Messages API	The connector reaches remote servers and exposes tools only — prompts and resources need a different host.

You should now be able to

Distinguish built-in tools, custom tools, Skills and MCP servers by what each actually provides.
Choose a mechanism from the constraints in a requirement rather than from preference.
Explain progressive disclosure and why a skill's idle context cost is a single line.
State the context, engineering and portability cost of each option.
Combine mechanisms — a skill directing MCP tools, permission rules covering both.
Recognise when a capability should be promoted from a custom tool to an MCP server.

Agentic customization