Claude Code MCP Explained

Claude Code MCP lets an AI coding agent query your database, read your tickets, and post to your team chat without custom integrations. Model Context Protocol is an open standard that connects Claude Code to external tools through a shared interface.

MCP matters because it turns Claude Code from a repo-only tool into a workflow agent. Instead of copying data into prompts, the agent calls tools that fetch live context from the systems your team already uses.

This guide covers how Claude Code MCP servers work, how to configure them, which integrations teams adopt first, and the security model you need before connecting production systems.

What is Model Context Protocol

Model Context Protocol is an open standard created by Anthropic for connecting AI agents to external tools and data sources. It defines a universal way for an agent to discover available tools, call them with structured inputs, and receive structured outputs.

Before MCP, every integration required custom code. A team that wanted Claude Code to read from PostgreSQL, check GitHub issues, and post to Slack needed three separate wrappers. MCP replaces that with one protocol that all three servers speak.

Each MCP server exposes a list of tools. When Claude Code connects to a database MCP server, it sees tools like query, list-tables, and describe-schema. The agent picks the right tool, passes parameters, and gets results back in a standard format.

• Open standard, not proprietary to Anthropic. Anyone can build or host an MCP server.
• Each server exposes typed tools with names, descriptions, and input schemas.
• Claude Code discovers available tools at connection time, no hardcoded list.
• One protocol replaces dozens of one-off integration scripts.

How Claude Code MCP servers connect

MCP servers connect to Claude Code through settings.json, either at the project level or globally. You define each server by name, transport type, and command or URL. Claude Code launches the server process and negotiates available tools on startup.

Two transport types exist. Stdio transport runs a local process and communicates over standard input and output. This is how most MCP servers work: Claude Code spawns a Node or Python process, and they exchange JSON messages. SSE transport connects to a remote HTTP server using server-sent events, which is better for shared team servers or cloud-hosted integrations.

Project-level servers go in .claude/settings.json inside your repo. Global servers go in ~/.claude/settings.json. Project-level servers only activate when you open that project. Global servers are available everywhere. Most teams start with project-level to keep scope tight.

• Stdio: local process, fast, no network dependency. Best for database and filesystem servers.
• SSE: remote HTTP endpoint. Best for shared team servers or cloud APIs.
• Project config: .claude/settings.json for repo-specific servers.
• Global config: ~/.claude/settings.json for tools you want everywhere.

Claude Code MCP servers teams use first

The most-adopted MCP servers connect Claude Code to databases, version control, communication tools, and cloud platforms. Teams typically start with one read-only server and expand after they see the workflow improvement.

PostgreSQL and Supabase MCP servers let Claude Code query tables, inspect schemas, and run SQL. A developer can say "find all users who signed up this week but never completed onboarding" and the agent writes and runs the query. The Supabase server adds project management and edge function deployment.

The GitHub MCP server gives Claude Code access to issues, pull requests, reviews, and repository metadata. Instead of switching to a browser, a developer asks the agent to list open PRs with failing checks, read the test output, and suggest a fix in one session.

Slack and Google Drive MCP servers round out the common stack. Slack lets the agent post summaries, notify channels on completion, or read thread context. Google Drive lets it read shared docs and spreadsheets as context for code changes.

• PostgreSQL / Supabase: query data, inspect schemas, manage migrations.
• GitHub: read issues, review PRs, check CI status, manage releases.
• Slack: post notifications, read thread context, send completion alerts.
• Google Drive: read shared docs and spreadsheets as project context.
• Brave Search: web search for documentation and package lookups.
• Filesystem: controlled access to directories outside the current repo.

How to set up an MCP server step by step

Setting up an MCP server takes under five minutes for most community servers. You install the server package, add the configuration to settings.json, and restart Claude Code. The agent detects the new tools on next launch.

For a PostgreSQL server, install the package with npm, then add a block to your project .claude/settings.json under the mcpServers key. You specify the command (npx), arguments (the server package name and your connection string), and optionally environment variables for credentials. Claude Code spawns the server process and lists available tools.

For a custom internal API, you build a small server that speaks the MCP protocol. Anthropic publishes SDKs in TypeScript and Python. Your server defines tools with names, descriptions, and JSON Schema inputs. When Claude Code connects, it reads the tool list and can call them like any other tool. A typical internal server takes a day to build and covers five to ten API endpoints.

• Install: npm install or pip install the MCP server package.
• Configure: add the server block to .claude/settings.json under mcpServers.
• Credentials: pass secrets via environment variables, never inline.
• Test: restart Claude Code and ask it to list available tools from the new server.
• Custom servers: use the TypeScript or Python MCP SDK to expose your own API.

Claude Code MCP security model

MCP servers run with whatever permissions you grant them, so security starts with least privilege. A database server should use a read-only connection string until you explicitly need writes. A Slack server should be scoped to specific channels, not your entire workspace.

Claude Code prompts for permission before calling MCP tools for the first time in a session. You can pre-approve specific tools in settings.json or require approval every time. For production databases, always require per-call approval for any write or delete operation.

Credential isolation matters. Store database passwords, API keys, and tokens in environment variables, not in settings.json files that get committed to repos. Use .env files with .gitignore entries or a secrets manager. The MCP server process inherits environment variables from its launch context, so you control what it can access.

Audit logging is your safety net. Log every MCP tool call with timestamp, tool name, inputs, and the user who triggered it. Most MCP server implementations support logging out of the box. Review logs weekly during early rollout.

• Use read-only credentials for database and API servers by default.
• Store secrets in environment variables, never in committed config files.
• Require per-call approval for write and delete operations.
• Log every tool call for audit and review.
• Separate development and production MCP server configurations.

Building your own MCP server

Community servers cover common tools, but most teams eventually need a custom MCP server for internal APIs. The MCP SDK makes this straightforward. You define tools as functions with typed inputs and outputs, register them with the server, and Claude Code discovers them at connection time.

A CRM integration is a good first custom server. You expose tools like search-contacts, get-deal-pipeline, and log-activity. Claude Code can then pull customer context while writing code, draft follow-up emails based on deal stage, or generate reports from CRM data without any copy-paste.

Build servers in layers. Start with read-only tools that search and retrieve. Add write tools only after the read layer proves useful and your team has review processes in place. Each tool should do one thing. A tool called update-contact-and-send-email does too much. Split it into update-contact and send-email so the agent and the reviewer can approve each step.

• Start with the TypeScript or Python MCP SDK from Anthropic.
• Define each tool with a clear name, description, and JSON Schema input.
• Ship read-only tools first. Add write tools after review processes exist.
• Keep tools atomic. One action per tool, not compound operations.
• Test with Claude Code in a sandbox repo before production rollout.

Business workflows with Claude Code MCP

MCP turns Claude Code from a code editor into a business workflow agent. The most valuable workflows combine two or three MCP servers in a single session.

A support engineering workflow connects GitHub, PostgreSQL, and Slack. A developer asks Claude Code to find the customer's recent error logs in the database, check if a related GitHub issue exists, and post a summary to the support channel. That sequence used to require three browser tabs and fifteen minutes of context-switching.

A weekly reporting workflow connects Google Drive and a database. Claude Code reads the metrics spreadsheet, queries the database for fresh numbers, compares against last week, and drafts a summary. The developer reviews and approves the post.

An onboarding workflow connects GitHub and an internal knowledge base MCP server. New developers ask Claude Code questions about the codebase and it pulls answers from both the repo and internal documentation, reducing the time to first meaningful commit.

• Support triage: database query plus GitHub issue lookup plus Slack summary.
• Weekly reporting: spreadsheet context plus fresh database metrics.
• Developer onboarding: repo code plus internal knowledge base search.
• Incident response: log search plus runbook lookup plus status page draft.

Community MCP servers vs custom builds

The MCP ecosystem includes hundreds of open-source community servers. Before building custom, check the MCP server registry and GitHub for existing implementations. Community servers for PostgreSQL, MySQL, GitHub, Slack, Google Drive, Jira, Linear, and Notion are mature and well-tested.

Custom servers make sense when your system has a proprietary API, when you need fine-grained permission controls that a community server does not support, or when you want to enforce business logic at the server level. A company that needs Claude Code to only query certain database tables should build a thin server that exposes just those tables, rather than giving a generic database server full access.

The tradeoff is maintenance. Community servers get updates from the ecosystem. Custom servers are your team's responsibility. Plan for quarterly reviews and keep the tool surface small so maintenance stays manageable.

• Check the MCP registry before building. Community servers exist for 50+ tools.
• Use community servers for standard tools: databases, Git, chat, cloud platforms.
• Build custom when you need proprietary API access or fine-grained permission control.
• Plan for maintenance: quarterly reviews, version pinning, and dependency updates.