Built-In Tools vs. Custom Tools vs. Skills vs. MCP Servers
CoreChoose the right agentic customization mechanism · Difficulty 2/5
Explanation
Four Ways to Extend Claude
| Mechanism | What it is | Best when |
|---|---|---|
| Built-in tools | Anthropic-provided tools (e.g., web search, code execution, computer use) | The capability already exists as a built-in; least effort |
| Custom tools | Your own function-calling tools defined per app | App-specific actions/logic that live with one application |
| Skills | Packaged instructions + optional scripts/resources (SKILL.md) Claude loads when relevant | Reusable know-how/procedures that extend behavior without a running service |
| MCP servers | Standardized servers exposing tools/resources/prompts | A capability reused across many apps and maintained independently |
Selection Heuristics
- Does a built-in already do it? Use it -- don't rebuild what Anthropic already provides.
- App-specific, lives with one app? Use a custom tool.
- Reusable procedure/knowledge, no separate service needed? Use a Skill.
- Shared capability across several apps, independently maintained, possibly remote? Use an MCP Server.
The recurring exam theme across this whole domain is *which extension mechanism fits the requirement* -- the deciding factors are reusability, maintainability, and where the code/logic actually runs (inside one app, packaged as instructions, or as an independent service).
The Built-In-Tools Ceiling
Built-in tools have fixed, Anthropic-defined capabilities. They do not automatically reach an arbitrary internal API just because they exist -- for an internal service, the choice is a custom tool (app-specific) or an MCP Server (shared/reusable), never a built-in.
Common exam traps
- "A built-in tool can reach any internal REST API." False -- built-ins have fixed capabilities; internal systems need a custom tool or an MCP Server.
- Confusing a Skill with a deployed service -- a Skill is packaged instructions/procedures Claude loads when relevant, not a running MCP Server or microservice.
- Choosing a custom tool for a capability that's explicitly described as needing to be reused across multiple apps and maintained independently -- that combination of requirements points to an MCP Server, not an app-local custom tool.
- Reaching for an MCP Server when the actual need is just reusable knowledge/procedure with no running service required -- that's the Skill sweet spot, and standing up a server for it is over-engineering.
Key Takeaways
- Built-in tools: least effort, use them when the capability already exists (web search, code execution, computer use)
- Custom tools: app-specific logic that lives with a single application
- Skills: packaged instructions/procedures (SKILL.md) for reusable know-how without a running service
- MCP servers: the mechanism when a capability must be reused across many apps and maintained independently
- Built-in tools cannot reach arbitrary internal APIs -- that requires a custom tool or an MCP server
Glossary Terms
The design flaw of giving an agent more, or more powerful, tools than its role genuinely requires. Capability bloat harms security (a hijacked agent can invoke a capability it never needed), reliability (tool-selection accuracy drops as the tool set grows and descriptions overlap), and cost (every tool definition consumes context tokens on every request). The fix is least privilege by removal -- eliminating the capability entirely -- not adding logging or confirmation prompts around it.
Reusable markdown instruction files with YAML frontmatter that define custom slash commands in Claude Code. Invoked with /skill-name. Frontmatter configures: description (for trigger matching), allowed-tools (tool restrictions), and context (fork for isolation). Stored in .claude/skills/.
A process that implements the MCP protocol and exposes tools, resources, and prompts to MCP clients. Built with official SDKs (Python, TypeScript). Deployed locally via stdio or remotely via StreamableHTTP. Claude Code auto-discovers servers configured in .mcp.json.
The practice of writing tool definitions (name, description, input schema) that enable Claude to reliably select and use tools correctly. Key principles: precise descriptions that distinguish similar tools, explicit input format requirements, clear boundary examples, and documented error return formats.
Related Concepts
Writing Good Tool Definitions: Descriptions, Schemas, and Errors
Tool description quality -- what it does, when to use it, what each parameter means -- is the top driver of correct tool selection
MCP Primitives: Tools, Resources, and Prompts
MCP is an open standard ('USB-C for AI') that lets a capability be built once and reused across any MCP-compatible client