Connect Claude Code to MCP Servers

When builders first start using Claude Code, the most common frustration I hear sounds like this: "Claude is great at writing code in my files, but my real work lives in Postgres, GitHub issues, and Jira. Am I supposed to copy and paste query outputs into my terminal all day?"

The answer is no. Copying data back and forth turns you into a manual transport layer between your model and your infrastructure. That is where the Model Context Protocol (MCP) changes the operating equation. MCP provides an open standard that allows Claude Code to discover and execute external tools provided by outside servers.

Instead of hard-coding brittle API calls into prompts, an MCP server runs as a separate process or network service. It advertises its available tools and schemas, and Claude invokes them on demand. When combined with custom skills, MCP lets you build automated workflows that query real production databases, verify state, and take action without manual intervention.

What MCP actually provides in practice

Vendor documentation frequently explains MCP in abstract architecture diagrams. Here is the operational reality: MCP gives your terminal session three specific capabilities:

• Tool execution: Exposes functions like database queries, issue creation, or web scraping that Claude can call with structured JSON arguments.
• Resource access: Allows Claude to read file-like data streams such as server logs, schema dumps, or live metrics.
• Credential isolation: Database passwords and API tokens stay inside the server configuration on your machine. They are never pasted into conversational prompts or leaked into model training context.

Adding an SQLite or Postgres server with the CLI

Claude Code manages MCP servers using the `claude mcp` CLI command family. You do not need to edit raw JSON configuration files by hand unless you prefer to.

Notice the double dash (`--`) in the command above. Everything before the double dash configures Claude Code. Everything after the double dash is the exact command and argument string used to spawn the server process.

Choosing between stdio and HTTP transports

In my experience testing both transports across client workflows, builders often get stuck deciding between stdio and HTTP. Here is how to decide based on system architecture:

• stdio (Standard Input/Output): Claude Code launches the server as a local child process and talks to it via standard streams. Use stdio for local SQLite files, filesystem tools, and utilities running directly on your machine.
• HTTP / SSE (Server-Sent Events): Claude Code connects over HTTP to a persistent endpoint. Use HTTP when connecting to remote team services, Docker containers, or internal microservices hosted elsewhere on your network.

Scope hierarchy: project vs user vs local

Where you store a server definition matters for team collaboration and security. Claude Code supports three configuration scopes:

1. project (default): Stored in `.claude/settings.json`. Checked into version control so every teammate cloning the repo gets the same development tools.
2. user: Stored in `~/.claude/settings.json`. Available across every project on your workstation, perfect for personal productivity tools.
3. local: Stored in `.claude/settings.local.json`. Excluded from git, necessary for any server configuration that requires private personal access tokens.

How skills orchestrate MCP tools

The true power of this architecture appears when you combine skills with MCP. A common misconception is that skills and MCP compete with each other. They do not. A skill represents packaged human judgment (the workflow, conventions, and verification steps). MCP represents tool access (the database connection or API client).

Here is a skill that uses our connected SQLite MCP server to investigate customer billing errors:

---
name: audit-customer-discrepancy
description: Use when investigating a customer billing discrepancy or order status error in the development database.
---

# Audit customer discrepancy

When investigating an order issue:
1. Use the sqlite read_query tool to select * from orders where customer_id matches the request.
2. Verify the payment status, line items, and updated_at timestamp.
3. Check src/services/billing.ts to verify if the state matches business rules.
4. Output an incident summary with recommended remediation steps.

Diagnosing common MCP connection failures

When an MCP server fails to respond, run `/mcp` inside your active session. The command opens an inspector showing the status of each server and the exact list of tools received.

If a stdio server hangs or disappears, the most frequent culprit is stdout pollution. Stdio MCP servers communicate strictly using JSON-RPC over stdout. If your server script prints debugging messages (`console.log` in Node or `print()` in Python) to stdout, Claude Code cannot parse the protocol framing and drops the connection. Route all internal logs to stderr.