Claude Code MCP Deep Dive (9): Where MCP Ends and Skills, Tools, and Plugins Begin

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?

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 Enter fullscreen mode Exit fullscreen mode 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.

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.

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.

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.

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?