# Plugins and ecosystem integrations
Claude does its best work when it sits inside the tool you already have open, not in a browser tab you keep switching to. This lesson maps every place Claude plugs in: your editor, your desktop, your Slack, your repos, and the connector layer that ties it all together. Then we set up the VS Code integration end to end and draw a clear line for when an integration earns its keep over copy-paste.
Think of Claude as having three "bodies" you can install it into.
The Claude apps. Web, desktop, and mobile share the same core: Projects (persistent context buckets), Artifacts (live, editable outputs), Styles (reusable tone and format presets), and Skills (packaged instructions plus files Claude loads on demand). The desktop app matters most here because it can run Connectors and local MCP servers, which the web app cannot reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition →.
Claude Code. A terminal-native agent that reads and edits your actual filesystem, runs commands, and works against your git history. This is what powers the IDE extensions.
The API layer. The Anthropic Messages APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → and the Claude Agent SDK for when you build your own surface instead of using Anthropic's.
The connective tissue across all three is MCP (Model Context Protocol), an open standard for exposing tools and data to a model. A "Connector" in the Claude apps is, under the hood, usually an MCP server. Learn MCP once and the same mental model applies whether you're in the desktop app, Claude Code, or your own SDK build. The spec lives at modelcontextprotocol.io.
A Connector lets Claude read from and act on an external system: your Google Drive, a Notion workspace, a Postgres database, a Sentry project. Anthropic ships a set of first-party connectors and hosts a connector directory; many are community-built MCP servers you point Claude at.
Two flavors matter:
That distinction (remote vs local) decides which "body" of Claude you reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → for. Local data means desktop or Claude Code, not the web app.
Let's do the concrete one. The Claude Code extension brings the agent directly into VS Code so it can see your open files, your selection, and your diagnostics, then propose edits you review inline.
You need the Claude Code CLI first, then the extension wires into it.
# Install Claude Code (macOS / Linux)
curl -fsSL https://claude.ai/install.sh | bash
# Verify, then authenticate
claude --version
claude # first run opens a browser to log inThen in VS Code, open the Extensions panel, search Claude Code, and install the official Anthropic extension. It detects the CLI automatically. JetBrains users get a parallel plugin from the JetBrains Marketplace; the workflow below is nearly identical.
Once installed, you get a Claude panel in the sidebar and a keyboard shortcut to send the current selection or file into context. The key difference from the web app: Claude now sees the real project, not a pasted snippet. It can open neighboring files, read your package.json, and run your test command.
Drop a CLAUDE.md file at your repo root. This is the project's standing instructions, loaded automatically every session. It's the single highest-leverage file in the whole setup.
# Project: billing-service
## Stack
- TypeScript, Node 20, Fastify, Prisma, Postgres
- Tests: vitest. Run with `npm test`.
## Conventions
- No `any`. Prefer explicit return types on exported functions.
- All money values are integer cents, never floats.
- DB access goes through `src/db/`, never inline Prisma in routes.
## Before you finish
- Run `npm run lint && npm test` and report results.Now when you ask "add a refund endpoint," Claude already knows your stack, your money rule, and that it should run lint and tests before declaring victory. You stopped re-explaining context on every prompt.
Say you want Claude to query your dev database directly inside VS Code. Register an MCP server scoped to the project:
claude mcp add postgres-dev \
--env DATABASE_URL="postgres://localhost:5432/billing_dev" \
-- npx -y @modelcontextprotocol/server-postgresAfter this, "show me the schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → of the invoices table and write a migration to add a refunded_at column" works against your live dev schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →, no copy-paste of \d invoices output required. The server runs locally, so the connection string never leaves your machine.
Claude Code in VS Code: Full Setup & Workflow
The GitHub integration moves Claude from "in your editor" to "in your pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →." Install the Claude GitHub app on a repo and you can tag @claude in an issue or PR comment, and it will open a branch, write the change, and push a PR, or review an existing PR and leave inline comments.
This is the cleanest example of integration beating the web app. The model acts where the work already lives: the diff, the CI logs, the review thread. Nothing gets pasted anywhere. You wire it up with a GitHub Actions workflow and your Anthropic APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → key stored as a repo secret. Use it for triaging issues, drafting first-pass PRs for well-specified tickets, and automated review on a label.
The Claude Slack integration puts Claude in a channel or DM where it can read the thread it's mentioned in and answer with your connected context. Pair it with connectors (say, a Notion or Drive connector) and "@Claude summarize the decision in this thread and draft the update for #eng-announce" becomes a one-message task.
The pattern generalizes: any surface where your team already talks or works is a candidate. The value isn't a smarter model, it's removing the context-gathering step the human would otherwise do by hand.
Knowledge check
1. What is the primary role of MCP (Model Context Protocol) across Claude's different surfaces?
2. You need Claude to read and act on a local Postgres database and internal files you don't want exposed to the internet. Which surface should you reach for?
3. Why does the desktop app matter more than the web app when working with certain integrations?
4. Select ALL statements that correctly describe the distinction between remote connectors and local MCP servers.
Select all the correct answers.
5. Select ALL of the following that are shared capabilities of the Claude apps (web, desktop, mobile).
Select all the correct answers.
Here's the decision rule. The web app is a great scratchpad. An integration wins whenever one of these is true:
1. The context is large or lives in many files. Pasting twelve files into a chat is lossy and you'll forget one. The IDE integration reads the repo. The cost of assembling context by hand is exactly what the integration deletes.
2. The output needs to land somewhere specific. A PR, a Slack message, a database row, an edited file. If you're going to copy Claude's answer and paste it into another tool, an integration that writes there directly removes a failure point (the copy-paste where you lose formatting or grab the wrong block).
3. The task is repeated. "Review every PR for our money-handling rule" is worth a GitHub Action. A one-off question is not. Automate the loop, not the one-off.
4. The data can't leave your machine or your org. Local MCP servers and the desktop app keep things in-house. The web app means data transits to your browser session.
When NONE of those hold (a quick one-off question, a brainstorm, a snippet small enough to paste), the web app is genuinely the right tool. Don't over-engineer. The integration overhead (config files, auth, MCP servers) only pays off when context, destination, or repetition is in play.
You need to add input validation to one route.
These actions are compiled in the role's Playbook.
CLAUDE.md, writes the edit with correct imports, runs npm test, and reports back. You review the diff.The second path isn't smarter. It's the same model with the friction removed.
When no existing integration fits, you build one with the Agent SDK. This is the escape hatch: you keep Claude's tool-use and MCP capabilities but wrap them in your own app, cron job, or internal service.
import anthropic
client = anthropic.Anthropic()
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=[{
"role": "user",
"content": "Summarize today's failed payments and flag any over $500.",
}],
)
print(resp.content[0].text)That's the raw Messages APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →. The Agent SDK builds on top of it to give you the same agent loop, tool calling, and MCP support that Claude Code uses, so a nightly script can do what you'd otherwise do by hand in the app. The starting points and SDK source live under github.com/anthropics.
The mental model: apps for thinking, Claude Code and IDE extensions for building, the SDK for shipping the loop into your own infrastructure. MCP is the wire that connects your tools to all three.