Claude Code · Advanced · Part 6 of 8

Extending Claude Code: MCP, subagents, plugins, and using it in your editor

So far Claude Code has worked inside your project folder with the tools it ships with. Real projects also live in issue trackers, databases and monitoring dashboards, and real developers live in editors. This part covers the extension layer: how to connect Claude to outside tools with MCP, how to delegate work to subagents, how to bundle and share setups as plugins, and how Claude Code behaves in VS Code, JetBrains, the desktop app and the web. As before, details come from the official docs and my own advice is marked.

1. Which extension for which problem?

The official guide to extending Claude Code makes a useful point: you do not need to configure everything up front. Each feature has a recognisable trigger, and most teams add them in roughly this order:

And this is how the main ones differ in what they cost your context window, which connects back to Part 3:

They also combine. The docs give examples: MCP provides the connection while a skill teaches Claude how to use it well (for instance, MCP connects to your database and a skill documents your schema and query patterns); CLAUDE.md holds the always-on rules while skills hold the reference material loaded on demand; and a skill can spawn subagents for parallel work. For the rest of this post I will skip automation scripts that run on events (the series leaves those out) and focus on the four tools above.

2. MCP: connecting Claude to outside tools

The Model Context Protocol (MCP) is, in the docs' words, “an open source standard for AI-tool integrations.” In plain terms: an MCP server is a small program or web service that offers Claude a set of tools for one outside system, such as an issue tracker, a design tool, a monitoring service or a database. Once connected, you can say things like these (the official examples):

Add the feature described in JIRA issue ENG-4521 and create a PR on GitHub.
Check Sentry and Statsig to check the usage of the feature described in ENG-4521.
Find emails of 10 random users who used feature ENG-4521, based on our PostgreSQL database.

Adding a server

There are different ways a server can be reached. HTTP is the recommended one for remote servers; stdio runs a program on your own machine; SSE is deprecated in favour of HTTP.

# Remote server over HTTP (recommended for remote)
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Remote server that needs a token header
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

# Local program over stdio. The -- separates Claude's flags from the server command
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
  -- npx -y airtable-mcp-server

Where the configuration lives

Add --scope (or -s) to choose who gets the server:

When the same server name exists at several levels, local wins over project, and project over user. Claude Code asks you to approve servers from a project's .mcp.json before using them, which protects you from servers a teammate (or a stranger's repository) committed.

Managing and signing in

claude mcp list            # all servers, with health status
claude mcp get notion      # details for one server
claude mcp remove notion   # remove it (also deletes stored sign-in tokens)

# Inside a session
/mcp                       # check status, sign in, reconnect, toggle

For servers that use OAuth sign-in, add the server, run /mcp in a session, and follow the browser steps. Tokens are stored and refreshed automatically. From a shell, claude mcp login <name> does the same. Non-interactive runs (claude -p) cannot do the OAuth step, so sign in interactively first.

Safety and cost

• Token cost: tool search is on by default, so idle MCP tools use little context: only tool names load at the start and full details load when a tool is needed. Run /context all to see how many tokens each loaded MCP tool uses, and disable servers you are not using.
• CLI first when one exists: the cost guide notes that tools like gh, aws, gcloud and sentry-cli are more context-efficient than MCP servers because they add no per-tool listing.
• Large outputs: Claude Code warns when a tool returns more than 10,000 tokens and caps output at 25,000 by default.

3. Subagents: helpers with their own context

The best-practices guide says context is your fundamental constraint, and subagents are the main tool for protecting it. The docs define them like this: a subagent is a specialised assistant you use when a side task would flood your main conversation with search results, logs or file contents you will not reference again. It does the work in its own context window and returns only the summary.

Built-in subagents

Claude uses these on its own when it makes sense, and you can ask directly:

Use subagents to investigate how our authentication system handles token
refresh, and whether we have any existing OAuth utilities I should reuse.

use a subagent to investigate how our auth system handles token refresh

Making your own

A custom subagent is a markdown file with a short header. Put it in .claude/agents/ to share it with your project, or in ~/.claude/agents/ to use it everywhere. Only name and description are required. This is the docs' own example:

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

• tools limits what the helper may do. A reviewer that can only read cannot change your code.
• model can be sonnet, opus, haiku, inherit or a full ID. Routing simple work to a cheaper model is a real cost saving (Part 3).
• The description matters: Claude uses it to decide when to delegate. Phrases like “use proactively” encourage it.
• Invoking it: ask in plain words (Use the test-runner subagent to fix failing tests), @-mention it with @"code-reviewer (agent)" look at the auth changes, or run the whole session as that agent with claude --agent code-reviewer.
• Where it wins: when the same name exists in several places, managed settings win, then the --agents flag, then .claude/agents/, then ~/.claude/agents/, then plugins.
• Note on /agents: on current versions the command just prints a reminder to ask Claude or edit the folders directly; older versions (v2.1.197 and earlier) opened a wizard.

Good to know

• Foreground or background: foreground subagents block your conversation and pass permission prompts through. Background ones run alongside; press Ctrl+B to send a running task to the background.
• What a subagent does not see: your conversation history (except a “fork”, started with /subtask), your output style, or your main auto memory. Put what it needs in the prompt.
• Limits: by default up to 3 layers of nesting and 20 running at once, both adjustable with environment variables.
• Permissions: if your session is in auto, accept edits or bypass mode, a subagent's own permission mode is ignored.
• A review pattern from the docs: “Use a subagent to review the rate limiter diff against PLAN.md. Check that every requirement is implemented, the listed edge cases have tests, and nothing outside the task's scope changed. Report gaps, not style preferences.”

4. Plugins: bundle and share a setup

A plugin packages skills, subagents, MCP servers (and other pieces) into a single installable unit. A marketplace is a catalogue of plugins. Use plugins when you want the same setup across repositories or to share it with others. Plugin skills are namespaced like /commit-commands:commit so several plugins can coexist.

1. Open the browser. Run /plugin in a session. It opens a panel with a Discover tab listing plugins from your marketplaces.

   /plugin

2. Or install one by name. This example from the docs adds commands for committing, pushing and opening pull requests; it opens the plugin's details so you can review it first.

   /plugin install commit-commands@claude-plugins-official

3. Read what it adds. The details pane lists the skills, agents and servers it installs, and for plugins in Anthropic's official marketplace it shows token estimates: one for every turn and one for when its skills are invoked.
4. Choose a scope. User (every project on this machine), project (everyone on the repository, recorded in the committed .claude/settings.json) or local (you, this repository only).
5. Check it worked. Type / and look for /<plugin>:<skill>, or run claude plugin list in your shell.

5. Your editor, desktop app or browser

The agentic loop, tools and settings are the same everywhere. What changes is where the code runs and how you interact with it. In the official words, each surface connects to the same Claude Code engine, so your repository's CLAUDE.md, settings and MCP servers work across all of them.

VS Code (and Cursor)

• Needs: VS Code 1.94.0 or later and a paid Claude plan (Pro, Max, Team or Enterprise) or a Console account. Install from the Extensions view (search “Claude Code”), or use the install link for Cursor.
• Open it: click the Spark icon in the editor toolbar, the Activity Bar or the status bar, or use the Command Palette and type “Claude Code”.
• What it adds over the terminal: a graphical panel with inline diffs, the plan opened as a markdown document you can comment on, @-mentions of files with line ranges from your selection, conversation history, multiple conversations in tabs, and a mode indicator under the prompt (Manual, Plan, Auto, Edit automatically).
• Rewind: hover over any message for the rewind button: fork the conversation, rewind code, or both.
• What differs: only a subset of commands and skills are available (type / to see them); the ! shell shortcut and tab completion are CLI-only. Installing the extension does not put claude on your PATH; for CLI features, install the CLI and run claude in the integrated terminal, which connects to the editor automatically.
• Same history: the extension and CLI share conversations. Continue an extension conversation in the terminal with claude --resume.

JetBrains IDEs (IntelliJ, PyCharm, Android Studio and more)

• Two pieces: install the Claude Code CLI, and the Claude Code plugin from the JetBrains Marketplace, then restart the IDE. The plugin runs claude in the IDE's terminal and connects to it; it does not bundle its own CLI.
• Open it: Cmd+Esc on Mac or Ctrl+Esc on Windows/Linux, or the Claude Code button. From an external terminal, run /ide to connect.
• What you get: changes open in the IDE's diff viewer, your current selection and tab are shared automatically, Cmd+Option+K (Mac) or Alt+Ctrl+K inserts file references like @src/auth.ts#L1-99, and Claude can read the IDE's inspection diagnostics.
• Gotchas: if Esc does not interrupt Claude, untick “Move focus to the editor with Escape” in the terminal settings. For JetBrains Remote Development, install the plugin on the remote host. WSL2 may need a firewall rule or mirrored networking.
• Security note from the docs: in accept-edits mode Claude may be able to modify IDE configuration files that the IDE can execute automatically, so the docs suggest Manual mode in JetBrains.
• Privacy: a Read deny rule (Part 2) stops the IDE from sharing a matching file's selection with Claude, for example .env.

The desktop app

• What it is: the Claude desktop app with three tabs: Chat (general conversation with no file access), Cowork (an autonomous background agent for tasks) and Code (Claude Code with a graphical interface). It needs a Pro, Max, Team or Enterprise plan for Code.
• No terminal needed. The app includes Claude Code, so you do not install Node.js or the CLI.
• Start: open the Code tab, choose Local (your machine), Cloud, SSH or WSL, select a folder, pick a model and describe the task.
• Why people like it: a visual diff view with Accept and Reject, comments on specific lines, several sessions side by side (optionally each in its own worktree), a built-in preview of your running app, scheduled tasks, and PR monitoring that can fix CI failures.

Claude Code on the web (cloud sessions)

• What it is: a session that runs on cloud infrastructure instead of your computer, started from claude.ai/code, the mobile app, the desktop app or the terminal. It keeps running after you close your laptop. Available on Pro, Max and Team plans, and for Enterprise users with premium seats.
• It needs GitHub: connect GitHub (the Claude GitHub App or /web-setup from your terminal) so the session can clone your code and push branches.
• Move work between terminal and cloud: claude --cloud "Fix the authentication bug in src/auth/login.ts" starts a cloud session for your current repository (push first: it clones your GitHub remote, not your local checkout). claude --teleport pulls a cloud session into your terminal.
• Review: each session shows a diff indicator such as +42 -18; open it, comment on lines and send feedback.
• Auto-fix: Claude can watch a pull request and respond to CI failures and review comments. Run /autofix-pr on the PR's branch. The docs warn it replies using your GitHub account, and to review repository automations triggered by comments before turning it on.
• Isolation: each session runs in an isolated VM with limited network access by default, and your GitHub credentials stay outside the VM.
• Limits: cloud sessions share your plan's usage limits, GitHub is required for cloning and pull requests, and /clear is not available (start a new session instead).

6. Choosing a surface

You can mix them. Because the extension and CLI share history and the engine is identical, a common pattern is to explore in the editor, run a heavy job in the cloud, and teleport the result back to the terminal to finish. My own advice: pick one surface and get fluent in it first; extra surfaces are easy to add later.

7. Wrap-up and glossary

1. Add extensions when a recurring problem appears, not before.
2. MCP connects outside systems; trust servers carefully, and prefer a CLI tool when one exists.
3. Subagents protect your main context and can use cheaper models.
4. Plugins package and share a setup; read what they add and prune the ones you do not use.
5. The surface changes how you interact, not what Claude can do.

Part 7 moves from one developer to many: running Claude Code in scripts and CI, and setting it up for a team or organisation.