# Built-In Tools vs Custom Tools vs Skills vs MCP > Built-in tools, custom tools, Agent Skills, and MCP servers are complementary layers, not a power ranking — one agent often uses several at once. Match each capability to complexity, reusability, governance, and latency — not to raw capability. The exam trap is defaulting to MCP because it sounds the most powerful. **Domain:** D2 · Tool Design + Integration (18% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/agentic-tool-surface-selection **Last reviewed:** 2026-05-04 ## Quick stats - **Mechanisms:** 4 - **Exam domain:** D2 - **Also tested in:** CCD-F D8 - **Selection axes:** 4 - **Cheapest option:** Built-in ## What it is Architects extending what Claude can do choose among four distinct mechanisms, each with a different trade-off of setup cost, reusability, and scope. Built-in tools are platform-provided (Read, Write, Edit, Bash, Grep, Glob, web search) — zero setup, zero maintenance. Custom tools are hand-written functions or API calls you define, typically served through an in-process MCP server in the Agent SDK. Agent Skills package instructions plus optional scripts and resources that Claude loads automatically when relevant. MCP servers expose external systems as tools over a standard protocol, callable locally or remotely. Anthropic explicitly positions these as complementary layers in the same stack rather than competing options. The architect's job is fit-for-purpose selection: the same agent often uses built-in tools for file work, a custom tool for one private API, a Skill for a repeatable procedure, and MCP for org-wide integrations — all at once. ## How it works Built-in first. Reach for platform tools for straightforward, native, well-defined tasks — they are the fastest path with no external setup and no maintenance overhead. A file-editing agent that reinvents Read/Write/Edit is over-building. Applying built-ins effectively. Within the built-in set, match the tool to the operation: Read for a known file path, Grep to search file *contents* by pattern, Glob to find files by *path* pattern, Bash for shell commands and anything without a first-class tool, and Edit for a targeted in-place change versus Write for a full-file replace. The exam rewards NOT dropping to Bash (e.g. grep/cat/ls) when a dedicated tool exists — first-class tools are more reliable, cheaper to reason about, and easier to permission. Custom tools for private, one-off access. When you need a proprietary API or internal service no built-in covers, define a custom tool via the Agent SDK's in-process MCP server so Claude can call your functions directly. Running in-process avoids the IPC/round-trip of an external server, so latency is typically lower for a single private call. Skills for reusable, multi-step procedures. A Skill is the right unit when a capability is a stateful, orchestrated workflow you want Claude to invoke automatically and reuse across sessions — not a single function call. A Skill can itself call custom tools or MCP servers for its steps, so it composes with the other layers rather than replacing them. Constraint: API Agent Skills run via code execution, which is excluded from Zero Data Retention — a ZDR-required flow can't rely on them (this is about API Agent Skills; Claude Code skill files are a separate surface with their own ZDR rules). MCP when you connect external systems. Prefer an MCP server when the job is integrating outside services and you want one shared, governable integration point across a team rather than a bespoke per-app function. Note the setup asymmetry: consuming a pre-built MCP server is a one-line .mcp.json entry; authoring your own is the higher-effort path. MCP is a protocol — the centralized auth, audit, and versioning are governance *you build on it*, not automatic. Anthropic teaches this as a live refactoring skill. A Code w/ Claude 2026 session frames it as "tool, skill, or subagent?" — decomposing an agent whose logic has outgrown its prompt, categorizing each capability, and running evals after each change to confirm the split didn't regress behavior. The decision is iterative, not a one-time pick. ## Where you'll see it in production ### Coding agent Built-in Read/Write/Edit/Grep for file work; a custom tool for one internal deploy API; no MCP needed. ### Enterprise assistant MCP servers front Jira + Slack + the warehouse so one auth + audit layer governs every external call. ## Comparison | Mechanism | Best for | Setup / maintenance | Reusability | Governance / retention | | --- | --- | --- | --- | --- | | Built-in tool | Native file / shell / search ops | None | Platform-provided | Platform-managed | | Custom tool | One private function or API | Low (in-process MCP) | Per-app | You own the code | | Agent Skill | Reusable multi-step procedure | Medium | Across sessions / teams | You own it; API skills excluded from ZDR | | MCP server | Connecting external systems | Consume: low (.mcp.json) · author: high | Per-server, sharable | Whatever auth / audit you build on it | ## Decision tree 1. **Does a built-in already do it?** - **Yes:** Use the built-in (pick the right one — Read/Grep/Glob/Bash/Edit/Write) — done. - **No:** Keep going — the layers below can combine. 2. **Do you need a private function or API no built-in reaches?** - **Yes:** Add a custom tool (in-process = typically lowest latency). - **No:** Skip to the procedure + connectivity questions. 3. **Is it a reusable, multi-step procedure?** - **Yes:** Package it as an Agent Skill — which can still CALL custom tools or MCP for its steps (mind ZDR for API skills). - **No:** A single tool is enough. 4. **Are you connecting external systems or want one shared, governed integration point?** - **Yes:** Use an MCP server (consume = a .mcp.json line; author = more work). Skill + MCP together is common — procedure plus connectivity. - **No:** Built-in or custom tool covers it. ## Exam-pattern questions ### Q1. A file-editing coding agent needs to read, search, and modify files in a repo. What should it use? Built-in tools (Read/Write/Edit/Grep/Glob/Bash). The tempting distractor is "an MCP filesystem server for consistency" — but built-ins already cover native file work at zero setup. MCP here adds overhead with no benefit. ### Q2. You need Claude to look up a customer by ID against one internal database, used only by this app. Which mechanism? A custom tool served through the Agent SDK's in-process MCP server. The distractor is "a Skill" — but this is a single function call, not a reusable multi-step procedure, so a Skill over-packages it. ### Q3. A recurring 'generate a compliant invoice PDF' procedure bundles a template, formatting rules, and a script. Best fit? An Agent Skill — it packages instructions + resources Claude loads automatically and reuses across sessions. The distractor "a custom tool" misses that this is a stateful, multi-step procedure, not one function. ### Q4. You must connect Claude to Jira, Slack, and a data warehouse across the whole org, and you want one shared, auditable integration point. Which mechanism? MCP servers — the fit for integrating multiple external systems behind one governable surface. The distractor "one big custom tool per system" duplicates integration work and skips the shared auth/audit layer. (MCP does not *auto*-provide governance — you build the auth/audit on it — but it is the layer designed for it.) ### Q5. A regulated deployment requires Zero Data Retention. Your team wants to ship a reusable multi-step procedure as an API Agent Skill. What's the catch? API Agent Skills run via code execution, which is excluded from ZDR — so a ZDR-required flow can't rely on them. The exam rewards knowing this scoped constraint (it's about API Agent Skills, not Claude Code skill files); the fix is a custom-tool/MCP path, not a Skill. ### Q6. A recurring workflow must 'triage new Jira tickets and post a summary to Slack' — a repeatable procedure that also needs live Jira + Slack access. One mechanism, or more? Compose them: an Agent Skill for the repeatable procedure, calling MCP servers (or custom tools) for the Jira/Slack connectivity. The trap answer is "a Skill" OR "MCP" alone — treating them as either/or. They are complementary layers: procedure + connectivity. ## FAQ ### Q1. Is MCP always better than a custom tool? No. An in-process custom tool typically has lower latency for a single private call; MCP earns its keep when you're connecting external systems or want a shared, governed integration point across a team. ### Q2. Do Skills break Zero Data Retention? API Agent Skills execute via code execution, which ZDR excludes — so a ZDR-required flow can't rely on them. This is scoped to API Agent Skills; Claude Code skill files are a separate surface with their own ZDR rules. --- **Source:** https://claudearchitectcertification.com/concepts/agentic-tool-surface-selection **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.