Claude Code Integrations: MCP Servers, IDE Setup, and CI/CD

Claude Code is powerful on its own. It reads your files, writes code, runs commands. But right now, every time you need it to know something outside your project — a database schema, a GitHub issue, a Sentry error — you're copy-pasting. You're the middleman.

What if Claude could just... go get that information itself?

That's what MCP servers do. Only 8% of setups in our analysis configure them, but those that do score 7.5/10 on average. The reason is simple: MCP servers eliminate the copy-paste tax that eats most of a session's time.

Let's set one up right now. You'll have it working in under five minutes.

Your first MCP server: GitHub

MCP stands for Model Context Protocol. It's an open standard that lets Claude talk to external services through a structured interface. An MCP server is a small program that runs in the background and gives Claude access to tools — like searching issues, querying databases, or reading documentation.

Let's start with the GitHub MCP server because the setup is dead simple and the payoff is immediate.

Add this to your .claude/settings.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

You'll need a GitHub Personal Access Token. Go to GitHub > Settings > Developer Settings > Personal access tokens > Generate new token. Give it repo scope.

Now restart Claude Code and try this:

> List my 5 most recent pull requests

Claude doesn't ask you to paste anything. It calls the GitHub MCP server, fetches your PRs, and shows them. Now try:

> What's the status of issue #42? Read the comments too.

Claude pulls the issue, reads the discussion, and has the full context. When you say "work on issue #42," it actually knows what issue #42 says — without you copying the description into the chat.

That's the whole point of MCP: Claude gets the context itself instead of you being the courier.

The database MCP server (the one that changes everything)

If you use PostgreSQL, this is the MCP server that'll make you wonder how you worked without it.

Add to .claude/settings.json:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://dev:dev@localhost:5432/myapp_dev"
      }
    }
  }
}

What this unlocks:

• Claude reads your actual table schemas before writing queries — no more guessing column names
• It can run SELECT queries to understand data shapes
• Migration generation becomes accurate because Claude sees the real current schema
• Column name mismatches get caught before you run the code

Important: Use a read-only database user. Claude doesn't need write access to understand your schema:

CREATE USER claude_readonly WITH PASSWORD 'secure_password';
GRANT CONNECT ON DATABASE myapp_dev TO claude_readonly;
GRANT USAGE ON SCHEMA public TO claude_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly;

Try it. Ask Claude: "Show me the schema for the users table." It queries the database directly and gives you the exact columns, types, and constraints. No more "I'll assume the schema looks like this."

More MCP servers worth setting up

Once you've got the hang of it, here are the other servers that earn their spot:

Slack — search team conversations

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-your-bot-token"
      }
    }
  }
}

Working on a feature that was discussed in Slack last week? Instead of you summarizing the conversation, Claude searches for it directly.

Sentry — pull error reports

{
  "mcpServers": {
    "sentry": {
      "command": "npx",
      "args": ["-y", "@sentry/mcp-server"],
      "env": {
        "SENTRY_AUTH_TOKEN": "your_sentry_token",
        "SENTRY_ORG": "your-org",
        "SENTRY_PROJECT": "your-project"
      }
    }
  }
}

Debugging a production error? Claude pulls the exact stack trace, affected user count, and error frequency from Sentry. No more screenshotting error reports and pasting them into the chat.

Context7 — live documentation

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@context7/mcp-server"]
    }
  }
}

This one is sneaky useful. Instead of relying on training data (which might be outdated), Claude fetches the current docs for the exact library version you're using. Particularly handy for fast-moving libraries like Next.js, React, or Prisma where the API changes between versions.

Filesystem — access files outside your project

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y", "@modelcontextprotocol/server-filesystem",
        "/Users/you/projects/shared-libs",
        "/Users/you/projects/design-system"
      ]
    }
  }
}

Working in a monorepo? Need Claude to reference your design system while editing a feature? The filesystem server gives it access to directories outside the current project.

IDE integration: meet Claude where you code

VS Code

The fastest way to get started:

1. Install the Claude Code extension from the VS Code marketplace
2. Open your project
3. Press Cmd+Shift+P (Mac) or Ctrl+Shift+P (Windows/Linux) and type "Claude"
4. Select "Claude Code: Open Panel"

The VS Code extension gives Claude access to your open files, terminal output, TypeScript errors, ESLint warnings — all without you copy-pasting anything.

JetBrains (IntelliJ, WebStorm, PyCharm)

Open the built-in terminal in your JetBrains IDE and run claude. It works in the terminal pane with full access to your project. The JetBrains plugin (currently in beta) adds inline suggestions and a chat panel inside the IDE.

Terminal with tmux

If you live in the terminal, this pattern works well — Claude in one pane, your editor in another:

tmux new-session -d -s dev
tmux split-window -h
tmux send-keys -t dev:0.1 'claude' Enter
tmux attach -t dev

You code on the left, Claude runs on the right. Same project directory, zero context switching.

CI/CD: Claude reviews every PR automatically

This is where Claude Code goes from personal tool to team infrastructure.

Automated PR review with GitHub Actions

Create .github/workflows/claude-review.yml:

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Claude Code Review
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Review this pull request. Check for:
            1. Security issues (SQL injection, XSS, exposed secrets)
            2. Performance problems (N+1 queries, missing indexes)
            3. Missing error handling
            4. Test coverage gaps

            Post your review as a PR comment with CRITICAL and INFORMATIONAL sections.

Every PR gets a thorough review before a human even looks at it. The mechanical issues get caught automatically, so your human reviewers can focus on architecture and design decisions.

Automated issue triage

name: Issue Triage
on:
  issues:
    types: [opened]

jobs:
  triage:
    runs-on: ubuntu-latest
    permissions:
      issues: write
    steps:
      - uses: actions/checkout@v4

      - name: Triage Issue
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Analyze this GitHub issue. Based on the codebase:
            1. Identify which files are likely affected
            2. Estimate complexity (trivial / moderate / complex)
            3. Suggest relevant labels
            4. If it's a bug, try to identify the root cause

            Post your analysis as a comment.

New issues get analyzed automatically — affected files identified, complexity estimated, labels suggested. Your team spends less time triaging and more time building.

Headless mode for scripting

Claude Code can run non-interactively for custom automation:

# Run a single prompt and exit
claude -p "Run the test suite and report any failures" --output-format json

# Pipe input
echo "Explain the architecture of this project" | claude -p --output-format text

# Use in a script
RESULT=$(claude -p "Check for TODO comments in src/" --output-format json)
echo "$RESULT" | jq '.output'

This is the building block for custom CI/CD steps, pre-commit hooks, and any workflow where you want Claude to do a specific job and report back.

Keep your tokens safe

MCP servers run with your credentials. Treat them seriously.

Never commit tokens to settings.json. Use environment variable references instead:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Use read-only credentials wherever possible. Claude rarely needs write access to your database or GitHub.

Scope to what you need. Don't connect a production database — use dev or staging.

Review MCP server code. These are npm packages running with your credentials. Check the source, prefer official packages, and pin versions.

The complete setup

Here's a full .claude/settings.json for a well-integrated project — permissions, MCP servers, and hooks working together:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git *)",
      "Read",
      "Glob",
      "Grep"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)"
    ]
  },
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "${DEV_DATABASE_URL}"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "@context7/mcp-server"]
    }
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": ".claude/hooks/pre-tool-guard.sh"
      }
    ]
  }
}

Database schema access, GitHub issues and PRs, live documentation, safety guards, and sensible permissions. That's a connected development environment, not an isolated chatbot.

What's next

With integrations in place, Claude Code stops being a tool you paste context into and starts being a tool that gets its own context. The next steps:

• Workflow patterns — subagents, code review orchestration, and the debugging strategies that power users rely on
• Cost optimization — MCP servers add token usage, so these strategies keep your bill in check
• Score your setup to see how your integrations compare to the top configurations

Frequently Asked Questions

How many MCP servers can I run at once?

There's no hard limit, but each server is a separate process using memory and CPU. In practice, 3-5 is the sweet spot. Beyond that, startup time increases and Claude's context gets crowded with tool descriptions. Start with the servers that save you the most copy-pasting — typically database and GitHub.

Do MCP servers work with the Max plan, or only API?

Both. MCP servers run locally on your machine regardless of billing model. The only cost difference: MCP tool calls generate additional tokens (tool descriptions, inputs, outputs), which matters more on per-token API pricing than on the flat Max plan.

Can I write my own MCP server?

Yes, and it's more straightforward than you'd expect. An MCP server communicates over stdio using JSON-RPC. The @modelcontextprotocol/sdk package provides TypeScript helpers:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server({ name: "my-server", version: "1.0.0" });

server.setRequestHandler("tools/list", async () => ({
  tools: [{ name: "my_tool", description: "Does something useful", inputSchema: { type: "object" } }]
}));

const transport = new StdioServerTransport();
await server.connect(transport);

SDKs also exist for Python, Go, and Rust.

Is the GitHub Actions integration safe?

The official anthropics/claude-code-action runs in a sandboxed CI environment. It can only access what you grant through GitHub Actions permissions (contents: read, pull-requests: write). Store your Anthropic API key as a GitHub secret, never hardcoded. The main risk is cost — a runaway action on a busy repo can generate large API charges. Set spend alerts and limit which events trigger the action.

Why use MCP instead of just telling Claude to run shell commands?

Shell commands work, but they're brittle. With a PostgreSQL MCP server, Claude calls query("SELECT * FROM users LIMIT 5") — it doesn't need to figure out your psql connection string, handle authentication, or parse tabular output. MCP gives Claude typed, structured access to your tools. Fewer errors, more reliable results, and you can grant database read access without granting full shell access.