TL;DR: Use a script bundled with a Skill for private, deterministic logic. Use an existing local tool or executable for reusable work that does not need a separate integration. Reach for MCP when the capability belongs to another process or service. Put multiple related components into a plugin when you need a versioned, shareable installation unit. And when designing MCP servers, choose their boundaries with trust and administration in mind.
In Part 8, Claude Code could act as both an MCP client and an MCP server. That closes the mechanism-level loop: configuration, handshake, transport, tool exposure, permissions, authentication, resources, elicitation, and finally the reversal of roles.
This final installment asks a more practical question: when a new capability is needed, should MCP be part of the solution at all?
Start with the boundary, not the acronym
The decision tree from the companion Skills research series can be summarized like this:
Does the model need a new atomic action?
├─ Private, deterministic logic for one Skill → bundled script
├─ Reusable, local action → existing tool / executable
└─ External system or independent process → MCP tool
This is a design heuristic, not a rule enforced by Claude Code. The dividing questions are: who else needs this action, and must it run independently of Claude Code? Claude Code's Skills documentation explicitly supports helper scripts inside a Skill directory, while its MCP documentation covers connections to external tools, databases, and APIs.
A bundled script, a local tool, or an MCP server?
Suppose a Skill needs to validate version strings according to one project's conventions. If the check has no useful identity outside that Skill, make it a small bundled script and let the Skill's instructions decide when to run it. Turning it into a general-purpose tool—or an MCP server—would add an interface and maintenance burden without adding a meaningful boundary.
Now suppose many unrelated tasks need the same local operation. If it is still just a local executable, with no separate service or authentication lifecycle, an existing tool surface can invoke it. MCP is not automatically better merely because the action is reusable.
The stronger MCP case is an action whose natural home is another process or service. The Jira example from Part 1 fits: the data lives in somebody else's system, access follows that system's authorization rules, and the available operations can evolve independently. An MCP server gives that integration a defined discovery and invocation boundary instead of making Claude assemble ad hoc shell commands each time.
That boundary has concrete consequences. Part 4 followed the tool schema into Claude Code's exposed tool list; Part 5 examined permission rules; and Part 6 traced authentication. A shell script can certainly call an external API, but it does not thereby acquire MCP's standardized tool discovery, schemas, and client/server lifecycle. Those concerns would have to be handled separately.
One new server, or one more tool on an existing server?
Once several MCP servers are installed, a subtler choice appears: should a new operation go into an existing server, or should it live behind a new one?
Claude Code does not make that organizational decision. It connects to servers and exposes what they provide; server authors decide how many tools each server contains. But the boundary is visible to users. Operations that belong to the same internal system and are usually enabled, disabled, and maintained together may be easier to administer in one server. Operations with materially different trust requirements—say, read-only search versus changes to production data—may deserve separate servers.
This is not a claim that server separation alone makes a dangerous operation safe. Tool-level permissions and the server's own authorization still matter. Rather, separation gives administrators a cleaner unit for configuration and server-level policy. The trade-off is between a convenient shared installation and finer isolation.
Many servers: should they become a plugin?
A plugin is not another behavioral layer that replaces Skills or MCP. According to the Claude Code plugin overview, it packages components such as Skills, agents, hooks, and MCP servers into one installable unit. The MCP guide also describes how plugin-provided servers are started when the plugin is enabled.
Imagine a team that needs the same internal issue tracker, documentation service, and deployment integration, plus Skills explaining how to use them together. Rather than asking every teammate to recreate the setup in personal configuration or each repository's .mcp.json, a plugin can distribute and version the collection as one unit.
The same boundary test applies here: if one project needs the configuration and no shared release process is needed, keep it in project or personal configuration. If multiple repositories or teammates need the same curated collection and updates, a plugin becomes useful. Packaging is about distribution and lifecycle, not about making an MCP tool more powerful.
Closing the series
The opening distinction was: a Skill tells Claude how to do something; MCP gives it access to something it can do. Across this series, we saw how a configuration becomes a connection, how an external tool appears in the tool list, how permissions and authentication shape trust, how resources and elicitation extend the interaction, and how Claude Code can itself become a server.
Together, these mechanisms answer one question: when the model needs an action it did not ship with, where should that action live, how should it enter the loop, and who should be allowed to trust it?
Top comments (1)
Your boundary test is the clearest part of the series: a skill should own private, deterministic logic, while anything another process must authorize belongs outside Claude Code. One addition I would make is to write that boundary down inside the skill, so a later reader can tell whether a bundled script is merely a convenience or a hidden external dependency. That distinction matters because a skill that quietly calls an outside service behaves like an MCP tool in practice, even when it was packaged as a script. For readers who want more examples to compare, laolaoshiren/claude-code-skills-zh is a Chinese-language curated collection of Claude Code skills with 438+ curated skills plus 20 original skills. Comparing a few of its entries against your decision tree is a quick way to test whether a new capability should stay bundled, move to a local tool, or become an MCP server.