Claude Code MCP Explained: The Model Context Protocol Guide

If you have spent any time with Claude Code, you have probably run into Claude Code MCP — the way the tool plugs into external data and services through the open Model Context Protocol. MCP is what lets Claude Code reach beyond your local files to talk to a database, drive a browser, read your design tool, or query an internal API, all without you hand-rolling a custom integration. This guide explains what MCP actually is, how MCP servers show up inside Claude Code, and where to find the exact configuration syntax. Claude Drops is an independent project and is not affiliated with Anthropic; everything here points back to the official docs for authoritative details.

What is the Model Context Protocol?

The Model Context Protocol (MCP) is an open standard, originally introduced by Anthropic, for connecting AI applications to external tools and data sources. Think of it the way you might think of the Language Server Protocol (LSP) for editors: instead of every editor writing a bespoke integration for every language, LSP defines one common protocol so any editor can talk to any language server. MCP does the same thing for AI tools — one protocol so any MCP-capable client (like Claude Code) can talk to any MCP server.

That matters because the hard part of agentic coding is rarely the model itself — it is context. The model needs to see your schema, your tickets, your docs, your running app. MCP standardizes how that context flows in, so the same database server you wire into Claude Code can, in principle, be reused by any other MCP-compatible client.

What is an MCP server, exactly?

An MCP server is a small program that exposes capabilities to an AI client over the protocol. A client like Claude Code is the host; it launches or connects to one or more servers and negotiates what they offer. Servers can expose a few different kinds of things:

• Tools — actions the model can invoke, like "run this SQL query," "open this URL in a browser," or "create a ticket."
• Resources — readable data the model can pull in as context, like a file, a document, or a record from a system.
• Prompts — reusable, parameterized prompt templates a server can offer to the client.

In day-to-day Claude Code use, the part you notice most is tools. When you connect a Postgres MCP server, Claude Code suddenly has tools for inspecting tables and running queries; connect a browser server and it can navigate and read pages. The model decides when to call those tools as part of completing your request, and Claude Code surfaces and gates those calls for you.

How Claude Code MCP shows up in a session

In Claude Code, MCP is the extension mechanism for third-party integrations. Once a server is configured, its tools become available to the agent during a session, alongside the built-in abilities to read and edit files, run shell commands, and search your codebase. A few practical things to know:

• MCP servers can be scoped — for example available only inside a single project, or shared across all your projects on your machine. Check the docs for the exact scope names and where each config lives.
• Claude Code can list which MCP servers are connected and which tools they expose, so you can confirm a server actually came up before relying on it.
• Tool calls from MCP servers are still subject to Claude Code's permission and approval model, so a server cannot silently run destructive actions without surfacing them.

If you are still getting your bearings on terms like host, tool, resource, and transport, our Claude Code glossary defines them in one place. MCP also pairs naturally with Claude Code Skills — Skills package reusable instructions and workflows, while MCP servers provide the live tools and data those workflows often need.

Transports: how the client and server talk

MCP defines how a client and server communicate over a transport. You mostly encounter this at a high level when configuring a server, and the right choice usually depends on whether the server runs locally or remotely:

For a local stdio server, configuration usually amounts to a command plus arguments that Claude Code runs. For a remote server, you typically point at a URL and provide any required authentication. The exact keys, flags, and file format can change between versions, so treat the table above as conceptual and confirm the current syntax in the official documentation rather than copying values blindly.

What MCP servers are good for

The whole point of Claude Code MCP servers is to close the gap between your codebase and the systems around it. Some representative categories:

• Databases — inspect schemas, run read or write queries, and let the agent reason about your actual data, not a guess at your data model.
• Browsers — navigate pages, read rendered content, and verify UI behavior as part of a coding task.
• Design tools — pull design specs, components, or layout data so generated code matches the source of truth.
• Issue trackers and docs — read tickets, requirements, and internal documentation so the agent has the surrounding context.
• Cloud and infra providers — query resources or trigger provider-specific actions through a vendor's MCP server.

Because these servers are reusable across MCP clients, an integration you build or adopt for Claude Code is not throwaway work — it can serve other MCP-aware tools too, which is part of why the ecosystem has grown quickly.

Adding an MCP server to Claude Code

The high-level flow is consistent even as the exact commands evolve: you tell Claude Code about a server (its transport, command or URL, and any credentials), Claude Code connects, and the server's tools become available in your session. The example below is illustrative of the shape of a local stdio config — confirm the real field names and command in the docs before using it.

{
  "mcpServers": {
    "my-database": {
      "command": "some-mcp-server-binary",
      "args": ["--connection-string", "postgres://localhost/app"]
    }
  }
}

For the authoritative, current syntax — including how to add servers from the CLI, scope them, and pass secrets safely — see the official Claude Code documentation. If you are curious how MCP support and related tooling have evolved release over release, the Claude Code changelog is the fastest way to track it, and the upstream CHANGELOG.md is the source of record.

Common gotchas

1. Server not starting. A stdio server is just a process — if the command is wrong or a dependency is missing, it will fail to launch. List your connected servers to confirm it came up before debugging your prompt.
2. Auth and secrets. Remote servers usually need credentials. Use the documented mechanism for passing secrets rather than hardcoding tokens into shared config files.
3. Too many tools. Connecting many servers at once floods the agent with tool options and can dilute focus. Enable only the servers a given task actually needs.
4. Scope confusion. If a server works in one project but not another, you may have configured it at the wrong scope. Confirm where the config lives.

Bottom line

Claude Code MCP turns the tool from a smart local coding assistant into one that can reach the rest of your stack through a single open standard. Learn the three building blocks — servers, the tools and resources they expose, and the transport they use — and the configuration details fall into place. Because the Model Context Protocol is open and shared across clients, the integrations you set up keep paying off. To go deeper, pair this with Claude Code Skills, keep an eye on new MCP-related capabilities in the Claude Code changelog, and consider getting the Claude Drops app so a push lands the moment a relevant release ships.