Module 7: Integrations: Git, SDK, and Remote Control

MCP and Remote Control: external connections

MCP and Remote Control: external connections

Overview

So far, the integrations you've seen connect Claude Code to tools you already know: Git for versioning, the SDK for programmatic access, the headless CLI for automation in scripts. But there's one question we haven't answered: what happens when Claude Code needs to reach something that isn't in your filesystem? A database? An external API? A web search service?

That's what MCP (Model Context Protocol) is for: an open protocol that connects Claude Code to external data sources and tools. Instead of Claude Code only being able to read files and run commands, MCP gives it access to databases, APIs, web services, and any tool that has an MCP server.

This capsule also covers Remote Control and remote access: the ways to run Claude Code remotely, including scheduled agents and headless mode. Together, MCP and the remote capabilities are the far end of the integration spectrum -- where Claude Code stops being a local tool and becomes a node connected to a wider ecosystem.


MCP: Model Context Protocol

What MCP is

MCP (Model Context Protocol) is an open protocol created by Anthropic that standardizes how AI agents connect to external data sources and tools. Think of MCP as "USB-C for AI agents" — a universal interface that lets you plug in any service.

The problem it solves

Without MCP, every integration is custom:

┌──────────────────────────────────────────────────────────────┐
│                         WITHOUT MCP                          │
│                                                              │
│  Claude Code ──── custom script ──── Database                │
│  Claude Code ──── another script ──── GitHub API             │
│  Claude Code ──── shell command ──── Web search              │
│  Claude Code ──── another script ──── Slack                  │
│                                                              │
│  (each integration is different, fragile, hard to maintain)  │
└──────────────────────────────────────────────────────────────┘

With MCP, everything speaks the same protocol:

┌──────────────────────────────────────────────────────────────┐
│                           WITH MCP                           │
│                                                              │
│               ┌── MCP Server: PostgreSQL                     │
│               │                                              │
│  Claude Code ─┼── MCP Server: GitHub                         │
│   (MCP client)│                                              │
│               ├── MCP Server: Web Search                     │
│               │                                              │
│               └── MCP Server: Slack                          │
│                                                              │
│  (one protocol, multiple servers, plug & play)               │
└──────────────────────────────────────────────────────────────┘

Key MCP concepts

ConceptWhat it isExample
MCP ServerA program that exposes tools and dataA PostgreSQL server that allows queries
MCP ClientA program that consumes serversClaude Code is an MCP client
ToolsFunctions the server exposesquery_database, search_web, get_issue
ResourcesData the server can readDB tables, remote files, documents
PromptsPre-configured templates on the server"Analyze this table", "Summarize this issue"

How it works

1. You install/configure an MCP server
2. You register it in Claude Code (settings)
3. Claude Code discovers the server's tools
4. When it needs external data, Claude uses the server's tools
5. The server runs the operation and returns the result
6. Claude Code folds the result into its answer

Popular MCP servers

⚠️ MCP packages evolve: The package names in the MCP ecosystem change frequently. Check the current names in the MCP Server Registry before installing.

Filesystem MCP Server

Enhanced filesystem access with advanced search, batch operations, and change watching.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/directory"]
    }
  }
}

Available tools:

  • read_file: read a file's contents
  • write_file: write files
  • list_directory: list a directory's contents
  • search_files: advanced search by content
  • get_file_info: file metadata

GitHub MCP Server

Access to the GitHub API: issues, PRs, repos, code search.

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

Available tools:

  • search_repositories: search repos
  • get_issue: read an issue
  • create_issue: create issues
  • list_pull_requests: list PRs
  • get_pull_request_diff: read a PR's diff
  • create_pull_request_review: leave a review

PostgreSQL MCP Server

Direct queries against a PostgreSQL database.

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:pass@localhost:5432/mydb"
      }
    }
  }
}

Available tools:

  • query: run SQL queries (SELECT)
  • list_tables: list tables
  • describe_table: a table's schema

Brave Search MCP Server

Real-time web search.

{
  "mcpServers": {
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-brave-search"],
      "env": {
        "BRAVE_API_KEY": "<your-api-key>"
      }
    }
  }
}

Available tools:

  • brave_web_search: search the web
  • brave_local_search: search for local businesses

Memory MCP Server

Persistent knowledge-graph storage for context across sessions.

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

Available tools:

  • create_entities: create knowledge nodes
  • create_relations: create relations between nodes
  • search_nodes: search the knowledge graph
  • read_graph: read the whole graph

Configuring MCP in Claude Code

Where the configuration lives

MCP servers are configured in Claude Code's settings. There are several levels:

LevelFileScope
Project.claude/settings.jsonThis project only
Personal.claude/settings.local.jsonJust you, in this project
Global~/.claude/settings.jsonAll your projects

Example: configuring the GitHub MCP

Step 1: Get a GitHub Personal Access Token with the permissions you need (repo, read:org).

Step 2: Configure it in settings:

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

⚠️ Security: Never put tokens in .claude/settings.json (the team file). Use .claude/settings.local.json (your personal file, which must be in .gitignore) or environment variables.

Step 3: Verify it in Claude Code:

You: What MCP tools do you have available?

Claude Code: I have access to the GitHub MCP server with the 
following tools:
- search_repositories
- get_issue
- create_issue
- list_pull_requests
...

Example: configuring multiple servers

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "${DATABASE_URL}"
      }
    },
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-brave-search"],
      "env": {
        "BRAVE_API_KEY": "${BRAVE_API_KEY}"
      }
    }
  }
}

Checking that an MCP server works

After configuring it, start a new Claude Code session and ask:

You: List the MCP tools you have available and try a query
     against the database.

If the configuration is right, Claude Code will show the server's tools and run the query.


MCP in action: practical examples

Example 1: debugging with a database

You: The user user@example.com reports that they can't see their
     orders. Query the database to figure out what's going on.

Claude Code (using MCP Postgres):
→ query: SELECT * FROM users WHERE email = 'user@example.com'
→ Result: user_id = 42, active = true

→ query: SELECT * FROM orders WHERE user_id = 42
→ Result: 3 orders, but all of them have status = 'draft'

Found the problem. The user has 3 orders, but every one of them 
is in status 'draft'. The orders view probably filters by 
status = 'completed' or 'shipped'. 

The orders never moved past 'draft' — likely a bug in the 
checkout flow that doesn't update the status after payment.

Example 2: analyzing a GitHub issue

You: Look at issue #156 in our repo and propose a fix.

Claude Code (using MCP GitHub):
→ get_issue: owner/repo #156
→ Title: "API returns 500 on empty cart checkout"
→ Description: "When trying to checkout with an empty cart..."

I've read issue #156. The problem is that the POST /checkout 
endpoint doesn't validate whether the cart is empty before processing.

Proposed fix:
1. Add validation in checkout_service.py
2. Return 400 with the message "Cart is empty" 
3. Add a test for this case

Want me to implement it?

Example 3: research with web search

You: I need to implement rate limiting. What's the best library
     for FastAPI in 2026?

Claude Code (using MCP Brave Search):
→ brave_web_search: "FastAPI rate limiting library 2026 best"
→ Results: slowapi, fastapi-limiter, custom middleware...

Based on my search, the main options are:

1. **slowapi** (most popular): built on limits, supports 
   Redis and in-memory. Well maintained.
2. **fastapi-limiter** (simpler): plain decorators, 
   fewer features but lighter.
3. **Custom middleware**: for complex cases where you need 
   total control.

Recommendation: slowapi if you need distributed rate limiting 
(with Redis), fastapi-limiter if it's a simple project.

MCP: an important note

This capsule covers the basic MCP configuration in Claude Code. MCP is a broad topic with a lot of surface:

  • Building your own MCP servers
  • MCP servers for your company's internal APIs
  • Orchestrating multiple MCP servers
  • Advanced security and authentication

Guide #5 in this series (Claude Code & MCP) covers MCP in depth: from building custom servers to multi-server architectures for teams. If MCP interests you, this capsule gives you the foundation; Guide #5 gives you the mastery.


Remote Control and remote access

Where things stand

Remote Control is an evolving capability in Claude Code. The current ways to reach Claude Code remotely include:

Scheduled Agents (Remote Triggers)

Claude Code lets you create scheduled agents that run on cron schedules:

# List scheduled triggers
# They're configured from the interface or the CLI

# Triggers run Claude Code in the cloud
# with no need to keep your machine on

Use cases:

  • Automatic code reviews on PRs
  • Periodic reports on the state of the codebase
  • Automated maintenance (dependencies, cleanup)

Headless mode as "Remote Control"

Headless mode (the -p flag) lets you run Claude Code programmatically, which enables remote control through scripts and APIs:

# Run it from a remote server
claude -p "analyze the last 5 PRs and generate a summary"

# Wire it into a webhook
curl -X POST your-server/api/claude \
  -d '{"prompt": "review the last commit"}'

Important notes

  • The remote capabilities are evolving actively
  • Check the official documentation for the current state: https://code.claude.com/docs/en
  • Some features may require specific plans (Team/Enterprise)

Computer Use in Claude Code (March–April 2026)

Until 2026, Computer Use only lived in Claude Cowork. Now it's in Claude Code too:

Computer Use in Claude Code Desktop (March 2026)

Claude Code Desktop can drive your actual desktop: open native apps, click on UI, verify visual changes. It's off by default and asks for confirmation before every action.

Best for:

  • Apps with no API (legacy proprietary tools)
  • Verifying end-to-end changes that only a GUI can validate (e.g. iOS Simulator onboarding flows)
  • Driving hardware control panels
  • Anything that only exists as a GUI

Turning it on:

Settings → Computer use → Enable
Grant OS permissions (screen capture, input control)

Example of use:

> Open the iOS simulator, tap through the onboarding flow, and take a screenshot of each step

Computer Use in Claude Code CLI (April 2026, research preview)

Also available from the CLI — Claude can open native apps, click on UI, and verify changes from your terminal. Ideal for closing the loop on things only a GUI can confirm.

When to use it: When neither a Connector nor an API solves your case. As a last resort.

When NOT to: Tasks that have an alternative via API, commands, or MCP — always prefer those.


Ultraplan (April 2026, early preview)

Ultraplan is a new way to plan work with Claude Code:

Local CLI  ──▶  Planning in the cloud  ──▶  Web editor
                          │                     │
                          ▼                     ▼
                    Run remotely          Pull it back local

Typical flow:

  1. From the CLI: draft a plan with Claude
  2. The plan goes up to the cloud, which auto-creates a cloud environment
  3. You review and comment in a web editor
  4. You run the plan remotely (the cloud does the work) or pull it back to local

Why it matters: it separates "planning" from "executing". You can plan in 5 minutes from the CLI, review it with a teammate on the web, and run it hours later without keeping your machine on.


Monitor tool (April 2026)

The Monitor tool streams background events into the conversation. Claude can "tail" a process's logs and react live.

Example:

> Run the dev server with npm run dev and monitor it. If an error shows up, fix it.

Claude starts the dev server in the background, the monitor tool streams stdout/stderr to it, and when an error appears in the logs, Claude catches it and acts.

Use cases:

  • Dev servers with hot reload
  • Long build processes
  • Local CI processes
  • Test watchers

Transcript Search (March 2026)

Searching inside a long conversation with Claude Code — finally.

How to use it:

Ctrl+O    # opens transcript mode
/migrate  # searches for "migrate" across the whole transcript
n         # next match
N         # previous match

Useful when you remember Claude ran a command 200 messages ago but you can't remember exactly which one.


PR Auto-fix (March–April 2026)

Two ways to turn on PR auto-fix:

PR Auto-fix in Claude Code Web (March 2026)

When you create a PR from Claude Code on the web, there's an "Auto fix" toggle in the CI panel. Turn it on and Claude:

  1. Watches CI
  2. Fixes failures (lint errors, typing issues, failing tests)
  3. Handles code review nits
  4. Pushes until the PR is green

Who it's for: teams that don't want to babysit PRs through 6 rounds of lint errors.

/autofix-pr from the terminal (April 2026)

Same feature, but from the CLI:

> /autofix-pr

Turns on PR auto-fix from the terminal without opening the web. Claude starts watching the PR and fixes CI failures on its own.


/team-onboarding (April 2026)

Packages up your setup (CLAUDE.md, skills, hooks, settings) into a replayable guide so a new team member can get to your exact setup fast:

> /team-onboarding

It generates a document (with commands and steps) that, followed step by step, reproduces your setup on another machine. Useful for:

  • Onboarding new hires
  • Setting up consistent dev environments across the team
  • Documenting your Claude Code configuration

PowerShell Tool (Windows, March 2026)

A native PowerShell tool for Windows — before, Claude could only run Bash (via Git Bash or WSL). Now it can run native cmdlets, pipe objects, and work with Windows paths without translating them.

Turning it on:

{
  "env": {
    "CLAUDE_CODE_USE_POWERSHELL_TOOL": "1"
  }
}

Comparisons and decisions

MCP vs custom scripts vs SDK

AspectMCP ServerCustom scriptSDK
SetupInstall + configureWrite from scratchInstall a library
MaintenanceThe community maintains itYou maintain itAnthropic maintains it
Integration with ClaudeNative (tools auto-discovered)Manual (prompt + output)Programmatic
ReusableYes (plug & play)No (custom)Yes (functions)
Ideal forStandard services (DB, API)Specific logicComplex automation

When to use which

Do you need to connect to a standard service (DB, API, search)?
├── Yes → Does an MCP server exist for that service?
│   ├── Yes → Use MCP
│   └── No → Custom script, or build your own MCP server
└── No → Is it automation logic?
    ├── Simple → Headless CLI (-p)
    └── Complex → SDK

MCP vs Claude Code's built-in tools

Claude Code already has tools to read files, run commands, and search code. So why do you need MCP?

Claude Code built-inMCP extends it with...
Reads local filesReads remote files, S3, Google Drive
Runs git commandsHits the GitHub API directly
Runs psql via the terminalDirect PostgreSQL queries with schema discovery
Can't search the webReal-time web search
Has no memory across sessionsA persistent knowledge graph

MCP doesn't replace the built-in tools — it complements them with access to resources that aren't on your local filesystem.


Common patterns

Pattern: one MCP server per environment

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

Use settings.local.json to point the server at your development database. Everyone on the team can have their own configuration.

⚠️ Never point an MCP server at production without restrictions. Use read-only accounts for production databases.

Pattern: MCP + CLAUDE.md

Document the available MCP servers in your CLAUDE.md:

# Available MCP servers

## PostgreSQL (db-dev)
- Development database
- Main tables: users, orders, products
- SELECT queries only (read-only)
- Use it for debugging and data analysis

## GitHub (github)
- Repo: company/main-api
- Access: issues, PRs, code search
- Use it to review PRs and manage issues

Pattern: check MCP at the start of a session

# In CLAUDE.md - start-of-session section

At the start of a session:
1. Verify that the MCP servers are available
2. If the PostgreSQL server doesn't respond, tell the user
3. List the available MCP tools if the user needs them

Pitfalls and edge cases

Pitfall 1: tokens in a shared settings.json

{
  "mcpServers": {
    "github": {
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_MySecretToken123"
      }
    }
  }
}

If that lives in .claude/settings.json, the token gets committed to the repo. Anyone with access to the repo has your token.

Fix: Use .claude/settings.local.json (in .gitignore) or environment variables:

{
  "mcpServers": {
    "github": {
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Pitfall 2: an MCP server that modifies data

A database MCP server can run DELETE FROM users. With no restrictions, Claude Code could run destructive queries.

Fix:

  • Use database accounts with read-only permissions
  • Configure the MCP server to accept SELECT queries only
  • Use a development database, never production directly

Pitfall 3: too many MCP servers

Every MCP server adds tools to Claude Code's context. If you have 10 servers with 5 tools each, that's 50 tools competing for Claude's attention.

Fix: Configure only the servers you need for the current project. Use per-project configuration (.claude/settings.json) instead of global.

Pitfall 4: an MCP server that's down

If an MCP server isn't available when Claude Code tries to use it, you'll get an error. Claude Code doesn't always handle those errors gracefully.

Fix: Check that the servers are running before the session. Add a check to CLAUDE.md:

Before using MCP tools, verify that the server responds.
If an MCP server isn't available, continue without it and let me know.

Pitfall 5: remote execution without supervision

When you run Claude Code remotely (headless mode or scheduled agents), there's nobody around to approve permissions interactively.

Fix: Configure broader permissions in allowedTools for remote sessions. Use the --allowedTools flag with headless mode to pre-approve the tools you need. Only high-risk actions should require manual approval.


Complete worked example

A workflow that combines MCP, Git, and headless mode:

Scenario: debugging a bug reported on GitHub
────────────────────────────────────────────

You: Issue #203 reports that users can't update their
     email. Investigate and fix it.

Claude Code:
───────────

# 1. Read the issue (MCP GitHub)
→ get_issue: company/api #203
→ "Users get 500 error when updating email via PATCH /users/me"
→ Steps to reproduce: ...
→ Error log: "UniqueConstraintError on users.email"

# 2. Investigate in the database (MCP PostgreSQL)
→ query: SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1
→ Result: 0 duplicates in the database

→ query: SHOW CREATE TABLE users (or the equivalent)
→ Result: UNIQUE constraint on email, but the code doesn't check 
  before running the UPDATE

# 3. Read the code (built-in tools)
→ Read: src/routes/users.py
→ The PATCH /users/me endpoint runs UPDATE without checking whether 
  the new email already exists in the table

# 4. Implement the fix (built-in tools)
→ Write: src/routes/users.py
→ Adds a check: if the email already exists, return 409 Conflict

→ Write: tests/test_users.py
→ Adds a test for the duplicate email case

# 5. Commit and reference the issue (Git)
→ git add src/routes/users.py tests/test_users.py
→ git commit -m "fix(users): handle duplicate email on update

Check if email already exists before UPDATE. Returns 409
Conflict with clear error message instead of 500.

Fixes #203"

→ gh pr create --title "fix: handle duplicate email on update" \
    --body "Fixes #203. Adds email uniqueness check before UPDATE."

This workflow uses three integrations in a single session: MCP GitHub (to read the issue), MCP PostgreSQL (to investigate the database), and Git (to commit and open the PR).


This module as a bridge

What we covered vs what's next

TopicThis guide (Guide #4)Guide #5 (MCP in depth)
MCP setupConfigure existing serversBuild your own servers
MCP serversUse community serversMulti-server architecture
SecurityBasic tokens and permissionsAdvanced auth, scopes, audit
AdvancedNoCustom tools, resources, prompts

If MCP caught your interest, Guide #5 is your next step after finishing this guide.


Practice exercises

Exercise 1: Basic — Configure the filesystem MCP

Configure the filesystem MCP server to give Claude Code access to a specific directory.

Requirements:

  • Install @modelcontextprotocol/server-filesystem via npx
  • Configure it in .claude/settings.local.json
  • Verify that Claude Code can list files using the MCP server
  • Restrict access to one specific directory
Solution

In .claude/settings.local.json:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/your/project/docs"
      ]
    }
  }
}

Start a new Claude Code session:

You: What MCP tools do you have available? 
     List the files in the docs directory using MCP.

Claude Code should use the list_directory tool from the MCP filesystem server.

Exercise 2: Intermediate — Configure the GitHub MCP

Configure the GitHub MCP server and use it to review a repository's issues.

Requirements:

  • Create a Personal Access Token on GitHub (Settings → Developer settings → Tokens)
  • Configure the MCP server in .claude/settings.local.json
  • Ask Claude Code to list the open issues of a public repo
  • Ask it to analyze one specific issue
Solution

Create a token on GitHub with the repo and read:org permissions.

In .claude/settings.local.json:

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

⚠️ Make sure .claude/settings.local.json is in .gitignore.

You: List the last 5 open issues in the facebook/react repo.

You: Read the most recent issue and propose a possible fix.

Exercise 3: Intermediate — MCP + bug investigation

Simulate a debugging workflow using the GitHub MCP to read an issue and Claude Code to hunt down the bug in the code.

Requirements:

  • Use the GitHub MCP to read an issue from your repository (or a public one)
  • Claude Code analyzes the relevant code using built-in tools
  • Produce a report with: issue description, root cause analysis, proposed fix
Solution
You: Read issue #[number] from [owner/repo] and analyze this
     project's code to find the root cause. Produce a report
     with: issue description, root cause analysis, and the
     proposed fix.

Claude Code uses:

  1. MCP GitHub: get_issue to read the description and comments
  2. Built-in Read/Grep: to find the relevant code
  3. Its own reasoning to connect the issue to the code

The report should include:

  • The issue description (from MCP)
  • The relevant files (from the search)
  • The root cause (analysis)
  • The proposed fix (with code)

Exercise 4: Advanced — Multiple MCP servers

Configure at least two MCP servers and use them in a single Claude Code session.

Requirements:

  • Configure the GitHub MCP and the filesystem MCP (or any combination)
  • In a single session, ask Claude Code to use both servers
  • Example: "Read issue #X from GitHub and check whether there's relevant documentation in docs/"
Solution

In .claude/settings.local.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..."
      }
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./docs"]
    }
  }
}
You: Read issue #42 from [owner/repo] using the GitHub MCP. 
     Then search the docs/ directory for documentation related 
     to the issue's topic. If there isn't any, suggest what 
     documentation to create.

Claude Code should:

  1. Use MCP GitHub to read the issue
  2. Use MCP filesystem to search docs/
  3. Combine both sources in its answer

Exercise 5: Challenge — Document your integrations setup

Write a complete section in your CLAUDE.md documenting every integration in this module.

Requirements:

  • A Git conventions section (conventional commits, branch naming)
  • An available MCP servers section (with a description of each)
  • An automation section (the headless mode scripts you have)
  • A permissions section for integrations (which Git commands are allowed)
Guide

A suggested structure for CLAUDE.md:

# Integrations

## Git Conventions
- Conventional commits: type(scope): description
- Branch naming: feature/*, fix/*, docs/*
- Merge strategy: squash merge into main
- NEVER force push. NEVER push directly to main.

## MCP Servers
### GitHub (github)
- Repo: owner/repo
- Access: issues, PRs, code search
- Use it for: reviewing issues, creating PRs

### Filesystem (docs)
- Directory: ./docs
- Access: read/write
- Use it for: searching and updating documentation

## Automation scripts
- ./scripts/review.sh: code review of changes
- ./scripts/pr-description.sh: generate a PR description
- ./scripts/daily-changelog.sh: daily changelog

## Git permissions
Allowed: git status, git diff, git add, git commit, git log
Require approval: git push, git merge
Forbidden: git push --force, git reset --hard

Check that CLAUDE.md is consistent with your settings.json and the MCP servers you configured.


Summary

What you learned in this capsule:

  • MCP (Model Context Protocol) is an open protocol for connecting Claude Code to external tools and data
  • MCP uses a client-server model: Claude Code is the client, MCP servers expose the tools
  • Popular servers: filesystem, GitHub, PostgreSQL, Brave Search, Memory
  • The configuration lives in settings.json or settings.local.json (tokens in the local one, never in the shared one)
  • Remote Control includes scheduled agents (remote triggers) and headless mode for remote programmatic execution
  • MCP complements the built-in tools — it doesn't replace them
  • Security: use read-only accounts for DBs, keep tokens in settings.local.json, limit MCP servers to the ones you need
  • This guide covers basic MCP — Guide #5 covers MCP in depth (building servers, architecture, advanced security)

Summary of the whole module

You've finished Module 7: Integrations. Here's what you can now do:

CapsuleWhat you learned
01 — IntroductionMental model: Claude Code as an integration hub
02 — Git workflowsSemantic commits, branches, PRs, code review, merge conflicts
03 — Python/TS SDKquery(), batch processing, automated code review, test generation
04 — Headless CLIThe -p flag, output formats, Unix piping, automation scripts
05 — MCP + RemoteMCP servers, configuration, remote access via scheduled agents and headless mode

Your Claude Code is no longer an island. It's connected to Git for versioning, reachable programmatically via the SDK, automatable with the headless CLI, and extensible with MCP for external data. It's an integrated component of your development stack.

Next module: 08 - Capstone project — you'll build your first complete CLI application with Claude Code, applying everything you've learned: CLAUDE.md, skills, hooks, subagents, Git workflows, and (optionally) the SDK or headless mode.


Additional resources

Official documentation

Community MCP servers

Complementary