Integrations
Connecting Claude Code to external systems — MCP servers, IDE extensions, GitHub, and the first-party app MCPs (Slack, Gmail, Drive, Calendar).
Integrations extend Claude Code's reach beyond the local filesystem. The Model Context Protocol (MCP) is the canonical way: an open protocol for tools, resources, and prompts that any server can implement and any client can speak. Claude Code is an MCP client; once you connect a server (local or remote), its tools appear alongside the built-ins.
The IDE extensions (VS Code, JetBrains) are a different shape of integration — they put Claude Code inside the editor, sharing diagnostics, diffs, and selection state. GitHub integration is mostly the `gh` CLI used from Bash, but the conventions for committing, opening PRs, and reviewing are common enough to be worth documenting once.
First-party app MCPs (Slack, Gmail, Drive, Calendar, Sentry, BigQuery, Atlassian, Amplitude) let Claude Code touch the rest of your work surface. Each one is auth-flow-gated for good reason; turning them on is a deliberate choice, not a default.
Key concepts
- MCP is a protocol, not a product — any server that speaks it works with any compliant client
- Local MCP servers run in the same process tree as the CLI; remote ones are network calls — the security surface differs
- IDE extensions share state with the editor — diagnostics are first-class, not parsed from terminal output
- GitHub access via `gh` is the same as your shell — your auth, your permissions, your audit trail
- App MCPs require explicit OAuth flows — turning one on grants Claude Code the same scopes you grant it
Reference template
// Checklist before adopting an integration
1. What does it grant Claude? (read? write? both? to which data?)
2. How is it authenticated? (your token? a service account? OAuth?)
3. Where does the audit live? (logs? a hook? nothing?)
4. Local or remote? (process boundary vs network boundary)
5. Failure mode? (graceful timeout? hard crash? silent drop?)
6. Rate limits? (does it throttle? cost per call?)
7. Who else can see it? (team-shared? user-only?) Adapt to your problem; the structure is the load-bearing part.
Common pitfalls
- Turning on an app MCP without reading the scopes — you authorised more than you think
- Treating an MCP server as trusted — its tool outputs flow into the model's context; treat them like external input
- Conflating IDE-integration with terminal-integration — they share the same model but have different affordances and constraints
- Forgetting to gate a remote MCP behind a per-environment config — what works in dev shouldn't be active in production sessions
Related topics
Items (6)
- MCP Servers Overview
The Model Context Protocol. What MCP is, how Claude Code talks to MCP servers, and the difference between local and remote servers.
Integration Intermediate - Building an MCP Server
Writing a custom MCP server in TypeScript or Python. Tools, resources, prompts, and the JSON-RPC contract.
Integration Advanced - GitHub Integration
Using `gh` for issues, PRs, and reviews from inside Claude Code. The committing checklist and the PR-creation workflow.
Integration Foundational - VS Code Extension
Running Claude Code inside VS Code. Diagnostics, inline diffs, and the split between IDE and terminal sessions.
Integration Foundational - JetBrains Extension
Running Claude Code inside IntelliJ-family IDEs. Feature parity with VS Code and the IDE-specific affordances.
Integration Foundational - App MCPs — Slack, Gmail, Drive, Calendar
First-party MCP integrations to common SaaS apps. Auth flow, scope, and the privacy considerations before turning each one on.
Integration Foundational