For a long time my Claude Code sessions were a lot of copy-paste. It’d ask what a database table looked like, and I’d paste the schema. It’d want to know what an issue said, and I’d paste the ticket. It could read my code perfectly but it was blind to everything around the code.

MCP fixed that. It’s the thing that lets Claude Code reach out to your actual database, your issue tracker, your logs, instead of you being the middleman pasting context in. Once I set up a couple of servers, whole categories of copy-paste just disappeared.

Here’s what MCP is in plain terms, the servers I actually run, and the honest take on where it’s worth it.

What MCP actually is

MCP stands for Model Context Protocol. Strip the acronym and it’s this: a standard way to give Claude access to tools and data that live outside your files.

An MCP server is a little program that exposes some capability. Query this database. Fetch this issue. Search these docs. Claude Code connects to it and can now use that capability directly, on its own, without you feeding it the data by hand.

The mental shift is the important bit. Without MCP, Claude works with what you paste in. With MCP, Claude goes and gets what it needs. You stop being the API between the model and your systems.

Adding a server

You register a server with the claude mcp add command. Here’s a real one, the Postgres server pointed at a local database:

claude mcp add postgres \
  --command "npx" \
  --args "-y" "@modelcontextprotocol/server-postgres" \
    "postgresql://localhost/myapp_dev"

After that, in a session I can ask “what columns does the orders table have” or “write a query for the top 10 customers by revenue” and it just knows the schema, because it queried it. No pasting.

You can see what’s connected with claude mcp list, and configs can live at the user level or per-project. I keep project-specific servers scoped to the project so I’m not connecting to a client’s database from some unrelated repo.

The servers I actually use

I tried a pile of them. Most I set up once and never touched again. These are the ones that earned a permanent spot.

Postgres (read-only). This is the one I’d install first. Being able to ask about the real schema and get real query results while writing code is the biggest single win. Point it at your dev database, not prod, and use a read-only user. More on that below.

A docs server, via Context7 or similar. Pulls current library documentation into the session. Cuts down on Claude confidently using an API that changed two versions ago. When I’m working with a library I don’t know well, this is the difference between right answers and plausible wrong ones.

GitHub. Reading issues and PRs without leaving the terminal. “Summarize the discussion on issue 412 and tell me what the actual decision was” is a genuinely useful thing to be able to ask. I keep this read-only too. I don’t want an AI opening or closing my issues.

A filesystem server for a second directory. Sometimes I want Claude to reference a sibling repo without opening it as the working project. A scoped filesystem server lets it read those files without me switching context.

That’s it. Four. I stopped chasing new ones once these covered the copy-paste I was actually doing.

Read-only, seriously

Here’s the part I want to be blunt about, because it’s a real risk and not a hypothetical.

An MCP server can be as powerful as you let it. A Postgres server connected with a write-capable user means Claude can, in principle, run an UPDATE or a DELETE. It’s usually careful. “Usually” is not a word I want anywhere near my database.

So: connect with a read-only role. Point at dev or a staging copy, never production. For anything that can change state, I either don’t grant it or I keep a human approval in the loop for every call. The convenience is not worth waking up to a mutated table.

-- the kind of role I actually connect with
CREATE ROLE claude_ro WITH LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE myapp_dev TO claude_ro;
GRANT USAGE ON SCHEMA public TO claude_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_ro;

Read-only by default. Grant more only when you’ve thought about what could go wrong.

Where it’s not worth it

I’m not going to pretend every MCP server is a win, because plenty weren’t for me.

If a task is a one-off, MCP is overkill. Setting up and trusting a server to save one paste is worse than just pasting. The value shows up when you’d otherwise be fetching the same kind of context over and over.

Some servers add latency and noise. Every tool Claude has is a tool it might reach for at the wrong moment, and a session with ten servers connected can get slower and less focused. I’d rather run three servers I use constantly than fifteen I use twice.

And a flaky server is worse than no server. If a connection hangs or errors mid-session, it derails the whole thing. I only keep servers that are reliable. The moment one gets flaky, I pull it.

How I decide to add one

Same test as everything else in my setup: am I doing this by hand, repeatedly? If I’ve pasted a schema three times this week, that’s a Postgres server. If I keep looking up the same library’s docs, that’s a docs server. If it’s a one-time thing, I just paste it and move on.

MCP is at its best when it removes a chore you didn’t notice was a chore. It’s at its worst when you install servers because they exist. Start from the copy-paste you’re tired of, not from the list of available servers.

Claude Code reading your files is table stakes. MCP is what lets it read the rest of your world, the database and the tickets and the docs, without you shuttling context back and forth. Add the two or three servers that kill your most common copy-paste, keep them read-only, and resist the urge to connect everything. The goal isn’t the most tools. It’s Claude having exactly the context it needs and none of the risk you didn’t sign up for.