Connecting Slack, Notion & Drive

How connections work

An hour from now, Slack and Notion answer inside your Claude sessions, and the permission rules that govern them are checked into your repo. The mechanism is MCP (Model Context Protocol) - how Claude Code talks to your tools. A vendor runs an MCP server; you add it with one command; Claude gets that tool's read and write actions. In 2026 the major ops tools all run official, first-party servers - no community glue needed for the core stack.

# Add Slack's official server
claude mcp add --transport http slack https://mcp.slack.com/mcp

# Then inside a session:
/mcp     # shows status, completes OAuth in your browser

# Or from the shell, without opening a session:
claude mcp login slack     # and: claude mcp logout slack

Connections have scopes. Local (the default) is private to you on this project. Project scope writes to a .mcp.json file checked into the repo, so teammates get the same servers with an approval prompt. User scope follows you across projects. There is also a fourth path: connectors you add at claude.ai (Settings, then Connectors) flow into Claude Code automatically when you log in with your subscription - and some Anthropic-hosted connectors like Gmail and Google Calendar only auth that way.

One important property of OAuth-based servers: they scope to the person who connected. The Slack and Notion servers can only see what your account can see, and actions appear as you. That is a feature - your existing permission model carries over.

The source cards: Slack, Notion, Google, transcripts

• Slack - official server at mcp.slack.com/mcp (OAuth). Search messages, files, users, and channels; send messages; read threads; create canvases. Workspace admins approve MCP clients, and MCP activity shows in Slack's audit logs.
• Notion - official hosted server at mcp.notion.com/mcp, OAuth only. Even better: the official claude-code-notion-plugin bundles the server with pre-built skills - install via /plugin. This is the standing habit from the skills lesson: when a vendor ships an official skill, start there instead of building your own.
• Google Workspace - Google ships per-product managed MCP servers (Gmail, Drive, Calendar, Chat), and claude.ai has first-party Gmail, Drive, and Calendar connectors. For Gmail the pattern is always: search and label freely, create drafts, never send.
• Granola - official server at mcp.granola.ai/mcp for meeting transcripts (transcript access needs a paid plan; free covers the last 30 days). Fireflies also ships an official MCP. These feed module two's meeting pipeline.

The classic first job for the Notion connection is migration, not sync: "Export our Notion SOP database to markdown files in playbooks/." That single run bootstraps the brain from wherever your knowledge currently lives. Then Notion stays connected for the things that genuinely live there, and the brain holds the canonical procedures.

A good first Slack job that exercises read and write in one pass: "Summarize #support since yesterday, group by theme, and post the digest to #ops." You will turn that into a scheduled job in module three.

Access boundaries: the three-layer model

Before you connect more tools, set the boundaries. The model from the official docs has three layers: CLAUDE.md shapes behavior, permission rules enforce, hooks and the sandbox guarantee. Permission rules are enforced by Claude Code itself, not by the model - the model cannot talk its way past them.

Rules evaluate deny, then ask, then allow - first match wins, and a deny anywhere beats an allow everywhere. Here is the starter settings file we check into client brain repos.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/credentials*.json)",
      "Edit(/finance/**)",
      "mcp__stripe__create_*"
    ],
    "ask": [
      "Bash(git push *)",
      "mcp__slack__send_*",
      "mcp__gmail__send_*"
    ],
    "allow": [
      "Read(/**)",
      "Edit(/clients/**)",
      "Edit(/meetings/**)",
      "Edit(/reports/**)",
      "mcp__slack__search_*",
      "mcp__notion__*",
      "mcp__granola__*"
    ]
  }
}

• Read(.env) deny blocks env files at any depth - gitignore semantics, and symlink-aware.
• Edit(/clients/**) scopes writes: Claude can edit client folders but not, say, company/policies/.
• MCP rules use the mcp__server__tool pattern: allow mcp__slack__search_* but put mcp__slack__send_* behind an ask. Exact tool names vary by server - run /mcp to list them before writing the rules, then match what you see.
• The cheapest boundary of all is launch location: Claude only sees the directory it starts in. Run client work from clients/acme/, not the repo root, and most cross-contamination is impossible by construction.
• Auto mode is now the starting permission mode for interactive sessions (v2.1.283, September 2026; on Pro, Max, and Team since August): a classifier reviews actions instead of prompting you for each one. That makes the checked-in deny list more important, not less, because it is the part of the boundary that does not depend on a classifier's judgment. Two mechanics to know: the old "default" mode is now labeled Manual, and defaultMode: auto or bypassPermissions in project settings is ignored; set those in user or managed settings. Admins turn auto mode off org-wide with permissions.disableAutoMode.

Use ask rules for the verbs you want a human to see every time: pushes, sends, posts. The prompt takes two seconds and it is the difference between "Claude drafted it" and "Claude sent it." This is the track's standing doctrine - draft, don't send: every outbound artifact the system produces is a draft, a CSV, or a preview for a named human to approve. You will meet it in every module from here on.

Secrets handling

Connections mean credentials, and credentials are where non-engineers most often get burned. The discipline is short enough to memorize.

• The shared .mcp.json supports ${VAR} expansion - the config is committable while each person's keys stay in their local environment.
• Add the Read(.env) and Read(**/credentials*.json) deny rules from above so Claude cannot even read secret files, let alone leak them into output.
• Add a pre-commit secret scan (gitleaks, or a simple hook in .githooks/) as the backstop for human mistakes.
• For anything that will run on a schedule, prefer restricted or read-only API keys over your personal OAuth - module three covers this for finance.
• A key being available is not permission to spend it. Once .env loads into every shell, every paid key (LLM, enrichment, scraping) is always just there. Before any run that costs money, the owner asked for that run or you ask, stating per-unit cost times unit count. Write that sentence into CLAUDE.md verbatim; it is the rule agents most need to read.

Rolling connections out to a team

Everything above works identically for one person or fifteen. What changes with a team is who decides - and writing those decisions down before connection sprawl starts.

Do this now

Sources and further reading

• Claude Code MCP docs
• Slack MCP server
• Notion MCP getting started
• Claude Code permissions docs