Using MCP Servers With Claude Code

Out of the box, Claude Code knows your repository. It reads your files, runs your shell commands, and edits code in place. That covers a lot — but plenty of the context you need lives outside the repo: the schema of a running database, the state of an issue tracker, a library's documentation, an error in your monitoring tool. MCP servers are how you hand Claude Code access to those systems without leaving the terminal.

This guide explains what MCP is at a concept level, why you'd connect one, the kinds of servers people actually use, and — most importantly — the trust considerations to weigh before you do. For exact command flags and config field names, check the official Claude Code MCP docs, which stay current as the tool changes.

What MCP actually is

MCP stands for Model Context Protocol. It's an open standard, introduced by Anthropic, for connecting AI applications to external tools and data sources through a common interface. The point of a standard is exactly what you'd hope: a tool built once as an MCP server can be used by any MCP-compatible client, instead of every application inventing its own bespoke plugin format.

The architecture is client–server. An MCP server is a program that exposes some capability — talking to a database, calling an API, reading a set of documents. An MCP client connects to that server and makes those capabilities available to the model. Here, Claude Code is the host application that runs the MCP client, and the servers you connect are what it reaches out to.

Servers expose a few kinds of capabilities. The one you'll care about most is tools — functions the model can decide to call, like "run this query" or "create this issue." Servers can also expose resources (data the model reads as context) and prompts (reusable templates). Different servers implement different subsets: a database server is mostly tools, a documentation server might lean on resources.

Why connect one to Claude Code

Claude Code is already capable inside your project. The reason to add an MCP server is to extend it beyond the filesystem — tools and data it otherwise has no way to reach. A few concrete motivations:

• Live systems, not just files. Your repo has migration files, but the actual shape of

your dev database — the tables that exist right now, the columns, the indexes — lives in the database. A database MCP server lets Claude inspect that directly instead of guessing from code.

• Context that isn't in the repo. Framework docs and your team's internal knowledge base

aren't checked into your project. A documentation or knowledge-source server pulls the relevant page into context on demand.

• Closing the loop on external state. When you're fixing a bug, the report is in an issue

tracker and the stack trace might be in a monitoring tool. Connect those and Claude can read the ticket, correlate it with the code, and — if you allow it — update the ticket when the fix lands.

The through-line: you stay in one place. Instead of copy-pasting a schema dump or a ticket into the prompt, the model fetches what it needs itself.

Typical examples

You don't have to write servers from scratch — there's a growing ecosystem of ready-made ones, and many vendors publish official servers for their products. Common categories:

• A database. Expose a dev or staging database so Claude can read the schema and run

queries. This is one of the highest-value connections, because so much reasoning about an app depends on knowing its real data model. Keep it read-only and off production data unless you have a strong reason not to.

• A documentation or knowledge source. Point Claude at a library's docs, an API

reference, or your internal wiki so it grounds answers in current, specific material instead of general recall.

• An issue tracker. Connect GitHub Issues, Linear, or Jira so Claude can read a ticket

you name, pull acceptance criteria into the plan, and optionally file or comment on issues.

The same pattern extends to error monitoring, CI systems, cloud consoles, and design tools. If a system has an API and someone has wrapped it as an MCP server, Claude Code can likely use it.

Configuring a server, conceptually

You don't edit Claude Code's internals to add a server — you register it, and Claude Code manages the connection. Two ideas are worth understanding before you look up the exact syntax.

Transport: local vs remote. A local (stdio) server runs as a subprocess on your own machine; you configure it with a command to launch and any arguments. A remote server runs elsewhere and Claude Code talks to it over HTTP; you configure it with a URL, and it usually requires authentication. Local servers are private but run code on your machine; remote servers are shared and managed but send requests off-box. Pick based on where the data and trust boundaries sit.

Scope: who sees this server. Claude Code lets you register a server at different scopes — roughly, just for you in this project, shared with the whole project through a config file committed to the repo, or in your personal user-level configuration that follows you across projects. A project-shared server is great for onboarding — clone the repo and you have the same tools as the team — while a personal server keeps a private credential out of shared config.

Claude Code exposes a claude mcp command family for adding, listing, and removing servers, and project-shared servers are typically declared in a JSON config file in the repo. A stdio server's config generally looks something like this:

{
  "mcpServers": {
    "example-db": {
      "command": "the-server-executable",
      "args": ["--some-option", "value"]
    }
  }
}

Treat that as an illustration of the shape, not a spec — the exact file name, field names, and command flags evolve, so confirm them in the official docs rather than trusting a blog (including this one) for the literal strings.

Trust and permission considerations

This is the part to slow down on. An MCP server is third-party code that runs with your privileges and can take real actions. That power is the whole point, and also the whole risk.

• A local server runs as you. A stdio server is a process on your machine with your

user's access. Only install servers whose source you trust, the same way you'd vet any dependency you're about to run. "It's just an MCP server" is not a security property.

• Tools can have side effects. Reading a schema is harmless; creating an issue, writing

to a database, or sending a message is not. The model decides when to call a tool based on the description the server advertises — so a poorly scoped or malicious server can offer dangerous tools, and those descriptions are themselves untrusted input that could attempt prompt injection. Prefer read-only tools and scoped credentials wherever the task allows.

• Connecting a server exposes its data to the model. Whatever a resource or query can

reach can flow into the context. Don't wire a production database or a secrets store into a coding session out of convenience.

• Approve deliberately. Claude Code asks before using servers defined in shared project

config, and prompts before tool calls, precisely because a server you didn't personally add shouldn't run silently. Read those prompts, and treat a new server in a committed MCP config the way you'd treat a new build script someone added.

The safe default is least privilege: point servers at dev, not prod; keep them read-only unless you need writes; use narrowly scoped tokens; and add one server at a time so you understand what each can do.

Wrapping up

MCP turns Claude Code from a repo-aware assistant into one that can also reach your database, your docs, and your issue tracker — through a single open standard rather than a pile of one-off integrations. The value is real: less copy-pasting, more grounded answers, tighter loops between code and the systems around it. The cost is that you're granting an agent live access to those systems, so the discipline matches adding any dependency — trust the source, scope the permissions, start read-only.

Get one useful server connected — a read-only dev database is a great first one — read the approval prompts, and expand from there. If you want a starting point for the rest of your Claude Code setup, the free claude-code-starter repo is a reasonable place to begin.

Related guides

• A Pre-Merge Review Pipeline With Claude Code
• How to Prompt Claude Code Effectively
• Safe Refactoring With Claude Code