What is MCP, and do you actually need it?

The short answer

MCP, the Model Context Protocol, is the open standard Anthropic published in November 2024 for connecting an AI agent to outside tools and data: your GitHub issues, a live database, a monitoring dashboard, hundreds of other services. It works through one shared format instead of custom code for each one. You need it the moment a task requires reaching something outside your project folder that your coding tool can’t already touch on its own. If you’re still building a single app end to end, reading and writing your own files inside Claude Code or Cursor, you almost certainly don’t need one yet, and installing one won’t make that app better on its own. Most people trying MCP for the first time reach for it too early, expecting a general upgrade, when it’s really a narrow bridge you install for one specific outside system at a time.

Three things MCP actually unlocks

Your GitHub issues become something the agent can act on. Connect the GitHub MCP server and you can ask it to implement the feature described in a specific issue and open a pull request directly, instead of copying the issue text into chat by hand and pasting the diff back out afterward.

Your live database becomes something you can question in plain language. Point an MCP server at Postgres or Supabase, ideally with a read-only account, and ask how many signups you got this week without writing a query yourself. This is one of the exact examples in Anthropic’s own Claude Code documentation: you ask a production database a question and get an answer, instead of a script you still have to run yourself.

You can see production errors without leaving the chat. Connect an error-tracking server like Sentry and ask what broke in the last 24 hours, or which deployment introduced a specific error, and the agent reads the real stack traces instead of you pasting screenshots of a dashboard into the conversation.

This is a different lever than spinning up a subagent. A subagent forks part of your existing agent’s work to run in parallel inside the same tool, on files and context it already has. An MCP server reaches for something entirely outside that, a separate system with its own login and its own data. Each of the three examples above needed the agent to touch a system outside your own files. That’s the whole test for whether you need one.

Where most beginners already are, and why that’s fine

If your coding tool already reads and writes your files and runs commands in a terminal, that’s the tool’s own built-in ability. MCP starts where that ability ends: another company’s server, a separate database, an app you haven’t loaded into the project at all.

If you haven’t deployed past localhost, don’t have a live production database strangers could query, and aren’t tracking errors through a separate service, there’s nothing yet for an MCP server to fetch. Add one when a specific, named task needs it, not because a tutorial implied a serious agentic setup always has a few servers running.

Each server you do add is standing infrastructure. It has to authenticate, it stays connected in the background, and every tool it exposes takes up room in your context window before you’ve asked it a single question. That’s part of why the honest answer for most solo, early-stage projects is not yet.

The confusion here doesn’t stop once you pass “beginner,” either. People well past their first project still describe clicking install on an MCP server and not being sure what actually happened next. It doesn’t mean you’re behind. It means MCP is opt-in infrastructure you reach for on demand, not something owed to your project by a certain week.

You want to…	Do you need MCP?
Build and test one app end to end, on your own files	No
Have the agent read and act on GitHub issues or PRs directly	Yes, a GitHub server
Ask your production database a question in plain language	Yes, a database server
Get pointed at live errors without leaving the chat	Yes, a monitoring server like Sentry
Teach the agent a task you already do by hand, repeatedly	Maybe not MCP, a Claude Skill first

Installing one without it being scary

1. Start from a server tied to a task you already have (GitHub, Notion, Sentry, Stripe), not a random one copied from a forum post you don’t recognize.
2. In Claude Code, one command does it: claude mcp add --transport http <name> <url>. Hosted servers then walk you through an OAuth login inside /mcp, nothing else to configure by hand for most of them.
3. Don’t take the install step’s word for it. Run /mcp afterward and look for “Connected” with a tool count next to the name, not “pending” or “failed.”
4. Keep credentials out of files that get committed. Pass a token as a header or an environment variable, never typed directly into a config file meant to be shared, and know the difference between a key, a secret, and a token before deciding which one is safe to hand over at all.
5. Grant the narrowest access that does the job: a read-only database account for a server that only answers questions, a token scoped to one repository instead of your whole GitHub account.

There’s a concrete reason step five matters beyond caution for its own sake. In May 2025, researchers at Invariant Labs showed how the official GitHub MCP server, one of the most widely used of all, could be turned against its own user. An attacker planted instructions inside a public GitHub issue. When a connected agent read that issue as part of its normal work, it followed the hidden instructions, pulled private repository data into its own context, and leaked it inside a pull request the attacker could then read. That’s what prompt injection looks like in practice: the agent read content it was told to process, and carried out a command hidden inside it. Anthropic’s own documentation carries the same warning directly: verify you trust a server before connecting it, because one that fetches outside content can expose you to exactly this. Keep access narrow on any server that reads content you don’t fully control (comment threads, incoming emails, public issues), and you’ve already avoided most of what actually goes wrong in practice.

What Glim would tell you

Glimfly is building Glim, a firefly that sits next to your coding agent and explains what it’s doing while it works, including the moment it reaches for an MCP tool instead of just editing a file. You’d see which server got called and why, instead of a wall of raw output scrolling past with no read on it. Look up any term above in the dictionary whenever your agent moves faster than the explanation does.