CCA Domain 2 Study Guide: Tool Design and Model Context Protocol (MCP)

Purpose and accuracy note

This guide covers the architectural decisions that make Claude’s external actions understandable, safe, and reliable. Anthropic’s public certification announcement does not publish domain percentages, so exact weight claims from unofficial study material have been removed. Use the current candidate guide or partner portal for authoritative weighting.

1. Tool use: the end-to-end contract

A tool definition tells Claude what capability exists. A typical definition includes:

• •name: short, distinct, and action-oriented;
• •description: what the tool does, when to use it, when not to use it, and important behavior;
• •input_schema: JSON Schema for parameters;
• •input_examples: optional examples for difficult inputs.

Claude selects a tool based largely on the user request and tool definition. For a client tool, Claude returns a tool_use block, your application validates and executes it, and your application sends a corresponding tool_result. Claude then uses that result to continue. Anthropic-managed server tools may execute within Anthropic’s infrastructure, but the client/server responsibility must still be understood for the tool type in use.

Tool use is not execution permission. The model proposes arguments; the application remains responsible for authentication, authorization, validation, confirmation, execution, auditing, and error handling.

2. Design tools Claude can choose correctly

Names should distinguish capabilities: get_customer is better than data, and cancel_subscription is clearly different from get_subscription_status. Descriptions should state boundaries and side effects.

Weak description:

“Manages accounts.”

Stronger description:

“Disables login for an existing user after administrator confirmation. This is a destructive, reversible action. Do not use to delete records or reset passwords.”

Schemas should encode real constraints:

• •required fields only when always necessary;
• •enums for known states;
• •formats and patterns when useful;
• •descriptions for ambiguous business fields;
• •identifiers instead of unrestricted queries where possible;
• •separate confirmation fields or workflow steps for high-impact actions.

Avoid overlapping tools with indistinguishable descriptions. If several tools share most behavior, consider one well-scoped tool with an enum. If operations have different permissions or risk, keep them separate so authorization is explicit.

Only expose tools relevant to the current task. A smaller, clearer tool set improves selection and reduces attack surface. Deferred loading or tool discovery can help when an environment has many capabilities.

3. Tool choice and control

The API can allow automatic selection, require some tool, or force a specific tool. Choose the least coercive setting that meets the workflow contract:

• •auto: Claude may answer directly or call a tool.
• •any: Claude must select one of the supplied tools.
• •forced tool: Claude must call a named tool.

Do not force a write tool merely because the user mentioned an entity. First gather missing parameters and confirmation. Forcing can be appropriate in a tightly controlled extraction or routing stage where a tool-shaped response is the contract.

Parallel calls are suitable for independent, read-only operations. Sequential calls are required when a later action depends on an earlier result. Side-effecting operations demand careful ordering, idempotency, and confirmation.

4. Results, errors, and side effects

Return concise, structured tool results. Include stable identifiers, status, and the facts Claude needs next. Do not flood the context with full logs or large raw payloads when a filtered summary and retrieval handle will do.

Use is_error for tool failures and provide actionable information without leaking secrets. Distinguish:

• •validation failure: fix arguments; usually do not retry unchanged;
• •authorization failure: stop or request proper access;
• •not found: clarify identity or report absence;
• •transient network/service failure: retry with bounded exponential backoff and jitter;
• •rate limit: honor Retry-After;
• •partial success: return what changed and what did not.

Design mutating tools for idempotency. Use an idempotency key, deduplication token, or read-before-write guard so retries do not create duplicate payments, tickets, or messages. For destructive or externally visible actions, surface a preview and obtain confirmation unless existing policy clearly authorizes execution.

Long-running work should return a job ID and status rather than keeping a synchronous call open indefinitely. Provide a separate status tool or callback path.

5. Security boundaries

Treat model-generated arguments as untrusted input. Enforce authorization in the tool implementation using the authenticated user or service identity. Never let the prompt choose an arbitrary user identity that bypasses access control.

Validate and parameterize database queries. Use allowlists for commands, paths, hosts, and operations. Canonicalize paths before checking containment. Do not concatenate tool arguments into shell commands or SQL. Apply output filtering so tool results do not expose secrets, credentials, hidden prompts, or another tenant’s data.

Prompt injection inside retrieved content is still untrusted data. The tool or host should constrain actions; a sentence in a webpage or document must not expand permissions.

6. Programmatic tool calling

Programmatic tool calling allows Claude to orchestrate tool calls through code, filter results, and reduce model round trips. It is valuable for large data exploration or repeated independent queries because raw intermediate results can be processed before they enter the model context.

Tools used this way should return documented machine-readable structures and only necessary fields. Programmatic execution does not remove security requirements: sandbox code, constrain available tools, limit resources, validate outputs, and preserve audit trails.

7. MCP architecture

MCP is an open protocol connecting AI applications to external systems. An MCP server can expose:

• •tools: actions the model can invoke;
• •resources: addressable data or context;
• •prompts: reusable prompt templates.

The host application manages the user experience and one or more MCP clients. Each client connects to a server. Servers implement capabilities and access underlying systems. The server does not “contain Claude”; it exposes capabilities that the host can make available to Claude.

Choose an existing maintained MCP server when it provides the needed features, trust, deployment model, and authorization controls. Build a custom server when business semantics, internal systems, tenancy, or compliance requirements are unique.

Local process transports are convenient for developer tools and local data. Remote HTTP-based connections suit centralized services but require secure transport, authentication, authorization, tenancy isolation, rate limiting, and operational monitoring. Follow the current MCP specification rather than memorizing one historical transport label.

Use resources when data should be discoverable/readable without being modeled as an action. Use tools for computation or side effects. Use prompts for reusable interaction templates. Do not expose a mutating action as a passive resource.

8. MCP operations and governance

For production MCP servers:

• •version schemas and capabilities;
• •expose health and meaningful diagnostics;
• •log identity, operation, result, and latency without sensitive payloads;
• •set timeouts and concurrency limits;
• •rate-limit by tenant and operation;
• •use least-privilege service credentials;
• •document ownership and deprecation;
• •test compatibility with intended hosts and clients.

An MCP integration should have an explicit trust decision. Installing a server can grant access to local files, networks, or accounts. Review its code or publisher, requested permissions, update process, and data flow.

9. High-frequency scenario traps

• •Vague descriptions such as “handles data.” Claude cannot reliably select the right capability.
• •Authorization in the prompt. Access control belongs in trusted application/tool code.
• •A single mega-tool with arbitrary operation and payload. Prefer bounded, typed capabilities.
• •Dozens of unrelated tools on every turn. Limit or discover tools by relevance.
• •Retrying every error. Validation and authorization errors need correction, not blind retry.
• •Retrying a payment without idempotency. Duplicate side effects are possible.
• •Returning complete raw logs. Filter and structure results.
• •Treating tool inputs as trusted because Claude produced them. Validate everything.
• •Saying MCP servers communicate directly with Claude. The host/client mediates the connection.
• •Using a tool for static reference data when an MCP resource is more natural.
• •Forcing a destructive tool before confirmation or required fields exist.
• •Executing partial streamed arguments before complete validation.

10. Rapid decision framework

• •Is the capability information retrieval, computation, or a side effect?
• •Who executes it: application, Anthropic service, or MCP server?
• •What identity and authorization apply?
• •Is confirmation required?
• •Is the action idempotent and retry-safe?
• •What result shape lets Claude continue with minimal context?
• •Should this be a tool, resource, or prompt?

11. Seven-day revision plan

• •Day 1: Write five tool definitions with clear names, boundaries, and schemas.
• •Day 2: Practice auto, any, and forced tool-choice scenarios.
• •Day 3: Implement result/error taxonomies and retry decisions.
• •Day 4: Threat-model SQL injection, command injection, path traversal, and cross-tenant access.
• •Day 5: Diagram MCP host, client, server, tools, resources, and prompts from memory.
• •Day 6: Compare existing versus custom MCP servers and local versus remote deployment.
• •Day 7: Solve 20 scenarios emphasizing security, side effects, and failure recovery.

Final checklist

• •I can define a clear tool name, description, schema, and example.
• •I can explain the tool_use/tool_result lifecycle and is_error.
• •I choose auto, any, or forced selection intentionally.
• •I validate identity, authorization, inputs, outputs, and side effects.
• •I design idempotent mutations and bounded retry behavior.
• •I understand MCP hosts, clients, servers, tools, resources, and prompts.
• •I can choose an existing or custom MCP server and justify the transport/security model.

Official sources

• •Claude certification announcement: https://www.anthropic.com/news/claude-partner-network
• •Tool use overview: https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview
• •Define tools: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/implement-tool-use
• •Handle tool calls: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• •Programmatic tool calling: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/programmatic-tool-calling
• •Fine-grained tool streaming: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/fine-grained-tool-streaming
• •Model Context Protocol: https://docs.anthropic.com/en/docs/agents-and-tools/mcp
• •MCP connector: https://docs.anthropic.com/en/docs/agents-and-tools/mcp-connector