Claude Certified Engineers logoClaude Certified Engineers

CCDV-F · Study Guide

← Domain 8: Tools and MCPs

8.1 · 3.5% of the exam · Topic 1 of 3

Tool Implementation

Design and implement Claude tools for reliable external-system interaction, including clear tool descriptions, constrained inputs, error handling, dispatch patterns, approval flows, and practical tool-set construction.

Learning objectives

  • Understand how Claude uses tools and function calling.
  • Write clear and precise tool descriptions and input schemas.
  • Constrain tool inputs and validate requests before execution.
  • Handle tool errors and unsuccessful execution safely.
  • Distinguish client-side and server-side tool execution.
  • Understand approval patterns for sensitive tool actions.
  • Construct focused tool sets that support reliable agentic behavior.

Detailed theory

Tool use and function calling

Tools give Claude a structured way to interact with external systems and perform actions that are not available through text generation alone.

A tool definition describes what the tool does and what inputs it accepts. Claude can then decide when a tool is useful and provide structured arguments for execution.

  • Define a clear tool name and purpose.
  • Use an explicit input schema.
  • Validate tool arguments before execution.
  • Return useful execution results or structured errors.
  • Keep tool behavior predictable and bounded.

Tool description and schema design

Tool descriptions are part of the interface Claude uses when deciding which capability to invoke. Ambiguous descriptions can lead to incorrect tool selection or incorrect arguments.

Input schemas should express required fields, expected types, and meaningful constraints wherever possible.

  • Describe the tool's actual responsibility.
  • Use specific parameter names.
  • Mark required inputs clearly.
  • Use enums or constraints when the valid values are known.
  • Avoid overlapping tools with indistinguishable purposes.

Validation and error handling

Tool arguments should be validated before an external operation is performed. Validation protects downstream systems from malformed or unexpected requests.

Tool failures should be represented clearly so the agent can understand that an operation failed rather than treating an error as successful output.

  • Validate required fields.
  • Validate values against allowed ranges or formats.
  • Handle authentication and permission failures explicitly.
  • Return actionable error information.
  • Do not silently convert failed operations into successful results.

Agentic harness dispatch

An agentic harness can dispatch tool calls, execute the selected capability, collect the result, and provide the result back to Claude.

The harness can also enforce application-level policies such as authorization, rate limits, logging, validation, and approval requirements.

  • Receive the model's tool request.
  • Validate the requested operation.
  • Apply authorization and policy checks.
  • Execute the tool.
  • Return the result or structured failure.

Client-side and server-side tools

Tool execution can occur on the client side or on a server depending on where the required capability, credentials, data, and security controls belong.

Client-side tools can access capabilities available in the user's environment, while server-side tools can centralize credentials, business logic, and access control.

  • Use client-side execution when the capability belongs to the user's environment.
  • Use server-side execution when credentials or protected resources should remain on the server.
  • Keep sensitive credentials outside model-visible tool arguments.
  • Place authorization at the appropriate execution boundary.

Approval patterns

Some tools perform actions with meaningful external consequences, such as sending messages, modifying records, or deleting resources.

An approval step can require a human or application policy to confirm the action before execution.

  • Identify high-impact operations.
  • Require confirmation where appropriate.
  • Show the action and relevant parameters before approval.
  • Do not treat model intent as automatic authorization.

Tool-set construction

A tool set should provide the capabilities needed by the workflow without unnecessarily increasing ambiguity or exposing unrelated operations.

Too many overlapping tools can make tool selection harder, while overly broad tools can make execution less predictable.

  • Keep tools focused on distinct responsibilities.
  • Avoid unnecessary duplication.
  • Prefer explicit operations over ambiguous catch-all tools.
  • Expose only the capabilities required for the workflow.

Core concepts

Tool definition

What
A structured description of a capability Claude can invoke.
Why
It gives Claude a predictable interface for external actions.
When
Claude needs to interact with an external system or capability.
When not
When no external action or structured capability is required.

Input schema

What
A structured specification of the arguments a tool accepts.
Why
It constrains and clarifies tool inputs.
When
Defining or validating tool calls.
When not
Never rely only on free-form text when structured inputs are required.

Tool dispatch

What
The process that receives a tool request and routes it to the appropriate implementation.
Why
It connects Claude's requested action to actual execution.
When
Building an agentic harness or tool runtime.
When not
When the application has no executable tools.

Approval pattern

What
A control that requires confirmation before a consequential tool action executes.
Why
It reduces the risk of unintended external actions.
When
Tools can modify data, communicate externally, or create significant consequences.
When not
For genuinely read-only and low-risk operations where approval adds unnecessary friction.

Practical examples

Customer lookup tool

A support assistant exposes a get_customer tool with a customer_id input.

The schema requires customer_id and the application validates that the requester is authorized to access that customer's information before querying the backend.

Send-message tool

An assistant can prepare an outbound message through a send_message tool.

Because the action has an external side effect, the application can require approval before actually sending the message.

Server-side database tool

Claude requests a tool that reads protected business data.

The server executes the database operation so database credentials remain outside the client and model-visible arguments.

Claude-specific considerations

  • Tool descriptions and schemas are part of the interface Claude uses for tool selection.
  • Use precise names and descriptions to distinguish tools with different responsibilities.
  • Validate tool arguments before executing external operations.
  • Use application-level authorization for sensitive actions.
  • Keep secrets and protected credentials outside tool arguments.
  • Use approval flows for consequential external actions when required.
  • Avoid unnecessarily large or overlapping tool sets.

Architecture decisions

SituationChooseBecause
Two tools have similar capabilities but different purposes.Give each tool a precise description and distinct responsibility.Clear boundaries help Claude select the appropriate capability.
A tool receives a value outside its allowed range.Reject or safely handle the invalid input before execution.Validation prevents malformed requests from reaching downstream systems.
A tool modifies an external record.Apply authorization and an approval pattern when appropriate.Model intent alone should not authorize consequential actions.
A tool requires protected backend credentials.Execute the capability server-side.Sensitive credentials should remain within the protected execution boundary.

Tradeoffs

Tool design balances flexibility, discoverability, security, and execution reliability. More capability is not automatically better if it creates ambiguity or increases the impact of mistakes.

AxisLess constrainedMore constrained
Tool scopeBroad multi-purpose tools.Focused tools with distinct responsibilities.
InputLoose free-form arguments.Explicit validated schemas.
ExecutionDirect execution.Validation, authorization, and approval where needed.
CredentialsExpose credentials near the client/model.Keep protected credentials server-side.

Quick reference

  • Tools provide structured capabilities for external interaction.
  • Tool descriptions should clearly explain purpose and behavior.
  • Input schemas define the arguments a tool accepts.
  • Validate tool arguments before execution.
  • Tool dispatch connects model requests to implementations.
  • Client-side and server-side execution have different security and capability boundaries.
  • Use approval patterns for consequential actions when appropriate.
  • Keep tool sets focused and avoid unnecessary overlap.

Decision rules for the exam

If the question says…The answer is likely…
"Claude has several similar tools to choose from"Use precise descriptions and distinct tool responsibilities
"the requested tool argument is invalid"Validate and reject or safely handle it before execution
"the tool performs a consequential external action"Apply authorization and approval when appropriate
"the tool needs protected backend credentials"Keep execution and credentials on the protected server side
"the workflow has many overlapping tools"Reduce overlap and expose focused capabilities

Common exam traps

TrapCorrect answer
A detailed prompt is enough to validate tool arguments.Validate tool arguments at the execution boundary.
Claude deciding to call a tool automatically authorizes the action.Authorization belongs to the application or execution boundary.
More tools always give an agent more useful capability.Focused, non-overlapping tool sets can improve reliable selection.
Backend credentials should be passed as normal model-visible arguments.Keep protected credentials inside the appropriate execution boundary.

Open the Domain 8 sheet

Exam tips

  • When a question asks how to improve tool selection, look for clear descriptions, schemas, and distinct responsibilities.
  • When a question involves malformed input, validate it before external execution.
  • For consequential actions, distinguish tool invocation from authorization and approval.
  • For protected credentials, identify the correct server-side execution boundary.
  • Do not assume a larger tool set is automatically better.

Common mistakes

  • Writing vague tool descriptions.

    Clearly state what the tool does, what it accepts, and when it should be used.

  • Trusting tool arguments without validation.

    Validate inputs before passing them to downstream systems.

  • Treating model tool selection as authorization.

    Enforce authorization outside the model at the application boundary.

  • Exposing protected credentials through tool arguments.

    Keep sensitive credentials inside the protected execution environment.

  • Creating many overlapping tools.

    Keep the tool set focused and distinguish responsibilities clearly.

Practice questions

Original questions for this topic. They are study items, not questions from the live exam.

What most directly helps Claude distinguish between two tools with similar capabilities?

Choose one answer

A tool receives an argument that violates its allowed constraints. What should happen before the external operation executes?

Choose one answer

Why might an application use an approval step before executing a tool?

Choose one answer

Scenario questions

A tool can delete customer records

A Claude application exposes a delete_customer tool. Claude can select the tool, but deleting a record has a significant external consequence.

What is the most appropriate execution pattern?

Choose one answer

A tool set has overlapping capabilities

An agent has several tools that all retrieve customer information but differ only slightly in naming and behavior.

What change is most likely to improve reliable tool selection?

Choose one answer

Build exercise

Design a safe tool interface

Intermediate · 35 minutes

What you will learn

  • Write a precise tool description.
  • Define a constrained input schema.
  • Add execution validation.
  • Identify authorization and approval requirements.
  • Choose an appropriate execution boundary.

  1. Step 1

    Define the tool responsibility

    Choose one external operation and write a short description explaining exactly what the tool does.

    Why: A focused responsibility makes tool selection more predictable.

    You should see: A tool description that clearly distinguishes the capability from other tools.

  2. Step 2

    Define the inputs

    List every argument required by the operation and specify its type and constraints.

    Why: Explicit schemas reduce malformed and ambiguous requests.

    You should see: A small structured input schema with required fields.

  3. Step 3

    Add validation

    Define the checks that happen before the external operation executes.

    Why: The execution boundary must not blindly trust model-provided arguments.

    You should see: Validation rules for every important input.

  4. Step 4

    Identify side effects

    Determine whether the operation reads information or changes an external system.

    Why: Side effects can require stronger authorization or approval controls.

    You should see: A clear distinction between read-only and consequential operations.

Review checklist

Checks are saved in this browser.

Key takeaways

  • Clear tool descriptions improve reliable tool selection.
  • Schemas make tool inputs explicit and constrain execution.
  • Validate and authorize before sensitive external operations.
  • Use approval patterns for consequential actions when appropriate.
  • Keep protected credentials inside the appropriate execution boundary.
  • Prefer focused, non-overlapping tool sets.

Sources

Domain 8 overview · Quick reference

View progress