Skip to main content

MCP Servers in Claude Code

Advanced

The Model Context Protocol (MCP) is an open standard for connecting AI to external tools and data. An MCP server exposes capabilities (query a database, open a GitHub PR, drive a browser); Claude Code connects to it and can call those tools during a session. It's how you extend Claude beyond your filesystem and shell.

What you'll learn
  • Explain what an MCP server is and how Claude Code calls its tools
  • Tell apart the two transports: local stdio vs remote HTTP/SSE
  • Add a server with claude mcp add and read the JSON it writes
  • Choose the right scope (local, project, user) for who sees a server
  • Connect a real database to Claude end-to-end
  • Avoid the security and configuration traps that bite most people

The shape of it​

You declare servers Claude may use; each server publishes a set of tools with schemas; Claude picks and calls them like any other tool.

MCP vocabulary
Press Enter or Space to flip the card. Use the left and right arrow keys to move between cards.Term shown.
1 / 5

Transports​

There are two ways Claude reaches a server. Pick by where the server runs.

  • stdio — a local process Claude launches (great for local tools/CLIs).
  • Remote (HTTP/SSE) — a hosted server, often with OAuth.

Configuring servers​

The fastest path is the claude mcp add command — it writes the config for you. Follow this sequence to go from zero to a connected server.

Guided walkthrough1 of 4
  1. Run claude mcp add — everything after the -- is the launch command Claude runs for you.

Add a local stdio server

# A local stdio server (everything after -- is the launch command)
claude mcp add github -- npx -y @modelcontextprotocol/server-github

Add a remote HTTP server (shared with the project)

# A remote HTTP server, shared with everyone on the project
claude mcp add --transport http --scope project linear https://mcp.linear.app/mcp

Under the hood that's just JSON. A project-scoped server lands in a .mcp.json at the repo root — check it in and your whole team gets the same tools:

{
  "mcpServers": {
    "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] }
  }
}

Scope decides who sees the server​

ScopeLives inUse it for
local (default)your user settings, this project onlypersonal experiments, secrets
project.mcp.json in the repo (committed)tools the whole team should share
useryour user settings, all projectsservers you want everywhere

Run claude mcp list to see what's connected and /mcp inside a session to inspect tools and authenticate remote servers. See MCP Config & Server Scaffolds for copy-paste starters.

Worked example: give Claude your database​

Say you want Claude to answer questions against a local Postgres instead of you pasting query results. Add the server (project scope, so teammates inherit it):

Add a Postgres server at project scope

claude mcp add --scope project db -- npx -y @modelcontextprotocol/server-postgres "postgresql://localhost/app"

Now in a session you can ask the question in plain language and let Claude do the query loop for you:

Ask a question against the database

How many users signed up last week? Check the DB.

Claude calls the server's query tool, gets rows back, and answers — no copy-paste loop. Because it's project-scoped, a teammate who pulls the repo gets the same capability the moment they open Claude Code. Keep the connection string read-only if you only want reads.

Trust & security​

Watch out
  • An MCP server runs code and can read data and take actions — only connect servers you trust.
  • Give each server the least privilege it needs.
  • Any external content a server returns can carry prompt injection.
  • Review third-party servers before connecting them.

:::warning Treat MCP servers like installing software An MCP server runs code and can read data and take actions. Only connect servers you trust, give them the least privilege needed, and remember that any external content they return can carry prompt injection. Review third-party servers first — see Reviewing Third-Party Code. :::

MCP in the apps too​

MCP also powers Connectors in the Claude apps — same standard, different surface. See Connectors (MCP) in the Apps and, for the API, MCP & Connecting to Tools.

Common mistakes​

  • Wrong scope. A server added at local scope won't appear for teammates; one you only wanted for yourself shouldn't be committed at project scope. Pick deliberately.
  • Too many servers, too many tools. Each connected server adds its tool schemas to the context — a tax paid on every turn. Connect what the task needs, not your whole catalog. See The MCP Token Tax for the real numbers and how defer_loading and code execution cut them.
  • Over-privileged connections. Give a database server a read-only role unless Claude genuinely needs to write. MCP makes capabilities real — scope them down.
  • Forgetting the injection risk. Anything a server returns (a web page, an issue body, a row) is untrusted text that can carry prompt injection. Don't wire a powerful write-capable server next to an untrusted read-capable one without thinking it through.

Check yourself

0/3
  1. Which transport is a local process that Claude launches itself?
  2. Where does a project-scoped server get written, and what's the benefit?
  3. Why keep a database connection read-only when Claude only needs to read?
Key takeaways
  • MCP is an open standard; an MCP server exposes tools that Claude Code calls like any other tool.
  • Two transports: local stdio (a process Claude launches) and remote HTTP/SSE (hosted, often OAuth).
  • claude mcp add writes the config for you; under the hood it's JSON, and project scope lives in a committed .mcp.json.
  • Scope controls visibility: local (you, this project), project (committed for the team), user (you, everywhere).
  • Treat servers like installing software: trust, least privilege, and watch for prompt injection in anything they return.

Next​