Claude Code MCP 深入解析（1）：從內置工具到可擴展能力

TL;DR: Claude Code ships with a fixed set of built-in tools such as Read, Write, and Bash. MCP—the Model Context Protocol—lets it connect to an external process at runtime and use that process’s declared capabilities as new tools. MCP does not solve “how should I reuse a procedure?” That is the job of a Skill. MCP solves “how can the model perform an action it did not ship with?”

Imagine that, before changing code, you want Claude to check the current state of an issue in your company’s internal Jira instance.

Claude Code does not come with a tool named Jira. It could use Bash to assemble a curl command, add an API token, organization domain, and issue ID, build a JSON request, then sift the useful fields from a large response. That can work. But every time, the agent has to reconstruct where the token lives, what the endpoint looks like, and how to interpret the returned fields.

That is a familiar kind of friction. An earlier Skill-focused discussion described it as repeatedly pasting a release checklist. Here, the repeated context is not a checklist but the mechanics of talking to an external system.

A natural reaction is: why not turn those curl steps into a Skill?

You can—but the Skill would package operational knowledge about how to talk to Jira. The actions available to Claude would still end at Bash. A Skill can organize the use of existing tools; it does not add a new executor. If the Jira integration needs to maintain session state, deal with pagination, or interpret schemas that differ by permission level, repeatedly composing requests and parsing them in Bash is less dependable than calling a purpose-built action that already understands Jira.

What is missing is not another set of instructions. It is a new action: something with a name, parameters, and a result, which the model can invoke directly like Read or Bash. Built-in tools are part of Claude Code itself. You cannot edit the product’s code just to make it recognize Jira.

That is the layer MCP addresses: how can a model gain a new action at runtime without changing Claude Code itself?

A connectable process, not a text file to read

A Skill is a folder containing Markdown and supporting files. Claude reads and expands it. An MCP server is different: it is an independently running process or service.

It might be a local program that can access a filesystem, or a long-running server inside a company network. It declares that it offers particular tools, readable data, and reusable prompt templates. The protocol gives that declaration a common shape regardless of the language used to build the server or the machine on which it runs.

This series will call that process an MCP server.

On the other side, Claude Code acts as an MCP client. It connects to a server, asks what that server can do, and adapts the answer into a form Claude Code can use. From the user’s perspective, the larger application is the host: it can manage several MCP clients and several servers at once.

Those names—host, client, and server—are general Model Context Protocol terminology, not concepts invented solely for Claude Code. The same vocabulary applies when an IDE or another desktop assistant supports MCP. The MCP introduction describes the protocol as an open standard for connecting AI applications with external systems.

An MCP server can declare more than one kind of capability. Three categories matter for this series:

Tools are callable actions that may have side effects, such as creating a Jira issue. They are the real answer to the opening scenario and the main thread of the series.
Resources are readable data exposed by a server, such as a current issue list. They are not the same as the supporting resources inside a Skill folder: these are externally supplied, potentially live data.
Prompts are reusable conversation templates provided by a server. They are useful, though less central here than tools and resources.

Connecting one server does not imply that all three categories exist. A server may expose only tools, only resources, or some combination. The client first needs to learn what the server supports. For a practical overview of the kinds of external systems Claude Code can connect to, see the official Claude Code MCP documentation.

The important point for now is simple: tools, resources, and prompts are three different things.

Once connected, it looks like an ordinary tool

Suppose an MCP server declares a create_issue tool. Claude does not see it as a special “external capability.” Claude Code names and wraps it so it becomes another entry in the normal tool list, alongside Read and Bash.

That uniformity is the design decision that makes MCP useful. The model need not switch into a separate “MCP mode” before deciding whether to call a tool. The source may be external, but the agent-facing shape remains a tool name, description, input schema, and result.

The previous article in this series maps the full route from server configuration to a callable tool. The rest of the series will unpack the main questions along that route:

Where does a server come from? A server can be configured at several scopes. How does Claude Code discover the configuration and resolve conflicts?
How do bytes move? A local child process and a server inside a private network cannot use exactly the same connection path.
How does naming work? Why does a connected tool such as create_issue not collide with a built-in tool, and how does it reach the list the model can see?
Who approves an action? If a server can reach an internal network or create issues, who authorizes it? Can approval apply to the whole server rather than require a separate decision for every tool?
Where is the boundary with Skills? Both extend what Claude can accomplish, but they do so at different layers.

Draw the line with Skills early

The detour through “should this be a Skill?” is not a distraction. It is worth establishing the boundary at the start because every later article relies on it.

	What it solves	Where it ends
Skill	Reusable operating knowledge: what to do first, and what to do after each result	It invokes existing tools
MCP	An action the model did not ship with	It adds a new tool

The two mechanisms are complementary. Once an MCP server adds a useful tool, a Skill can absolutely include that tool in a repeatable workflow. One layer defines how to proceed; the other changes what actions are available at all.

A compact way to remember the distinction is:

Skills answer “how do I do this?” MCP answers “what can I do?”

That framing also clarifies why MCP should not be treated as a bag of prompt snippets or shell recipes. It is a protocol boundary that lets independently built capabilities enter an agent without turning the agent itself into a collection of special cases.

Next: configuration becomes a connection

Before Claude Code can connect to an MCP server, that server must appear in configuration. The same name might be defined in a project, a user-level configuration, or centrally managed settings. What happens when those sources disagree?

The next article follows that path: from the first configuration entry, through scope and precedence, to a completed handshake and a client that knows which capabilities the server supports.