You don't always need MCP (here's what I use instead)

A lot of people believe this: to connect Claude to Gmail, Notion, or your own server, you need MCP. You don’t. That’s the most common misconception going around right now. I let Claude run the infrastructure for this whole channel — and for most of it, I don’t use MCP at all. Today: how I connect without it, and one test for whether you even need it. First, where the myth comes from. Without MCP, Claude can only handle text. That’s true — of Claude chat. But Claude Code is different. Out of the box, it can run Bash. Read and write files. Execute code. So the hands you need to connect things? They exist before you add any MCP at all. What MCP adds is a pre-defined toolbox. Convenient — but not the only road, and not required. Let me prove it. Two things I connect, with zero MCP. Number one: call the API directly. The DNS for this channel’s domain lives on Cloudflare. I want Claude to manage it. Find a Cloudflare MCP server, stand it up, connect it? I didn’t. There’s just one small script called cf dot py. Inside, it’s plain curl, hitting the Cloudflare API. Claude’s Skill says: you can check and edit DNS with cf dot py. That’s it. No server. The scope is already locked at the API token — DNS edits only, no Workers. Write it once, and it runs the same way every time. A textbook case where MCP is unnecessary. Number two: wrap a CLI you already have. Google Drive and Sheets. Claude touches those too. Again, no server. There’s a CLI called gws, and Google already holds the auth. All I did was write the forbidden moves and required steps into a Skill. Never permanently delete — trash only. Never overwrite — append only. Always read before you write. This is actually the home-grown advantage. The guardrails live inside my own markdown. I can read all of it, audit it, change it. And research backs this up: a large share of public MCP servers ship with security holes. Someone else’s server — you can’t see all of it. By now you might be thinking, so MCP is useless. It isn’t. Let me be fair — there are places MCP clearly wins. One. You don’t have to figure out what’s possible and build it. No reading API specs, no writing scripts. The moment you connect, a whole toolbox is just there. Two. With an official MCP, it’s harder to misuse. It’s built carefully, and it leans safe. Three. When you’re using a service broadly — poking at lots of its features, still exploring. That’s when a ready-made toolbox beats writing a script every time. The real value of MCP isn’t interactive or not. It’s the breadth of features you’ll use. So here’s the rule I promised. Decide by the breadth of features you’ll use. Narrow, fixed, just repeating? Write one script or use a CLI. Once it’s built, it’s no different from MCP — lighter, even. Broad, and you’re not sure yet what you’ll use? A ready-made MCP is easier. It skips all the figuring-out and building. It’s not repeating, so MCP. A fixed job runs forever on a single script. The call is simple. One fixed faucet — build it yourself. A whole toolbox — reach for MCP. MCP is a useful tool. But it’s not a default, and it’s not required. Before you connect, ask once: do I need a toolbox, or just one faucet? If the answer is one faucet — you can already connect. Today. Without MCP.