Out of the box, Claude Code can read files, write code, and run terminal commands. That alone is powerful, but it operates within a boundary: your local filesystem and whatever tools are available in your shell. The real world of software development extends far beyond that. Your code lives in GitHub. Your data lives in Postgres. Your team communicates on Slack. Your CI pipeline runs on remote infrastructure. To be truly useful, an AI assistant needs to reach into those systems.
That is exactly what the Model Context Protocol (MCP) enables. MCP is an open standard that lets Claude Code connect to external tools and data sources through lightweight server processes. Instead of building one-off integrations for every service, MCP provides a single, consistent protocol that any tool can implement. The result is an extensible architecture where Claude Code's capabilities grow with every server you connect.
What MCP Actually Is
MCP stands for Model Context Protocol, and it was released by Anthropic as an open specification. At its core, MCP defines a standard way for AI models to discover, invoke, and receive results from external tools. Think of it as a USB port for AI: just as USB provides a universal interface for connecting peripherals to a computer, MCP provides a universal interface for connecting data sources and capabilities to an AI model.
Before MCP, every integration between an AI model and an external service required custom glue code. Want the model to query a database? Write a custom tool. Want it to read from GitHub? Write another custom tool. Each integration had its own schema, its own error handling, and its own authentication flow. MCP replaces that fragmentation with a single protocol that all tools can implement.
MCP turns the question from "how do I build an integration between Claude and my service?" to "how do I expose my service's capabilities through a standard interface?" The difference is profound: one approach scales linearly with effort, the other compounds.
Architecture: How MCP Servers Work
An MCP server is a lightweight process that runs locally on your machine (or on a remote host) and communicates with Claude Code over standard input/output (stdio) or server-sent events (SSE) over HTTP. The server exposes a set of tools, resources, and prompts that Claude Code can discover and use.
The communication flow works like this:
┌──────────────┐ stdio/SSE ┌──────────────┐
│ │ ──────────────► │ │
│ Claude Code │ │ MCP Server │ ──► External API
│ │ ◄────────────── │ │ ──► Database
│ │ JSON-RPC 2.0 │ │ ──► Filesystem
└──────────────┘ └──────────────┘When Claude Code starts, it reads your MCP configuration and launches each configured server as a child process. It then sends an initialize request to each server, which responds with a manifest of its capabilities: the tools it offers, the resources it can provide, and any prompts it supports. From that point forward, Claude Code knows what each server can do and can invoke those tools as part of its reasoning process.
Tools, Resources, and Prompts
MCP servers expose three types of capabilities:
- Tools are actions the model can invoke, like running a database query, creating a GitHub issue, or sending a Slack message. Each tool has a name, a description, and a JSON Schema defining its input parameters.
- Resources are data sources the model can read from, such as file contents, database schemas, or API documentation. Resources provide context that helps the model make better decisions.
- Prompts are predefined prompt templates that the server provides for common tasks. These give users a structured way to invoke complex workflows through the server's domain expertise.
When Claude Code decides it needs to use a tool, it sends a tools/call request with the tool name and arguments. The MCP server executes the operation, and returns the result. Claude Code then incorporates that result into its ongoing reasoning. This happens seamlessly within the conversation: you ask Claude to check the status of a pull request, and it calls the GitHub MCP server's get_pull_request tool behind the scenes.
Available MCP Servers
The MCP ecosystem already includes servers for many of the tools developers use daily. Here is a survey of the most widely used servers:
- Filesystem — Provides controlled access to specific directories on your machine, with read/write capabilities scoped to configured paths. Useful when you want Claude Code to access files outside the current project.
- GitHub — Full integration with the GitHub API: reading repositories, creating and reviewing pull requests, managing issues, searching code, and browsing commit history.
- PostgreSQL — Connects directly to a Postgres database. Claude Code can inspect schemas, run read queries, and analyze query results. Essential for data-driven development tasks.
- SQLite — A lighter-weight database server for local SQLite files. Useful for prototyping, testing, and working with embedded databases.
- Puppeteer — Browser automation through Puppeteer. Claude Code can navigate web pages, take screenshots, interact with elements, and scrape content. Powerful for testing and web-related tasks.
- Slack — Read and send messages in Slack channels, search conversation history, and interact with threads. Useful for pulling context from team discussions.
- Memory — A persistent knowledge graph that Claude Code can write to and read from across sessions. It stores entities, relationships, and observations, giving the model a form of long-term memory.
- Fetch — Makes HTTP requests to any URL and returns the response content. A general-purpose server for interacting with REST APIs and web content.
The list grows regularly as the open-source community builds servers for additional services. Sentry, Linear, Google Drive, Notion, Docker, and many more have community-maintained MCP servers available.
Configuring MCP in Claude Code
MCP servers are configured through JSON settings files. Claude Code supports configuration at three levels: project-level (in .mcp.json at your project root), user-level (in ~/.claude/settings.json), and through the /mcp slash command within a session.
Here is a typical project-level .mcp.json configuration that connects Claude Code to a GitHub server and a local Postgres database:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxx"
}
},
"postgres": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost:5432/myapp_dev"
]
},
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/you/Documents/specs",
"/Users/you/Documents/designs"
]
}
}
}Each server entry specifies a command to launch the server process and args to pass to it. The optional env object sets environment variables for the server process, which is how you pass API tokens and other credentials without hardcoding them into arguments.
Once configured, restart Claude Code or use /mcp to reload the configuration. Claude Code will launch the servers and discover their tools. You can verify the connection by asking Claude what tools are available, and it will list every tool from every connected MCP server.
Building a Custom MCP Server
The real power of MCP emerges when you build servers tailored to your organization's internal tools. If your team has a deployment API, a feature flag service, or an internal documentation system, you can expose those capabilities to Claude Code through a custom MCP server.
The official MCP SDK is available for TypeScript and Python. Here is a minimal TypeScript server that exposes a single tool for checking the status of a deployment:
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
const server = new McpServer({
name: "deploy-status",
version: "1.0.0",
});
server.tool(
"check_deployment",
"Check the current deployment status for a service",
{
service: z.string().describe("The service name to check"),
environment: z.enum(["staging", "production"]).describe("Target env"),
},
async ({ service, environment }) => {
const response = await fetch(
`https://deploy.internal.co/api/status/${environment}/${service}`
);
const data = await response.json();
return {
content: [
{
type: "text",
text: JSON.stringify(data, null, 2),
},
],
};
}
);
const transport = new StdioServerTransport();
await server.connect(transport);This server defines one tool called check_deployment. It uses Zod schemas to define the input parameters, which the SDK automatically converts to JSON Schema for Claude Code's discovery process. When Claude Code calls this tool, the server makes an HTTP request to your internal deployment API and returns the result.
To register this custom server, add it to your MCP configuration:
{
"mcpServers": {
"deploy-status": {
"command": "node",
"args": ["./tools/deploy-status-server.js"]
}
}
}Now Claude Code can check deployment status as naturally as it reads files. You might say "check if the payments service is healthy in production" and Claude will invoke your custom tool, interpret the response, and give you a clear summary.
Real-World Integration Patterns
Once you start thinking about MCP as a bridge between Claude Code and your infrastructure, several powerful patterns emerge.
CI/CD Pipeline Integration
Connect a custom MCP server to your CI/CD system and Claude Code can check build statuses, read test failure logs, trigger deployments, and monitor rollout progress. When a test fails in CI, you can ask Claude to pull the failure log, diagnose the issue, and suggest a fix, all without leaving your terminal.
Database-Assisted Development
With the Postgres or SQLite MCP server, Claude Code can inspect your database schema, run exploratory queries, and understand the shape of your production data. This is transformative for tasks like writing migrations, optimizing queries, or debugging data-related issues. Instead of manually running queries and pasting results into the conversation, Claude pulls the information it needs directly.
Documentation and Knowledge Bases
Build an MCP server that indexes your team's internal documentation, architecture decision records, or API specifications. Claude Code can then reference this documentation when writing code, ensuring that its output aligns with your team's conventions and architectural decisions.
The most productive MCP setups are not the ones with the most servers connected. They are the ones that connect the specific systems where context loss causes the most friction in your workflow.
Security Considerations
MCP servers are powerful precisely because they have access to external systems. That power demands careful attention to security.
Principle of Least Privilege
Every MCP server should have the minimum permissions necessary. If Claude Code only needs to read from your database, use a read-only database user. If the GitHub server only needs to view repositories, use a token scoped to repo:read. Avoid giving MCP servers broad administrative tokens just because it is easier to configure.
Token Management
Never commit API tokens or credentials in your .mcp.json file if it lives in a shared repository. Instead, use environment variables referenced from your shell profile, or use a secrets manager. Many teams keep a .mcp.json.example file in their repository with placeholder values and add the real .mcp.json to .gitignore.
Approval Prompts
Claude Code asks for your approval before executing MCP tool calls that have side effects. A read-only database query might execute automatically, but creating a GitHub issue or sending a Slack message will prompt you for confirmation. This human-in-the-loop design ensures that you remain in control of actions that affect external systems.
Network Boundaries
MCP servers run as local processes, which means they have access to whatever network your machine can reach, including internal services behind your VPN. Be deliberate about which servers you enable and what network resources they can access. A compromised or misconfigured server could theoretically exfiltrate data to an external endpoint.
The Future of Tool-Connected AI
MCP is still in its early stages, but the trajectory is clear. As the protocol matures and the ecosystem of available servers grows, the boundary between what an AI assistant knows and what it can do will continue to blur. Today, connecting Claude Code to a database requires configuring an MCP server. Tomorrow, that server might auto-configure itself based on the database connection string in your project's environment file.
The deeper implication is architectural. MCP enables a world where AI assistants are not isolated text generators but active participants in your development infrastructure. They can monitor, query, create, and deploy across the full surface area of your toolchain. The developers and teams that learn to build and configure these connections effectively will have a meaningful advantage: their AI assistant understands not just the code, but the entire ecosystem in which that code operates.
In the next article, Autonomous AI Agents, we will explore what happens when you take these tool-connected capabilities and give the AI more autonomy to plan, execute, and iterate on complex tasks without constant human guidance. MCP is the foundation that makes that autonomy possible.