Domain 8 – Tools and MCPs (10.6%)

• Tool Implementation (4.4%)
• MCP Server Development (2.1%)
• Agentic Customisation (4.1%)

CCDV-F Domain 8 · Task 8.1

What You Need to Know

A tool is an action Claude can ask for. A tool you define has three parts: name, description, input_schema. When the model decides whether to call a tool, it reads only those three surfaces. If it chose badly, the information it needed was missing from one of them.

What a Description Has to Say

Anthropic ranks the description above the schema and the model. Checklist:

• what the tool does
• when it should be used, and when it should not
• what each parameter means and how it affects behaviour
• important caveats, including what information the tool does not return

Floor: at least three to four sentences. Disambiguation is a sentence in both directions — each description names the sibling tool and states the boundary.

The Schema Is the Other Half of the Contract

Closed sets → enum. Mandatory fields → required. Units and formats → per-property description. input_examples attaches validated example inputs. strict: true guarantees schema-conformant inputs.

What the Tool Returns When It Fails

Interface design, not exception handling. Pattern: tool_result with is_error: true and a body written for a reader who must decide what to do next — what went wrong and what to try next. Empty lists and last-known-good values produce fabrication. Server tools: API handles their errors; you do not set is_error.

Where the Code Runs

Type	Who executes	Reach
Client tool	Your process	Your network, your credentials
Server tool	Anthropic	Platform environment only

Anthropic-provided ≠ Anthropic-executed. Some Anthropic-schema tools are client tools.

Dispatch and Approval

Harness resolves name → handler, validates, applies policy, executes under timeout, logs, formats result. Independent read-only calls can run in parallel; side-effecting calls one at a time. Approval classification is a design decision made when the tool set is designed.

CCDV-F Domain 8 · Task 8.2

What You Need to Know

MCP is a standard protocol for connecting an application to an outside system. An MCP server wraps the system and offers capabilities. Tools a server offers are ordinary tools — everything in 8.1 applies.

Host, Client, Server

• MCP Host — the AI application that coordinates one or multiple MCP clients
• MCP Client — maintains a connection to an MCP server and obtains context for the host
• MCP Server — provides context to MCP clients

The host creates one client per server. Local and remote describe where a server runs, not what it is.

Three Primitives, Three Controllers

Primitive	Who decides	What it is
Tools	Model	Functions the LLM actively calls
Resources	Application	Passive read-only data sources (URI or template)
Prompts	User	Pre-built instruction templates; explicit invocation (slash commands)

The usual mistake is to make all three into tools. Passive reference data → resource. Standard document template a person pulls in → prompt.

Transport Follows Topology

• Stdio — local processes on the same machine; optimal performance; typically single client. Server must not write non-MCP messages to stdout (log to stderr).
• Streamable HTTP — remote communication; supports standard HTTP auth; typically multi-user.

Selection rule: who needs to reach this server, and from where? A remote server is a service — version, owner, availability, authentication, access control.

Reaching a Server from a Claude Application

MCP connector on the Messages API: connect to remote MCP servers without a separate client. Limitations: (1) only tool calls supported; (2) server must be publicly exposed through HTTP. Local stdio servers and prompts/resources need a client-side connection via SDK helpers.

CCDV-F Domain 8 · Task 8.3

What You Need to Know

Four mechanisms: built-in tools, custom tools, Skills, MCP servers. This sub-skill is choosing between them.

Built-In Tools

No code, no handler, no deployment. Server-executed ones leave no execution to manage. When a built-in fits, it is the cheapest correct answer. Cost is reach: a server-executed tool runs in the platform’s environment — nothing connects it to a database on your private subnet.

Built-in ≠ Anthropic-executed. Client tools have an Anthropic-defined schema but your application handles execution.

Skill or Tool: Ask What Is Missing

Missing	Mechanism
Information it cannot reach, or an action it cannot perform	Tool
Knowledge — does the task inconsistently, wrong format, wrong conventions	Skill

Instructions are not access. On the Claude API, Skills run in a sandboxed container with no network access. A Skill that documents a private system still does not perform the lookup.

Progressive Disclosure

Level	When loaded	Token cost
Metadata (name + description)	Always	~100 tokens per Skill
Instructions (SKILL.md body)	When triggered	Under 5k
Resources (bundled files/scripts)	As needed	None until accessed

Description is the trigger — must say both what the Skill does and when to use it.

Custom Tool or MCP Server: Reuse and Ownership

Three facts decide:

1. How many applications/surfaces need this capability?
2. Should it be maintained independently of any one application’s release cycle?
3. Who owns the underlying system, and should they own the integration?

One application, one team → custom tool. Several surfaces, or system-owning team should own the integration → MCP server.

The Four Postures That Recur (Wrong)

1. Pasting data into context on every request (stale snapshot; wastes context)
2. Hard-coding the procedure into every system prompt (copies drift)
3. Assuming a built-in tool can reach an internal service (platform environment)
4. Reaching for fine-tuning (wrong class of problem for knowledge packaging or tooling)

Running the Decision

1. Does the platform already provide this? → built-in
2. Does the model need to DO something, or KNOW how? → tool vs Skill
3. How many consumers? Independent ownership? → custom tool vs MCP
4. Mix of requirements → assign each the right mechanism; uniformity is almost always wrong