Quick Reference: Domain 8 — Tools and MCPs

8.1 Tool Implementation

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.

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

Trap	Correct 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.

If the question says...	The answer is likely...
"Claude needs to perform an action in an external system"	Expose the capability as an MCP tool
"Claude needs read-only contextual data"	Consider an MCP resource
"the client launches the server locally"	Use a local transport such as stdio
"many clients need the same integration"	Consider a remote MCP server
"tool input can be malformed or unsafe"	Validate the input on the server
"a tool performs a sensitive operation"	Enforce authorization at the application/service boundary

Trap	Correct answer
MCP resources and tools are the same thing.	Tools perform actions; resources provide data or context.
The model should decide whether a sensitive tool call is authorized.	Authorization should be enforced by the application or service.
stdio is required for every MCP deployment.	Transport should match the deployment and connectivity requirements.
A tool description is enough to validate tool input.	The MCP server should validate inputs before execution.
Remote MCP servers do not need authentication because MCP standardizes communication.	Remote deployments still need appropriate authentication and authorization.

Built-in tools provide capabilities already available in the agent environment.
Custom tools expose application-specific executable operations.
Skills provide reusable instructions, knowledge, and workflows.
MCP provides a standardized interface for external capabilities.
Start with the simplest mechanism that satisfies the requirement.
Use MCP when external capabilities need a reusable standardized integration boundary.
Use Skills for reusable procedures rather than arbitrary external execution.

If the question says...	The answer is likely...
"the capability already exists in the agent environment"	Prefer the built-in tool
"the application needs a new executable backend operation"	Consider a custom tool
"the agent needs reusable procedural guidance"	Consider a Skill
"multiple compatible clients need a standardized external integration"	Consider MCP
"a simple mechanism already satisfies the requirement"	Avoid unnecessary additional infrastructure

Trap	Correct answer
Every new capability should be implemented as an MCP server.	Choose the simplest mechanism that satisfies the requirement.
A Skill is equivalent to an executable external-system tool.	Skills primarily provide reusable instructions and workflows; executable access requires an appropriate tool or integration.
Custom tools are always better than built-in tools.	Use an existing built-in capability when it already satisfies the requirement.
MCP is only useful for one specific Claude application.	MCP can provide a standardized integration boundary that is reusable across compatible clients.
Tool, Skill, and MCP are interchangeable terms.	They serve different roles: executable capabilities, reusable guidance, and standardized external integration.