Claude Code Extensions Guide

Why extend Claude Code?

Out of the box, Claude Code reads files, writes code, runs shell commands, and searches your codebase. That covers most coding tasks. But the moment you need to query a database, call an API, manage cloud resources, or interact with external platforms, you hit the boundary of what vanilla Claude Code can do.

Extensions push that boundary. Claude Code supports four extension mechanisms - MCP servers, custom commands, hooks, and skills - and each solves a different problem. MCP servers connect Claude to external tools and services. Commands automate multi-step workflows. Hooks enforce rules at lifecycle events. Skills provide domain knowledge on demand.

This guide covers all four, with practical setup examples you can copy and adapt.

MCP servers - connecting external tools

MCP (Model Context Protocol) is the primary way to give Claude Code access to external services. An MCP server is a lightweight process that exposes tools to Claude through a standardized protocol. When you configure an MCP server, its tools appear alongside Claude Code's built-in tools - Claude can call them just like it calls Read or Bash.

How MCP servers work

An MCP server runs as a local process (usually via npx or a direct command) that communicates with Claude Code over standard I/O. You register servers in your project's .mcp.json file, and Claude Code starts them automatically when needed.

Each server exposes a set of tools with defined inputs and outputs. Claude sees these tools in its available tool list and can invoke them based on your instructions or its own judgment about what's needed.

Setting up your first MCP server

Create a .mcp.json file in your project root:

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

That's it. Next time you start Claude Code in this project, it will launch the memory server and expose its tools. You can verify by asking Claude "what MCP tools are available?"

Essential MCP servers for developers

Here are the MCP servers that provide the most value for typical development workflows:

Database access - Connect Claude directly to your database. Instead of writing one-off query scripts, Claude can inspect schema, run queries, and analyze results in real time.

{
  "mcpServers": {
    "turso": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-turso"],
      "env": {
        "TURSO_DATABASE_URL": "libsql://your-db.turso.io",
        "TURSO_AUTH_TOKEN": "your-token"
      }
    }
  }
}

Browser automation - Playwright MCP lets Claude control a browser for testing, scraping, or debugging UI issues.

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

Web search - Give Claude the ability to search the web for documentation, solutions, or current information.

{
  "mcpServers": {
    "exa": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-exa"],
      "env": {
        "EXA_API_KEY": "your-key"
      }
    }
  }
}

GitHub - Read issues, create PRs, review code, and manage repositories without leaving the terminal.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-github"],
      "env": {
        "GITHUB_TOKEN": "your-pat"
      }
    }
  }
}

For a comprehensive list of available MCP servers and detailed configuration, see our MCP servers guide.

Managing MCP server context

Each enabled MCP server adds tool definitions to Claude's context window. If you have 15 servers configured but only use 3 regularly, the other 12 are consuming context tokens every session for tools you never call.

Disable unused servers to reclaim context:

claude mcp disable server-name

Re-enable when needed:

claude mcp enable server-name

A token optimizer MCP server can also help by lazy-loading tool definitions only when they're actually invoked, rather than loading all of them at startup.

Custom commands - workflow automation

Commands are markdown files that define reusable workflows. They're the simplest extension type and often the most impactful.

Anatomy of a command

A command file at .claude/commands/deploy.md becomes the /deploy command:

---
description: Build, test, and deploy to production
allowed-tools:
  - Bash(npm:*)
  - Bash(git:*)
  - Read
---

Deploy the current branch to production:

1. Run `npm run build` - verify it compiles cleanly
2. Run `npm test` - all tests must pass
3. Run `git push origin main` - push to trigger deploy
4. Verify the deployment succeeded by checking the build output

If any step fails, stop and report the error. Do not proceed with deployment if tests fail.

The frontmatter controls what tools the command can access. The body is the prompt Claude follows. This is a security boundary - a review command that only has Read access cannot accidentally modify files.

Command levels

Commands can live in three places:

Location	Scope	Use case
.claude/commands/	Project-level, shared via git	Team workflows (deploy, test, review)
~/.claude/commands/	User-level, all projects	Personal shortcuts (standup, notes)
MCP servers	Server-provided	Tools that ship with integrations

Commands with arguments

Use $ARGUMENTS to pass input to a command:

---
description: Investigate a bug report
argument-hint: "[issue description]"
---

Investigate this bug: $ARGUMENTS

1. Search the codebase for related code
2. Check recent git commits for relevant changes
3. Identify the likely root cause
4. Suggest a fix with code changes

Now /investigate login fails when email has a plus sign passes the description directly into the prompt.

For a complete guide to building command libraries, see our commands guide.

Hooks - automated guardrails

Hooks are shell scripts that run automatically at specific lifecycle events. Unlike commands (which you invoke manually), hooks fire on their own whenever their trigger condition is met.

Hook lifecycle events

Event	When it fires	Common use
PreToolUse	Before Claude uses any tool	Block dangerous operations, validate inputs
PostToolUse	After a tool completes	Log changes, verify outputs
SessionStart	When a new session begins	Load context, reset state
Stop	When Claude finishes a turn	Log activity, quality scoring
PreCompact	Before context compaction	Save state before context is compressed

Setting up a hook

Hooks are defined in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "bash .claude/hooks/validate-write.sh \"$TOOL_INPUT\""
      }
    ],
    "Stop": [
      {
        "matcher": "",
        "command": "bash .claude/hooks/log-turn.sh"
      }
    ]
  }
}

The matcher field filters which tools or events trigger the hook. An empty matcher means the hook fires on every event of that type.

Practical hook examples

Block credential file access:

#!/bin/bash
# .claude/hooks/block-secrets.sh
INPUT="$1"
if echo "$INPUT" | grep -qE '\.(env|key|pem|credentials)'; then
  echo "BLOCKED: Cannot access credential files"
  exit 1
fi

Log every file modification:

#!/bin/bash
# .claude/hooks/log-changes.sh
echo "$(date +%H:%M:%S) | Modified: $TOOL_INPUT" >> .claude/logs/changes.log

Validate JSON before writing settings:

#!/bin/bash
# .claude/hooks/validate-json.sh
if echo "$1" | grep -q "settings.json"; then
  echo "$2" | python3 -m json.tool > /dev/null 2>&1 || {
    echo "BLOCKED: Invalid JSON would break settings"
    exit 1
  }
fi

For advanced hook patterns including quality gates and completeness checks, see our hooks guide.

Skills - domain knowledge on demand

Skills are knowledge files that Claude loads when relevant. They contain facts, patterns, rules, and reference material - not procedures (that's what commands are for).

How skills work

A skill file at .claude/skills/database/SKILL.md contains everything Claude needs to know about your database layer:

# Database Skill

## Schema
- Users table: id, email, name, created_at, plan_tier
- Projects table: id, user_id, name, slug, created_at
- Deployments table: id, project_id, status, started_at, completed_at

## Conventions
- All timestamps are UTC
- Soft deletes use deleted_at column (never hard delete)
- Foreign keys use {table}_id naming
- Indexes on all foreign keys and commonly queried columns

## Known Quirks
- The users.email column has a unique constraint but legacy data has duplicates
- Deployments.status enum: pending, building, deploying, live, failed, rolled_back

Claude reads this file when working on database-related tasks, giving it instant knowledge about your schema, conventions, and edge cases without you explaining them every time.

Organizing skills

A typical skills directory:

.claude/skills/
  database/SKILL.md
  deployment/SKILL.md
  testing/SKILL.md
  api/SKILL.md
  client-acme/SKILL.md

Keep each skill focused on one domain. A 50-line skill file that Claude reads in full is more useful than a 500-line file where most content is irrelevant to the current task.

For detailed patterns on building effective skills, see our skills guide.

Third-party integrations

Beyond the four built-in extension types, Claude Code integrates with external tools through its Bash tool and MCP servers.

CI/CD integration

Claude Code can be embedded in CI/CD pipelines for automated code review, test generation, or deployment verification. This requires API billing (not a subscription) since automated usage is outside subscription terms.

# GitHub Actions example
- name: Claude Code Review
  run: |
    echo "Review the changes in this PR for security issues and code quality" | \
    claude --api-key $ANTHROPIC_API_KEY --print

IDE integration

Claude Code runs in any terminal, which means it works alongside any IDE. The recommended pattern is a split terminal setup - your IDE on one side, Claude Code on the other. Claude reads and edits the same files your IDE has open, and changes appear in real time.

VS Code users can also use the integrated terminal, giving Claude Code direct access to the workspace without switching windows.

Notification and messaging integrations

MCP servers exist for email (AgentMail), Slack, and other messaging platforms. These let Claude send reports, alerts, or summaries directly to stakeholders without manual intervention.

{
  "mcpServers": {
    "agentmail": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-agentmail"],
      "env": {
        "AGENTMAIL_API_KEY": "your-key"
      }
    }
  }
}

Building your extension stack

Start minimal. The most common mistake with extensions is configuring everything at once and ending up with a bloated context window and tools you never use.

Week 1: Foundation

• Write your CLAUDE.md
• Create 2-3 essential commands (/start, /review, /deploy)
• Add one MCP server for your most-used external service

Week 2: Guardrails

• Add a PreToolUse hook to block credential access
• Add a Stop hook for activity logging
• Create a /safe-clear command for context management

Week 3: Knowledge

• Write skills for your most complex domains (database, deployment, API)
• Add MCP servers for services you access weekly
• Build commands for workflows you repeat

Ongoing

• Convert repeated manual instructions into commands
• Promote agent corrections into knowledge base rules
• Disable MCP servers you haven't used in a week
• Review hook logs for patterns

FAQ

How many MCP servers can I run at once?

There is no hard limit, but each server adds tool definitions to your context window. Practically, 5-8 active servers is a good range. Beyond that, you start losing meaningful context to tool definitions that may never get called. Use the disable/enable commands to rotate servers based on what you're working on.

Do extensions slow down Claude Code?

MCP servers add a small startup delay (typically under 2 seconds each) when Claude Code launches. During operation, tool calls to MCP servers add network latency if the server talks to external APIs. Hooks run as shell scripts and add milliseconds. Commands and skills are just file reads - no performance impact. The bigger concern is context consumption, not speed.

Can I share extensions across a team?

Yes. Project-level commands (.claude/commands/), hooks (.claude/settings.json), and skills (.claude/skills/) live in your project directory and can be committed to git. MCP server configuration in .mcp.json can also be shared, though API keys should be injected via environment variables rather than committed. User-level commands at ~/.claude/commands/ are personal and don't sync.

---

Extensions are what turn Claude Code from a coding assistant into a development platform. MCP servers connect it to your infrastructure. Commands encode your workflows. Hooks enforce your standards. Skills give it your domain knowledge. Together, they create a system that knows your project deeply and operates within the boundaries you set.

Want all of this pre-built? Claudify ships with 21 production commands, 1,727 skills across 31 categories, 9 specialist agents, hooks, and a complete extension stack. One install: npx create-claudify.