Claude Code MCP: How to Connect Tools and Data to Your Agent

Out of the box, Claude Code can read files, run commands, and search the web. The moment you want it to query your Postgres database, file a Jira ticket, drive a browser, or pull a design from Figma, you need MCP. The Model Context Protocol is an open standard for connecting AI agents to external tools and data sources, and Claude Code is its deepest implementation: one configuration line gives your agent a new capability, with the same permission controls that govern everything else it does. This guide explains how the pieces fit and gets you from zero to a working server without the detours.

The mental model

An MCP server is a small program that exposes three kinds of things to an agent: tools (actions the agent can invoke, like query_database or create_issue), resources (data the agent can read), and prompts (reusable instruction templates). Claude Code is the MCP client. When a server is configured, its tools appear alongside the built-in ones, the agent decides when to call them, and your permission rules decide whether the call is allowed.

The protocol's value is the many-to-many economics: any server works with any MCP client, so the community builds a connector once (GitHub, Slack, Postgres, Playwright, Stripe, Sentry, and hundreds more exist) and every agent benefits. This is why MCP spread beyond Anthropic and became the industry's default connector standard.

Adding a server in one command

The CLI manages everything:

# A local server, run as a subprocess over stdio
claude mcp add postgres-db -- npx -y @modelcontextprotocol/server-postgres "postgresql://localhost/mydb"

# A remote server over HTTP
claude mcp add --transport http github https://api.githubcopilot.com/mcp/

# List, inspect, remove
claude mcp list
claude mcp get github
claude mcp remove github

Two transports cover practice: stdio for local servers Claude Code launches itself (the command after -- is how it starts them), and HTTP for remote servers that stay running elsewhere. Remote servers that need authentication use OAuth: run /mcp inside a session and Claude Code walks you through the browser login and stores the token.

The three scopes, and when each is right

Where a server's configuration lives determines who gets it:

• local (default): stored in your user settings for this project only. Right for personal experiments and credentials only you should hold.
• project: written to a .mcp.json file at the repo root, checked into version control, shared with every teammate. Right for the team's standard connections, such as the project database, the issue tracker, or the docs source. Claude Code asks for approval before using a project-scoped server from a fresh checkout, so cloning a repo does not silently grant it capabilities.
• user: available to you across all projects. Right for personal utilities you want everywhere, like a browser-automation server.

Pass the scope at add time: claude mcp add --scope project .... A .mcp.json looks like this and can be edited directly:

{
  "mcpServers": {
    "postgres-db": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
    }
  }
}

Environment variables in the config support ${VAR} expansion, which keeps secrets out of the checked-in file.

Security, before convenience

An MCP server extends what your agent can do, so treat adding one like adding a dependency with hands.

Install only servers you trust. A malicious server can feed the agent poisoned tool results, and tool descriptions themselves are instructions the model reads. Prefer official vendor servers and widely-used community ones, and read the source of anything obscure before wiring it to real credentials.

Scope credentials down. Give the database server a read-only role until the agent has earned write access. Give API tokens the minimum scopes. The server can only misuse what you handed it.

Let permissions do their job. MCP tools appear in Claude Code's permission system as mcp__servername__toolname, so you can allow reads while requiring approval for writes, exactly as you would for shell commands. Our permissions guide covers the rule syntax.

Remember prompt injection. Any server that returns web content or user-generated text can carry adversarial instructions in its results. Agents with both untrusted input sources and powerful write tools deserve tight approval settings, and this pairing is precisely what the exam scenarios probe.

The connections worth making first

Start with the server that removes your most frequent context switch:

1. Your database (Postgres or the official Supabase server): the agent answers schema questions and writes migrations against reality instead of memory.
2. GitHub: issues, PRs, and reviews become things the agent reads and files itself.
3. Playwright: the agent drives a real browser, which turns "check that the form still submits" into a delegated task.
4. Your docs or knowledge base: a Context7 or docs server keeps the agent's library knowledge current instead of frozen at training time.
5. Whatever your team's system of record is: the internal API wrapped in a thin MCP server is usually a one-day build that pays off daily, and tool design practices covers how to shape it well.

Where MCP fits in the bigger picture

MCP is one layer of Claude Code's operating system, alongside CLAUDE.md memory, permissions, hooks, skills, and subagents. The architecture guide goes deeper on the protocol itself, and the free Claude Code course teaches the full stack level by level, with MCP arriving once the fundamentals are in place. Connect one server today, put its write tools behind an approval rule, and you have crossed the line that separates a chat assistant from an agent wired into your actual work.