The Model Context Protocol is everywhere right now. Every agent tutorial opens with "first, set up your MCP servers." And yet the agent stack running on the machine I'm typing this from — search monitoring, Telegram alerting, social posting, a voice assistant — contains exactly zero MCP servers. Everything talks to external services through direct API calls.
That's not a rejection of MCP. It's a protocol, not a movement — and the flood of agent-architecture content keeps turning plumbing decisions into identity decisions. You're not an "MCP shop" or "behind." You're making a per-workload integration choice, and it comes down to two gates: one decides whether MCP is even the relevant category, the other decides whether it's worth the overhead.
Gate one — relevance: does a model pick the tool at runtime?
MCP exists to solve a specific problem: a language model, mid-session, deciding which tool to use. The protocol standardises how a model discovers tools, what their schemas look like, and how results come back. That's its entire reason to exist — it's a model-facing protocol. If no model is ever choosing, MCP isn't the relevant category; you'd share a library or stand up a plain service.
Now look at what most automation actually is. My morning report pipeline:
- Cron fires at 8:30
- Script calls the Google Search Console API
- Script formats the numbers
- Script posts to Telegram
The model isn't deciding anything here. There's no runtime tool choice — the model's only job in pipelines like this is reading the data at one step, not fetching it. The call order is fixed, every day, forever. For this workload, MCP isn't the question.
One subtlety that matters later: gate one is evaluated over a tool surface's consumers, not over the workload in front of you. The cron pipeline will never pass it. But the search-data access underneath it might — the day a model-driven client wants the same data. The pipeline isn't an MCP candidate; the surface can become one.
Either way: being an agent isn't the criterion. Plenty of agentic systems are deterministic pipelines with a model doing interpretation in the middle.
Gate two — worth: who else benefits from the standard?
Here's the case that taught me gate one isn't enough. My voice assistant does pass it: the model maps what I say to one of the scripts on this machine at runtime. That's genuine tool selection — exactly MCP's territory.
And MCP still isn't worth it there. The model selects from eight known scripts, on one machine, in one client, all written by me. A dictionary mapping intent to script path does the job in twenty lines. MCP would buy me a standardised interface to a thing that has exactly one consumer and one author.
So gate two has two doors, and passing through either one justifies the overhead:
- A second consumer. If a coding agent, a desktop assistant, and a chat interface all need access to your database, writing it once as an MCP server beats three custom integrations. The standardisation is the product.
- Tools you didn't write. Third-party MCP servers — browsers, databases, SaaS platforms — hand you capabilities without authoring the API client yourself. To be precise about what you're buying: ownership flips the authoring cost, not the operating cost. You still run the connection, the auth, the version pinning, and the server's failure surface — more on that below. Even so, with a single consumer, not writing and maintaining the client code is often the better end of the trade.
- The degenerate case of both: genuinely open-ended sessions. Interactive agent work where you can't predict which of forty mostly-third-party tools the next request needs. At that scale, schema discovery and uniform invocation stop being ceremony and become the only sane option.
The compressed rule: the model choosing makes MCP relevant; a second consumer — or someone else's tools — makes it worth it.
What my stack actually looks like
| Workload | Gate 1: model picks? | Gate 2: consumers / ownership | Integration |
|---|---|---|---|
| Morning search reports | No — fixed pipeline | — | Direct API via cron script |
| Error monitoring → Telegram | No — fixed pipeline | — | Direct API via cron script |
| Posting to X when something ships | No — one script, one endpoint | — | Direct API (CLI tool) |
| Voice assistant running local scripts | Yes — speech maps to a script | One client, eight scripts, all mine | Custom tool map, ~20 lines |
| Interactive debugging sessions | Yes — agent decides what to query | Many tools, mostly third-party | This is where MCP earns it |
The cost nobody mentions
On managed platforms MCP servers feel free — though "free" there means a different bill: latency, opacity, and coupling to someone else's uptime. On bare metal the cost is undisguised. Every MCP server is another process: it starts at boot or it doesn't, it logs somewhere or it doesn't, it holds credentials, it has versions, it can hang. My monitoring stack exists because I learned that anything running unattended fails silently sooner or later. Each integration I add is a thing my future self debugs at 8am when the morning report doesn't arrive.
A direct API call inside a cron script has one failure surface: the script. An MCP integration has three: the client, the server, and the transport between them. That's the operating cost that third-party servers don't remove — they save you writing the client, then hand you a process to keep alive. Sometimes that trade is worth it. For a fixed daily pipeline, it isn't.
Where I'd reach for it — and where my rule bends
If I wire a second client to this machine's data — say a desktop assistant that needs the same search-data access my scripts have — that's the trigger. Two consumers, one tool surface: write the MCP server, point both clients at it, delete the duplicate glue. The moment standardisation has more than one beneficiary, the overhead flips into leverage.
One honest caveat about scope. "Wait for the second consumer, then migrate" is rational for me because I'm a solo operator on a machine I fully control — I'll be the one who notices the trigger, and I know every line of the glue I'd be replacing. On a team, the second consumer often shows up unannounced, after the original author has left, and the deferred-migration cost lands on someone who has to reverse-engineer the glue first. In that setting, pre-paying the abstraction can be the right call before gate two formally opens. The gates don't change; who's standing at them does.
Until my second consumer shows up, the boring answer stands: cron, a script, an HTTP call, and a log file. The model choosing makes MCP relevant. Someone else benefiting from the standard makes it worth it. Everything else is tutorials.
Top comments (0)