Chapter 17: Plugins and the Marketplace

Learning Objectives

By the end of this chapter, you will be able to:

Understand what plugins are and how they package Claude Code configurations
Find and install community MCP servers and plugins
Create a basic plugin with commands, hooks, and templates
Evaluate plugins for quality and security before installing
Share your own configurations with your team

Quick Start: Install a Community MCP Server (5-10 minutes)

The fastest way to extend Claude Code is to install a community MCP server. Let’s add the GitHub MCP server, which lets Claude interact with GitHub issues, PRs, and repositories directly.

Step 1: Add the GitHub MCP server to your project

Edit .claude/settings.json (create the file if it does not exist):

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

Step 2: Generate a GitHub personal access token

Go to GitHub > Settings > Developer settings > Personal access tokens > Tokens (classic). Generate a token with repo scope. Replace <your-token-here> with the actual token.

Step 3: Restart Claude Code and test it

You: "List my open PRs on this repository"

Claude: [Using MCP Tool: github.list_pull_requests]
You have 3 open PRs:
1. #142 - Add rate limiting middleware (ready for review)
2. #139 - Fix timezone bug in audit logs (changes requested)
3. #135 - Update dependencies (draft)

What just happened? You installed an MCP server that gives Claude Code direct access to GitHub’s API. Claude can now read issues, create PRs, check CI status, and more – all without you leaving the terminal. This is the simplest form of extending Claude Code: adding a community MCP server.

Try This Now: Install the filesystem MCP server instead (or in addition). It uses @modelcontextprotocol/server-filesystem and gives Claude controlled access to directories you specify. Add it to your settings and ask Claude to summarize your project structure.

Core Concepts (15-20 minutes)

17.1 What Are Plugins?

Throughout this book, you have built individual configurations: slash commands (Chapter 14), hooks (Chapter 15), and MCP servers (Chapter 15). A plugin bundles these into a single, shareable package.

Think of it this way:

Individual configuration: A single recipe (one command, one hook)
Plugin: A complete cookbook (commands + hooks + templates + MCP configs that work together)

A typical plugin structure:

my-plugin/
├── commands/            # Slash commands
│   ├── review.md
│   └── deploy.md
├── templates/           # CLAUDE.md templates
│   └── CLAUDE.md
├── README.md            # Documentation
└── plugin.json          # Metadata

When to create a plugin:

You have set up the same commands/hooks on 3 or more projects
New team members spend time manually configuring their environment
You need consistent workflows across multiple repositories

When a plugin is overkill:

You only need it for one project (just use local .claude/ config)
The configuration is still changing daily
It is a single command that can live in .claude/commands/

17.2 Finding and Installing Community MCP Servers

The MCP ecosystem is where most of the practical “plugin” value lives today. Community MCP servers let Claude Code talk to external services: databases, APIs, cloud providers, and development tools.

Where to find MCP servers:

Official MCP server list: The modelcontextprotocol GitHub organization publishes reference servers for common integrations (GitHub, filesystem, PostgreSQL, Slack, and others).
Community repositories: Search GitHub for mcp-server-* to find community-built servers for specific tools.
Your team: Internal MCP servers that wrap company-specific APIs.

How to install any MCP server:

All MCP servers follow the same pattern in .claude/settings.json:

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "package-name"],
      "env": {
        "API_KEY": "your-key"
      }
    }
  }
}

For Python-based servers, use uvx or python -m instead of npx.

Five MCP Servers Worth Knowing:

Server	Package	What It Does
GitHub	`@modelcontextprotocol/server-github`	PRs, issues, repos, code search
Filesystem	`@modelcontextprotocol/server-filesystem`	Controlled file access outside project
PostgreSQL	`@modelcontextprotocol/server-postgres`	Query databases, inspect schemas
Brave Search	`@modelcontextprotocol/server-brave-search`	Web search from Claude Code
Memory	`@modelcontextprotocol/server-memory`	Persistent knowledge graph across sessions

Evaluating an MCP server before installing:

Check the source. Is it from a known organization or individual? Read the code.
Check permissions. What environment variables does it need? An MCP server that asks for broad API keys deserves scrutiny.
Check activity. When was the last commit? Are issues being addressed?
Test in development first. Never install an untested MCP server in a production workflow.

17.3 Creating a Basic Plugin

Let’s build a Code Review Plugin that packages a review command, a pre-commit hook, and a CLAUDE.md template into a shareable unit.

Step 1: Create the directory structure

mkdir -p code-review-plugin/commands
mkdir -p code-review-plugin/templates

Step 2: Create the review command (commands/review.md):

# Code Review

Review the staged or changed files for quality issues.

## Instructions

1. Check for functions longer than 50 lines
2. Look for missing error handling in async/await code
3. Identify hardcoded values that should be configuration
4. Flag any console.log statements left in production code
5. Check for missing TypeScript types (any usage)

## Output Format

Report findings as:
- **Critical** (must fix before merge)
- **Warning** (should fix, but not blocking)
- **Suggestion** (nice to have)

Step 3: Create the CLAUDE.md template (templates/CLAUDE.md):

# Code Review Standards

When reviewing code in this project:
- Functions must be under 50 lines
- All async code must have error handling
- No console.log in production code
- TypeScript: avoid `any` type
- All API endpoints must validate input

Step 4: Create plugin.json:

{
  "name": "code-review-plugin",
  "version": "1.0.0",
  "description": "Automated code review with team standards",
  "author": "Your Team",
  "license": "MIT",
  "commands": ["commands/review.md"],
  "templates": ["templates/CLAUDE.md"],
  "tags": ["review", "quality", "team"]
}

Step 5: Share with your team

The simplest way to share is through a Git repository:

cd code-review-plugin
git init && git add . && git commit -m "Initial plugin"
git remote add origin https://github.com/yourorg/code-review-plugin.git
git push -u origin main

Team members clone the repo and copy the commands/ folder into their project’s .claude/commands/ directory, or symlink to it. The CLAUDE.md template can be appended to the project’s existing CLAUDE.md.

Note on plugin installation: Claude Code does not currently have a built-in install-plugin CLI command. Plugins are shared by distributing their files (commands, templates, settings) through Git repos, npm packages, or shared directories. Team members integrate them manually into their .claude/ configuration. This is straightforward and keeps you in control of what runs in your environment.

17.4 The Plugin Marketplace Ecosystem

Several community-driven directories have emerged for discovering Claude Code plugins and MCP servers:

Official Anthropic MCP Servers (github.com/modelcontextprotocol): Reference implementations maintained by Anthropic. These are the most reliable and well-documented.

Community Plugin Collections: Various GitHub repositories aggregate plugins organized by category (web development, testing, DevOps, security, documentation). These range from single MCP servers to full plugin bundles with commands and templates.

How to evaluate community plugins:

Read the README. Is it clear what the plugin does and what access it needs?
Check the code. Especially hooks and MCP server configurations. What commands does it run? What APIs does it call?
Look at version history. Active maintenance is a good sign. Abandoned repos with no updates in 6+ months are risky.
Check compatibility. Does it work with your Claude Code version?
Start small. Install one plugin at a time. Test it before adding more.

Try This Now: Browse the modelcontextprotocol GitHub organization. Pick one MCP server you have not used before (Brave Search is a good choice if you want web search). Add it to your .claude/settings.json, restart Claude Code, and test it with a real query.

Deep Dive (Optional)

17.5 Building a More Complete Plugin

Let’s extend the code review plugin into a full Team Workflow Plugin that includes commands, hook integration, and documentation templates.

Adding a deploy command (commands/deploy.md):

# Deploy

Deploy the current branch to the specified environment.

## Instructions

1. Check that all tests pass: run `npm test`
2. Check that the branch is clean: `git status`
3. If deploying to production, verify we are on `main` branch
4. Run the deploy script: `npm run deploy:$ARGUMENTS`
5. After deploy, run smoke tests: `npm run test:smoke`
6. Report results with deploy URL and any errors

Adding hook integration:

To auto-run the review before commits, add this to the project’s .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Hook: Checking for common issues before tool use'"
          }
        ]
      }
    ]
  }
}

Plugin versioning:

Follow semantic versioning when updating your plugin:

1.0.0 to 1.0.1: Bug fix (fixed typo in review command)
1.0.1 to 1.1.0: New feature (added deploy command)
1.1.0 to 2.0.0: Breaking change (renamed commands, changed config format)

Always maintain a CHANGELOG so team members know what changed.

17.6 Security Considerations for Plugins

When sharing plugins:

Never hardcode API keys, tokens, or credentials. Use environment variables.
Document what external access the plugin requires.
Review all hook scripts for unintended side effects.
Test plugin installation on a clean environment before distributing.

When installing plugins from others:

Read the source code, especially any MCP server configurations and hook scripts.
Check what environment variables are required and why.
Run in a test project before adding to production workflows.
Keep plugins updated to get security patches.

When Things Go Wrong

Problem: A plugin’s MCP server conflicts with another

Symptoms: Claude Code errors on startup, or one MCP server’s tools stop working after adding another.

Fix:

Check .claude/settings.json for duplicate server names. Each MCP server needs a unique key.
Check for port conflicts if servers run on specific ports.
Remove the new server, restart Claude Code, verify the original works, then re-add and test.

Problem: Plugin version incompatibility – commands reference features that do not exist

This happens when a plugin was written for a newer (or older) version of Claude Code than you are running.

Fix:

Check the plugin’s plugin.json for a claudeCode.minVersion field.
Update Claude Code: claude update or reinstall from the official source.
If the plugin is too new, pin to an older version or ask the maintainer for a compatible release.

Problem: An MCP server plugin slows down Claude Code startup

MCP servers start as separate processes. A slow or broken server can delay Claude Code initialization.

Fix:

Check which server is slow: temporarily remove MCP servers one at a time from .claude/settings.json and restart.
Increase the timeout in the server configuration if the server needs time to connect to an external service.
If a server consistently times out, it may have a configuration error (wrong credentials, unreachable endpoint). Check its logs.

Problem: Hook in a plugin runs unexpectedly or causes errors

Fix:

Check .claude/settings.json for hook definitions. Look at the matcher field to understand what triggers the hook.
Hooks use PreToolUse and PostToolUse event types (not before_tool_call / after_tool_call, which are outdated names from earlier documentation).
Temporarily disable the hook by removing it from settings, test your workflow, then re-enable with a more specific matcher.

Chapter Checkpoint

What you learned in this chapter:

Plugins bundle Claude Code commands, hooks, templates, and MCP configs into shareable packages
Community MCP servers are the most practical way to extend Claude Code today
Installing an MCP server requires adding a config block to .claude/settings.json
Creating a plugin means organizing commands and templates into a Git-shareable structure
Always review plugin code (especially hooks and MCP servers) before installing

Competency checklist – you should be able to:

Install and configure a community MCP server (GitHub, filesystem, or others)
Explain the difference between a single command, an MCP server, and a full plugin
Create a basic plugin with a command and a CLAUDE.md template
Share a plugin with your team through a Git repository
Evaluate a community plugin for quality, security, and compatibility
Troubleshoot MCP server startup issues and hook conflicts

You’ve completed Chapter 17: Plugins and the Marketplace Next: Chapter 18 – Best Practices and Mastery