Bash Or MCP

Every new integration doesn't need a server. If your agent can already open a terminal and run a command-line tool, wiring up an MCP server for the same job is extra infrastructure for no extra capability. The question worth asking before you build a server isn't "could MCP do this" — it's "does the agent already have a simpler way in."

The problem: reaching for a server by default

MCP (Model Context Protocol) servers give an agent structured, documented access to a system — useful when that system has no other way in. But it's easy to treat "wire up an MCP server" as the default move for any integration, even when the agent already has a perfectly good path through bash.

Asking an agent to "create a test issue in this URL" doesn't need a server at all if the GitHub CLI is already installed and authenticated on the machine — the agent just runs gh issue create. No setup, no server to maintain, no protocol layer between the agent and the tool it already knows how to use.

The decision rule

It comes down to one question: is this a common tool the agent already knows, or an unfamiliar system it has no way to discover?

• Common, well-known platform → bash. GitHub, Jira, and similar mainstream platforms already have mature command-line tools. Large language models have generally seen enough of these CLIs during training that they already know the commands — gh issue create, git push, standard Jira CLI calls — without any extra scaffolding. If you already use the CLI yourself, your agent can probably drive it too.
• Internal or unfamiliar system → MCP. This is where MCP actually earns its keep: unknown internal services the agent has never seen documentation for. An internal diagnostic system, a proprietary dashboard, a company-specific API with no public docs — none of that is in the model's training data, and there's no CLI for the agent to fall back on. An MCP server is what makes it discoverable and usable at all.

Example

gh issue create — the agent runs the existing, authenticated GitHub CLI. No setup. Compare that to an internal API with no public documentation: an MCP server describes what operations exist and how to call them, something the agent has no other way to learn.

How to run it

Before reaching for a server, ask two questions in order:

1. Is this a common platform (GitHub, Jira, or similar) that already has a CLI? If yes, let the agent use bash. It likely already knows the commands, and you save yourself a server to build and maintain.
2. Is this internal, proprietary, or otherwise undocumented anywhere the model could have learned it? If yes, that's a real case for MCP — the server is what turns an opaque internal system into something the agent can actually operate.

The underlying factor is how simple the operation is. Simple, well-known operations on well-known platforms don't need a protocol layer in between. Complex or unfamiliar systems benefit from one because there's no other way for the agent to learn the shape of the API.

Power tricks

• Don't treat MCP as inherently more advanced. It's a tool for a specific gap — discoverability of unfamiliar systems — not a universal upgrade over bash.
• Check what CLI you already use yourself first. If you drive GitHub, Jira, or another platform from your own terminal, that's a strong signal your agent can too, without any new infrastructure.
• Reserve server-building effort for the tools nobody's documented. That's where an MCP server converts an agent from useless to genuinely useful on that system.