When NOT to Reach for an MCP
The most useful skill in any powerful toolset is restraint — knowing when a simple script beats a server, and when MCP overhead costs more than it earns.
Introduction
You have spent seven lessons learning what MCP is, how to connect servers, the three primitives, the safety model, real-world server categories, how to build a server, and how to run it across multiple clients.
Now for the discipline lesson: when to not use any of that.
Core Concept
What MCP Actually Costs
MCP is not free. Before reaching for it, account for the real costs:
Design time. You have to decide what the server exposes, what tools or resources to create, what arguments they take, and how errors are handled.
Build and test time. Even a simple server requires writing code, testing it, and debugging edge cases.
Configuration overhead. You need to add the server to client configs, manage API keys, and handle the case where the server is not running when the client expects it.
Security surface. Every server you add is another potential attack surface, another place to manage credentials, another thing that can be misconfigured to expose more than intended.
Maintenance burden. Servers break when underlying APIs change, when dependencies update, or when the system they connect to changes its behavior. You will be the one fixing it.
This cost is worth paying when the server provides repeated, high-value access to a capability the AI cannot otherwise reach. It is not worth paying for one-off tasks, built-in capabilities, or cases where a simpler approach exists.
The MCP Decision Filter
Run any candidate capability through this four-question filter before building or connecting a server:
1. Does the AI already have this capability?
Many AI clients have built-in abilities: reading files provided in context, basic math, code generation, text summarization. If the AI can already do the thing without a tool call, MCP adds latency and complexity without adding capability.
Example: "Summarize this document for me" — paste the document in context. You do not need a summarize tool for this.
2. Is this a one-time or rare task?
If you will perform this task once this year, write a script and run it directly. The overhead of designing a server, configuring it, and maintaining it vastly exceeds the cost of a focused 15-minute scripting session.
Example: Converting a folder of CSV files to JSON as a data migration. Write the script, run it, delete it.
3. Will this be reused repeatedly across sessions or shared across clients?
This is the primary justification for MCP overhead. If you will call this capability in dozens of sessions across multiple clients over many months, the up-front cost amortizes quickly. If you will use it twice, it probably does not.
Example: A memory server that stores and retrieves project context — you query it in every session. MCP is the right answer.
4. Is there a simpler built-in alternative in your shell or existing tooling?
Before building an MCP server to run a shell command, ask: can Claude Code's built-in Bash tool handle this? Before building a file reader server, ask: can you provide the file as context? Before building a web scraper server, ask: does the site have an API you can call directly?
The answer is often yes. Check before building.
Practical Application
Scenarios: Server vs No Server
| Scenario | Use MCP? | Why |
|---|---|---|
| Daily semantic search across your knowledge base | Yes | High frequency, persistent state, AI cannot do this without external storage |
| One-time data format conversion | No | Write a script; overhead not justified |
| Posting daily notifications to Discord | Yes | Repeated action, closes the human-visibility loop, justifies the bridge |
| Counting words in a document | No | Paste the document in context; AI handles this natively |
| Reading from a live API with auth the AI cannot access | Yes | Genuine capability gap; server securely manages credentials |
| Running a bash command you know | No | Use Claude Code's built-in Bash tool |
| Persistent cross-session project memory | Yes | Exactly what MCP memory servers are for |
| Fetching a single URL to summarize | Maybe | If frequent across sessions, use a fetch server. If one-time, paste the URL in context and let the AI browse it. |
When a Simple Script Wins
Here is the most common over-engineering trap: someone learns MCP, gets excited, and builds a server for something they need once. Two hours later, they have a running server, a config entry, and a script they will never touch again.
The cleaner version:
# Just run the thing directly
python convert_csvs.py ./data/raw ./data/processed
# Or in Claude Code with the built-in Bash tool
# (no server needed — just ask Claude to run the command)
Save MCP for capabilities that need to outlive a session or be shared across clients.
Security Surface Warning
Every server you add expands your security perimeter. A server with access to your filesystem, your database, or your messaging platform is a potential pivot point if:
- Its dependencies have vulnerabilities
- Its API keys are stored insecurely
- Its access is scoped too broadly
More servers = more surface. Keep the server count proportional to genuine need. A setup with 3-5 well-scoped servers is more secure and easier to maintain than one with 20 servers half of which you no longer actively use.
Audit your mcpServers config periodically. Remove servers you have not used in 30 days. Scope filesystem servers to the narrowest directory that works.
Common Mistakes
Building a server because you could, not because you need to. The fact that MCP lets you wrap anything in a tool does not mean you should. is just complexity.
Wrapping a CLI tool in MCP when Claude Code's Bash tool already covers it. git, docker, curl, jq — Claude Code can already call these. You do not need MCP servers for common CLI tools.
Keeping servers connected that you no longer use. Inactive servers still get spawned at client startup, adding latency and security surface for zero benefit. Remove them from your config.
Using MCP to paper over a missing skill. If you need to learn how to write a specific script, writing an MCP server that calls the AI to do it for you is not learning — it is avoidance wrapped in architecture. Some things are worth doing directly.
Summary
- MCP has real costs: design time, build time, configuration, security surface, and ongoing maintenance
- Run any candidate capability through four questions: built-in? one-time? reused repeatedly? simpler alternative available?
- One-time tasks belong in scripts; repeated cross-session capabilities belong in servers
- Security perimeter grows with every server you add — audit and remove unused servers periodically
- The discipline of knowing when not to reach for MCP is what separates a thoughtful practitioner from someone who over-engineers everything
Congratulations
You have completed the MCP for Beginners track. You know what MCP is, what servers expose, how to connect them, the safety line between read and write tools, the three most valuable server categories, how to build a minimal server, how to use one server across multiple clients, and — critically — when to step back and reach for something simpler instead.
The most effective practitioners are the ones who use powerful tools surgically. You now have the foundation to do that with MCP.