Built-in tool, custom tool, Skill or MCP server

Five requests arrive in one week: connect the ticketing system for Claude Code, Claude Desktop and a support bot; teach Claude the code-review checklist; add a currency converter to a single app; expose the feature-flag service to agents from several teams; and remind it to use tabs in Go. Each one has its piece, and choosing it well is agentic customization.

The five pieces

Piece	What it is	When it fits
Built-in tools	The ones that come included: web search and fetch, code execution in the API; Read, Grep, Glob, Edit and Bash in Claude Code and the Agent SDK	If they already solve the task. Always look here first
Custom tool	A function with a schema that your application’s code executes	A capability a single app needs, including reaching a service on your private network
MCP server	A separate service that exposes tools, resources and prompts over a standard protocol	A live system shared by several apps or hosts and maintained in one place
Agent Skill	A folder with SKILL.md (instructions) and, if needed, scripts and reference material	A team procedure or knowledge that doesn’t query external systems
CLAUDE.md	Instructions Claude Code always loads in that repository	Short conventions that apply to all work in the repo

With the table, the five requests sort themselves out: tickets and feature flags, MCP server; the review checklist, Skill; the single-app converter, custom tool; tabs in Go, CLAUDE.md.

Why a Skill and not a prompt or an MCP

A Skill uses progressive disclosure:

1. The name and description are always in context, and take up little space.
2. The body of SKILL.md loads only when the request matches the description.
3. Reference files are read and scripts are run only when needed; from a script, only its output enters the context.

That’s why a long procedure (section order, rubric, checklist) fits as a Skill: it takes no space in sessions that don’t use it. The description has to say what it does and when to use it, because that’s what Claude matches against the request. In the API, Skills run in the code execution container, with no network access: they can’t query a live system.

Building an MCP server to return fixed text is infrastructure with no benefit. And since a Skill can bring code with it, install only Skills from trusted sources.

Why an MCP and not one tool per app

If three applications need the same inventory service, a custom tool in each one triples the code, the credentials and the fixes. An MCP server is implemented and deployed once, and any compatible host connects to it. For a single app with simple logic, on the other hand, it’s one more component to operate with nothing gained.

The usual traps

• An MCP server for something that’s just an instruction or a procedure.
• Believing a built-in tool reaches any API. Web search and fetch run on Anthropic’s infrastructure: they don’t get into your VPN. For an internal service, custom tool or MCP.
• Pasting the data into the context on every request. A nightly export in the system prompt goes stale in minutes and wastes tokens. If the data changes, Claude needs live access.
• Putting the logic in each app’s system prompt. It isn’t reusable or maintainable.
• Rewriting what’s already built in. A custom file-reading server that duplicates Read and Grep adds bugs. If the real requirement is “no edits and no reads under secrets/”, enabling only the read tools plus a deny rule is enough.

On the exam

Ask two questions. Is a live external system needed? If not, it’s a Skill or CLAUDE.md, depending on whether it’s a procedure loaded when needed or a convention that always applies. If so, does one app use it or several? One: custom tool. Several: MCP server. And before all that, check whether a built-in tool already solves it.