A Model Context Protocol (MCP) server is a permission grant that installs like a package. One claude mcp add line connects Claude Code to a Postgres database, a GitHub account, a headless browser, or a vendor’s API docs, across three transports. Every install page is one line long, and none of them says what the server reaches once it’s connected.
Every page currently ranking for MCP risk comes from an enterprise AppSec vendor writing for a security team with a threat model and a review board. None connects the risk to what a founder’s stack actually looks like: a handful of servers added over a few weeks because each one solved that afternoon’s problem, with nothing written down about any of them. Across the 21 third-party apps in the AxonBuild audit corpus, Dependencies and Supply Chain averaged 34.5 out of 100, scored on 20 of them, the second-weakest of the twelve readiness areas. An MCP server installed with npx -y …@latest is an unpinned dependency holding a live connection to production data, which puts it in the area founders already score worst on.
Everything below was checked against the current documentation on 29 July 2026.
What is Model Context Protocol (MCP) and what does Claude Code use it for?
Model Context Protocol is one wire format for the job every AI tool kept solving separately: handing a model a tool it can call and data it can read. A server written once works in Claude Code, Cursor, and Codex, so a vendor building a Stripe or GitHub integration writes it once instead of three times.
In practice a server is a small program, or a URL, that advertises a list of tools. Claude Code reads that list at startup and can call any of them mid-conversation. A Postgres server exposes something like query; a browser server exposes navigate and click. Nobody types those calls. The agent decides when to make them.
How do I add an MCP server to Claude Code with claude mcp add in 2026?
Adding an MCP server to Claude Code takes one claude mcp add command, and the only real decision is the transport: http for a hosted server, sse for the few services that still publish only that endpoint, and stdio for a server that runs as a local process on your machine.
# HTTP, the transport to prefer
claude mcp add --transport http stripe https://mcp.stripe.com
# SSE, deprecated, still the only endpoint some services publish
claude mcp add --transport sse asana https://mcp.asana.com/sse
# stdio, runs the server as a local process
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
-- npx -y airtable-mcp-serverTwo details in that third line trip people up. The -- matters: Anthropic’s MCP documentation states that everything after it “is passed to the server untouched,” so without it Claude Code tries to parse the server’s own flags as its own. And --env accepts multiple KEY=value pairs, so the server name can’t sit directly after it or the CLI reads that name as another pair and rejects the command. Neither is guessable from the one-line snippets people copy.
One thing to check before copying a tutorial: SSE is deprecated. The docs say so plainly, “The SSE (Server-Sent Events) transport is deprecated. Use HTTP servers instead, where available,” and plenty of setup guides written since still lead with it.
Local, project, or user: which .mcp.json scope lands in your git repo?
Scope decides two things at once: where the entry is stored, and who else gets it. Only one of the three writes a file into your repository.
| Scope | Where it lives | Who else sees it | Loads in |
|---|---|---|---|
| Local (the default) | ~/.claude.json | Nobody | The current project only |
| Project | .mcp.json in the repo root | Everyone with repo access, through version control | The current project only |
| User | ~/.claude.json | Nobody | All your projects |
Project scope is the one designed to be committed. That is the right call for a team, and a new place to leak a key if you paste one in. The documented way out is variable expansion: ${VAR} and ${VAR:-default} both work, in command, args, env, url, and headers.
{
"mcpServers": {
"api-server": {
"type": "http",
"url": "${API_BASE_URL:-https://api.example.com}/mcp",
"headers": { "Authorization": "Bearer ${API_KEY}" }
}
}
}That file is safe to commit. The same file with the token typed in is the committed-secret problem wearing a new filename.
When one server name appears in more than one scope, Claude Code takes the whole entry from the highest-precedence source and connects once. The order runs local, then project, then user, then plugin-provided servers, then claude.ai connectors. Fields are never merged across scopes, so editing one field in a lower-precedence copy changes nothing at all. Project-scoped servers also prompt for approval before Claude Code will use one, and claude mcp reset-project-choices clears those answers.
Which Claude Code MCP servers do founders actually connect?
The MCP servers founders actually reach for are a set of six, and the same six fill every “best MCP servers for Claude Code” roundup: GitHub, Postgres or Supabase, Playwright, Context7, Stripe, and Shopify’s Dev MCP server. Those roundups rank on popularity. Read the second column below instead.
| Server | What it reaches |
|---|---|
| GitHub | Issues, pull requests, and repository contents, scoped to whatever the token allows |
| Postgres or Supabase | Every table the connection string’s role can read, with row-level security applied or bypassed depending on which role you pasted |
| Playwright | A real browser session, including any site that browser profile is already signed into |
| Context7 | Library documentation, fetched live from an external service |
| Stripe | Your Stripe account, at whatever the API key permits |
| Shopify Dev MCP | Shopify’s developer documentation and API schemas, locally, with no authentication |
Four of those six reach something live, two reach documentation, and the install command looks identical either way. Reach is not the only thing an install spends, either: what MCP servers cost you in tokens is the other column those roundups leave out.
Can you connect Claude Code to Shopify?
Claude Code connects to Shopify through the Shopify Dev MCP server, which runs locally, needs no authentication, and reaches three things: Shopify’s developer documentation, its API schemas, and code validation for GraphQL queries, Liquid templates, and extensions. It never touches a store.
claude mcp add --transport stdio shopify-dev-mcp -- npx -y @shopify/dev-mcp@latestStore management is a separate path with a separate credential. Per Shopify’s Dev MCP documentation, the toolkit can prepare and run supported store-management tasks through Shopify CLI’s authenticated store context, with you choosing when to execute them. Hold onto that distinction, because the phrase “the Shopify MCP server” gets used for both. What can reach an order runs under credentials you granted the CLI on a different day, for a different reason.
Can I use Claude Code in GitHub?
Yes, and two different things go by that name. One is connecting the GitHub MCP server to the agent running in your terminal, the row at the top of the table above: issues, pull requests and repository contents, scoped to whatever token you handed it. The other is running Claude Code inside GitHub itself, which is a separate product called Claude Code GitHub Actions. There you mention @claude in an issue or pull request comment and a workflow runs the agent on GitHub’s runners.
Setup for the second one is one command, run from a Claude Code session in the repo:
/install-github-appPer Anthropic’s GitHub Actions documentation, checked on 29 July 2026, that installs the Claude GitHub App on the repository and then walks you through adding the workflow file and your API key as a repository secret. The App asks for read and write on Contents, Issues, and Pull requests, so it is the same shape as every other install in this post: one approval screen, a standing grant, and a credential that keeps working until you remove it. Two meters run as well, not one. The workflow spends GitHub Actions minutes and every @claude reply spends API tokens.
The part that reads differently from the terminal case is that nobody is at a keyboard during a workflow run. --mcp-config is a documented claude_args argument, so a whole server list can load inside a job with no prompt to answer and no one to answer it, which is worth knowing before you point that path at anything holding production credentials. The narrower default is to keep MCP servers on your machine and let the Action do repository work.
There is a third route, GitHub Code Review, which posts findings inline on pull requests without anyone typing a trigger phrase. Its documentation puts it in research preview on Team and Enterprise plans, so it is not the one a solo founder starts with.
MCP server security risks: what can a malicious or over-permissioned server reach?
A connected MCP server reaches exactly what its credentials allow, and Claude Code adds no second check once the connection is up. The four rows below put what the install step promises next to what the credential actually opens.
That second row is Anthropic’s own wording, from its security page:
Anthropic reviews connectors against its listing criteria before adding them to the Anthropic Directory, but does not security-audit or manage any MCP server.
A reasonable position for a protocol steward to take, and it leaves the trust decision with you. Anthropic’s MCP page puts it from the other side: “Verify you trust each server before connecting it. Servers that fetch external content can expose you to prompt injection risk.”
Claude Code does run a trust-verification step for new servers, and its security documentation names the hole in it: “Trust verification is disabled when running non-interactively with the -p flag.” Any CI job, cron script, or automated pipeline invoking Claude Code with -p gets no prompt for a server it has never seen. That is a narrower gap than the permission model covered in whether Claude Code is safe to use on a real codebase, and it sits in a place a founder is unlikely to check.
Then there is the config file itself. In the audit corpus, 6 of 21 third-party apps shipped a real secret, and 3 of those were permanently in git history: a webhook signing secret in one, a live AI-provider key in another, a Stripe test key and webhook secret in a third. The AI-provider key is worth walking through, because the tidy-up is what did the damage. An early version had written the key into the app’s own config file and committed it. The project later moved to a .env and deleted the config, and a working key sat readable in several past commits regardless, because deleting a file does not delete what git already recorded. .mcp.json is a file the documentation encourages you to commit, which makes it a fresh candidate for the same mistake. The counterweight: Secrets was the highest-scoring area in the corpus at 84 out of 100. This is a habit you already have, pointed at one more file.
How do you vet an MCP server before you connect it?
Vetting an MCP server is seven checks, covering who wrote it, which version you pinned, what its credential reaches, and where the config lives. None of them takes longer than reading the README.
- 01 Check who publishes it before checking what it does: the vendor whose API it wraps, or a stranger who picked a matching name
- 02 Pin the version. npx -y package@latest re-fetches whatever was published this morning, on every single launch
- 03 Read what it reaches, not what it is called. A Postgres server reaches whatever the connection string’s role reaches, so hand it the anon role rather than the service role
- 04 Keep every secret in the environment instead of the file, using ${VAR} expansion in command, args, env, url, and headers
- 05 Pick the scope deliberately: project scope for servers the team should review in a pull request, local scope for anything holding a personal token
- 06 Write the deny rule before the allow rule, and know that the allow syntax is stricter than the deny syntax
- 07 Re-review after updates. Approval attaches to an entry, and an entry can change after you approved it
The sixth check hides an asymmetry in the syntax. Deny and ask rules accept a bare glob, so "deny": ["mcp__*"] removes every MCP tool at once. Allow rules only accept a glob after a literal mcp__<server>__ prefix, and an unanchored allow glob is skipped with a warning and approves nothing at all.
{
"permissions": {
"deny": ["mcp__*"],
"allow": ["mcp__github__get_*"]
}
}Deny everything, then allow the read-only tools of one named server. That sits a layer below what a CLAUDE.md should say about fragile areas: a rules file tells the agent what not to break, while MCP permissions decide what it can touch at all. The instruction file every other coding agent reads sits in the same relationship to it.
Running seven checks across a stack of servers by hand costs an afternoon. A review that reads what every connected tool can actually reach in your codebase makes the same pass with file and line references, as one part of what a launch-ready AI-built app has to answer for.
Connecting servers is still the right call most of the time. The part that gets skipped is keeping a written list of which ones are connected, and I have no good answer for how a solo founder is supposed to remember why the ninth server went in on a Tuesday eight months ago, other than writing it down at the time, which nobody does.
Common questions about Claude Code and MCP
Can you connect Claude Code to Shopify?
Yes, through the Shopify Dev MCP server, which runs locally with no authentication and reaches Shopify’s developer documentation, API schemas, and code validation for GraphQL, Liquid, and extensions. It cannot touch a real store. Store-management tasks run on a separate path, through Shopify CLI’s authenticated store context, with you choosing when to execute them.
Can I use Claude Code in GitHub?
Yes, two ways, and they are separate products. The GitHub MCP server connects the agent in your terminal to issues, pull requests and repository contents through a token you supply. Claude Code GitHub Actions runs the agent inside GitHub instead: /install-github-app installs the Claude GitHub App and sets up the workflow file and API key secret, then mentioning @claude in an issue or pull request comment starts a run on GitHub’s runners, billed as Actions minutes and API tokens at the same time. The App holds read and write on Contents, Issues, and Pull requests for as long as it stays installed.
Can a malicious MCP server read my .env file or Supabase service role key?
A server reads whatever you handed it, directly, with no Claude Code permission prompt sitting in between. Paste a service role key into an MCP config and that server holds the key from then on. Two habits cover most of the exposure: use ${VAR} expansion so the file carries a variable name instead of a secret, and give a database server the narrowest role that still does the job.
What is the difference between local, project, and user scope in .mcp.json?
Local scope is the default, stores the entry in ~/.claude.json, and applies to the current project only. Project scope writes .mcp.json into the repository root, so the entry ships to everyone through version control. User scope also lives in ~/.claude.json but loads in all your projects. Local wins over project, project over user, and the winning entry is used whole, with no field merging.
Does adding an MCP server expose my code to anyone?
Not on its own. A local stdio server runs on your machine, and an HTTP server only sees what its tools are called with, so the exposure depends on which server it is and which credentials it holds. What changes with each one you add is the number of things holding live access at the same time, which is why the list is worth keeping. Running Claude Code with permission prompts skipped entirely, which some people do to stop the interruptions, widens all of it at once.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.
