App MCPs — Slack, Gmail, Drive, Calendar

What it integrates#

Anthropic ships a set of first-party MCP integrations to common SaaS apps. They’re remote MCP servers hosted by Anthropic; you authorise each one via an OAuth flow scoped to your account, and Claude Code gets a tool surface for reading and acting against that app.

The headline integrations covered here:

• Slack — read messages and channels you have access to; send messages; search across the workspace.
• Gmail — list, read, search, and send email; manage labels and drafts.
• Google Drive — list, search, read, and (with the right scope) create Drive documents and Sheets.
• Google Calendar — list events, check availability, create and update events, send invitations.

Adjacent first-party MCPs that follow the same auth pattern and are worth knowing about:

• Sentry — list and read issues, view stack traces, comment on issues.
• Google Cloud BigQuery — run SQL against datasets you have access to.
• Atlassian (Jira / Confluence) — read and update issues, search Confluence pages.
• Amplitude — query event data.
• Zoom — read meeting details, recordings, and transcripts.

What they share: hosted by Anthropic, OAuth-based auth, scoped permissions, no infrastructure on your side. What you give up versus a self-hosted MCP: data flows through Anthropic’s hosting layer, the scope is whatever the integration was designed for (you can’t widen it), and you can’t customise the tool surface.

Setup#

The uniform auth flow#

Every first-party integration follows the same three-step flow:

1. Trigger authentication. Inside a Claude Code session, ask the model to use the integration (“read my unread Slack DMs”), or call the auth tool directly: mcp__claude_ai_Slack__authenticate.
2. Complete OAuth in a browser. Claude Code returns an authorisation URL. Open it; sign in to the provider; review the requested scopes; consent.
3. Confirm the code. The provider returns a verification code; paste it back into the session and call mcp__claude_ai_Slack__complete_authentication with the code. The session is now bound to your account for that integration.

Sample exchange:

You:    Authenticate me to Slack.
Claude: [calls mcp__claude_ai_Slack__authenticate]
        Open this URL: https://claude.ai/...
        Paste the verification code when you have it.
You:    [opens URL, completes OAuth, copies code 'A4F2-9KX1']
        A4F2-9KX1
Claude: [calls mcp__claude_ai_Slack__complete_authentication]
        Authenticated. You have read:messages, write:messages, read:channels scopes.

Per-integration scope summary#

The scopes each integration requests at consent time:

Slack          read:messages, read:channels, write:messages
Gmail          gmail.readonly OR gmail.modify (your pick at consent)
Drive          drive.readonly OR drive.file OR drive (per file vs. full)
Calendar       calendar.events.readonly OR calendar.events
Sentry         project:read, event:read, event:write (for commenting)
BigQuery       bigquery.readonly OR bigquery
Atlassian      read:jira-work, write:jira-work, read:confluence-content.all
Amplitude      read-only query access
Zoom           meeting:read, recording:read

Some providers (Gmail, Drive, Calendar) let you pick read-only or read-write at the OAuth screen. Pick read-only unless you specifically need write — you can re-auth later to widen the scope.

What’s stored where#

The OAuth tokens are stored by Anthropic’s hosted MCP server, not on your machine. Your Claude Code session holds a reference (the integration is “connected for this user”) but doesn’t see the raw token. Two consequences:

• Re-authenticating from a different machine works — the server knows your account, finds your stored token, and uses it.
• Revocation lives in the upstream provider (Slack workspace settings, Google Account permissions, etc.), not in Claude Code. Removing an integration from the Claude Code UI un-connects the session; revoking the token in the provider revokes it for everyone.

Listing what’s available#

mcp__claude_ai_<App>__authenticate and mcp__claude_ai_<App>__complete_authentication are the bootstrap pair. Each integration also exposes domain tools (Slack: send_message, search_messages; Gmail: list_messages, send_message; Drive: list_files, read_file). The exact tool names are visible via the session’s tool listing once you’re authenticated.

Disabling per-project#

If a project shouldn’t have any app integrations active, scope them out in .claude/settings.json:

{
  "mcpServers": {
    "claude_ai_Slack": { "enabled": false },
    "claude_ai_Gmail": { "enabled": false }
  }
}

The integrations remain authorised at the user level but aren’t loaded for sessions started in this project. Useful for repos that should never have outside-context data flowing in (security-sensitive codebases, client work under strict NDA).

Capabilities#

Slack#

The recurring patterns:

• Triage unread DMs and threads. search_messages(query='from:@me has:question') plus the model summarising what needs a reply.
• Status-update digests. Pull the last day of messages from a #eng-status channel and produce a structured summary.
• Send a message. send_message(channel='#eng-deploys', text='Build green; merging shortly'). Cheap to do; high blast radius if misdirected — gate with a permission rule.
• Search across history. Slack’s search API powers search_messages; the tool exposes the same query syntax (from:, in:, before:, after:).

Gmail#

• Daily digest from the inbox. list_messages(query='label:inbox is:unread') then read each, summarise, propose action items.
• Draft a reply. create_draft(to, subject, body, in_reply_to). Drafts are reviewable in the Gmail UI before send — preferred over send_message for anything non-trivial.
• Search archive. Standard Gmail search operators work.
• Label management. Apply or remove labels in bulk.

Drive#

• Pull a document into context. read_file(file_id) brings the doc body into the session — useful when the model needs the spec, design doc, or runbook.
• Search by content. search_files(query='fullText contains "ratelimit"') finds docs the model can then read.
• Create a document. create_file(name, content, mime_type) — typical for “produce the postmortem doc and put it in the Eng folder.”
• Spreadsheets. Reading is straightforward; writing rows is supported but quirky — bulk-update via Sheets API is better for serious sheet manipulation.

Calendar#

• Check availability. list_events(time_min, time_max, calendar_id='primary') then the model identifies free slots.
• Create an event. create_event(summary, start, end, attendees).
• Reschedule. update_event(event_id, ...) — the integration handles RSVP regeneration upstream.
• Cross-calendar availability. With access granted to a colleague’s calendar (their consent), find a slot that works for everyone.

Sentry, BigQuery, Atlassian, Amplitude, Zoom#

The remaining integrations follow the same shape — auth via OAuth, a domain-specific tool surface, scoped permissions. Examples of what they unlock:

• Sentry — “list the top 10 unresolved issues in service X this week, summarise the common root cause.”
• BigQuery — “run this query against the events dataset, group by user_segment.”
• Jira — “what’s in my sprint? Which tickets are blocked?”
• Amplitude — “show the funnel from signup to first key action over the last 30 days.”
• Zoom — “summarise the recording from yesterday’s design review and extract action items.”

Configuration#

Per-session enablement#

The simplest case: every authenticated integration loads on session start. If you want a narrower session (“just Slack, nothing else”), use the project-level mcpServers block to disable the rest. The user-level auth is preserved; only the in-session tool surface is narrowed.

Permission rules per tool#

The strongest leverage is on write-capable tools — sending messages, creating events, writing files, posting comments. Default-ask these:

{
  "permissions": {
    "allow": [
      "mcp__claude_ai_Slack__search_messages",
      "mcp__claude_ai_Gmail__list_messages",
      "mcp__claude_ai_Gmail__get_message",
      "mcp__claude_ai_Google_Drive__list_files",
      "mcp__claude_ai_Google_Drive__read_file",
      "mcp__claude_ai_Google_Calendar__list_events"
    ],
    "ask": [
      "mcp__claude_ai_Slack__send_message",
      "mcp__claude_ai_Gmail__send_message",
      "mcp__claude_ai_Gmail__create_draft",
      "mcp__claude_ai_Google_Drive__create_file",
      "mcp__claude_ai_Google_Drive__update_file",
      "mcp__claude_ai_Google_Calendar__create_event",
      "mcp__claude_ai_Google_Calendar__update_event"
    ]
  }
}

Reads auto-approve; writes always prompt. The prompt-fatigue cost is small (writes are rare); the blast-radius reduction is significant.

Scope tightening per provider#

Each provider has its own permission management:

• Google — accounts → security → third-party access → “Claude” → manage scopes.
• Slack — workspace admin → integrations → app management → “Claude” → permissions.
• Atlassian — account → security → connected apps → Claude.

You can narrow scopes after the fact by revoking and re-authorising with a tighter consent screen.

Multiple accounts#

You can connect at most one account per integration per Claude account. To use a different Google account for Drive, re-run the auth flow; the previous token is replaced. There’s no built-in “switch account” UI mid-session — re-auth is the way.

Failure modes#

Auth expiry and silent revocation#

OAuth refresh tokens rotate. Symptoms: a read_file call that worked an hour ago now returns 401. The fix is to re-run the authenticate tool. Anthropic-side caching means you might also see a brief window where the cached token is still considered valid; just re-authing always resolves it.

Silent revocation happens when an admin removes the integration at the workspace level — your token is invalidated upstream without notifying you. Same symptom (401s), same fix (re-auth), but it’ll keep failing until the workspace admin restores access.

Rate limits#

Each provider has its own rate limits. A burst of list_messages calls in a row will hit Gmail’s quotaExceeded. Slack throttles aggressively per-method. The tool surface returns the upstream error verbatim; back off and retry.

Schema drift#

Anthropic updates the integration; an existing session has stale schemas cached. Restart the session — startup re-discovery picks up the new shape. Symptom that screams “schema drift”: the model insists a parameter exists that the tool now says it doesn’t.

Search-vs-fetch confusion#

Slack’s search_messages returns a paginated subset; the model may misinterpret it as exhaustive. The fix is in prompt: ask explicitly “search and then iterate pages until exhausted” when you need totality.

Drive document size#

read_file on a 100-page doc returns the whole body. That’s hundreds of KB into context, which crowds out everything else. Ask for read_file(file_id, range) if available, or have the model summarise iteratively rather than read whole.

Calendar timezones#

Times in the API are ISO-8601 with timezones. The model is good at this but not perfect; a missing Z or +00:00 can result in an event scheduled in the wrong hour. Always double-check the rendered event time before accepting.

Cross-integration data leakage in context#

Three integrations enabled means three sources flowing into the same context window. A Gmail thread the model just read can land in the context for a Drive write call later in the same turn. This is by design — that’s why MCP integrations are powerful — but it’s also exactly the surface attackers target with prompt injection.

Security and permissions#

Data flow#

The remote MCP server hosts the integration. When the model calls slack__send_message, the call goes:

Claude Code (your machine) → Anthropic MCP host → Slack API → channel

Three trust assertions implied:

1. You trust Anthropic with the OAuth token (it’s stored server-side).
2. You trust Anthropic’s MCP host with the request payload (the message content).
3. You trust Slack’s API to do the right thing (it’s the system of record).

The Anthropic privacy and data-handling commitments cover the storage and the request-processing layers. Provider-side handling is whatever the provider’s terms say.

Read scopes leak more than you think#

A Gmail gmail.readonly scope grants the integration access to every email in the account, not just emails you reference in conversation. The integration can only act when the model invokes a tool, but the scope the OAuth token holds is broad. If your inbox has secrets (recovery codes, single-sign-on bypasses), they’re reachable in principle.

Practical mitigation: dedicated work-only Google accounts for the Gmail/Drive/Calendar integrations, not your personal account. Most companies’ Google Workspace is the right answer.

Write scopes are blast-radius scopes#

Read scope leaks. Write scope acts. The same email account with gmail.modify:

• Can send email as you (with full headers, including DKIM).
• Can label, archive, or delete messages.
• Cannot read messages flagged with the gmail.metadata scope, but the model isn’t using that scope — it’s using the broader one.

For Slack, write-message scope means the integration can post as you in any channel you’re a member of. There’s no per-channel scoping at OAuth time — that’s set in the Slack admin console.

Read-only versus read-write at consent time#

The pattern that works: start read-only; re-auth to add write scope the day you actually need it; keep the write-tool permission rules at ask forever.

Revocation#

In order of speed:

1. In the upstream provider’s console. Google account → security → third-party access; Slack admin → integrations. Immediate and authoritative.
2. From Anthropic’s connected-apps UI. Disconnects the integration from your Claude account; the upstream token may remain valid for a few minutes until upstream sync.
3. From a project’s .claude/settings.json. Disables the integration for sessions in that project only. Cosmetic; the token is still authorized.

For “I think someone has access they shouldn’t,” do (1).

Related integrations#

• MCP Servers Overview
• Building an MCP Server
• GitHub Integration
• Permission Rules and Allowlists
• Hooks Overview