How Claude becomes an agent: 3 MCPs + 1 rule
- Gmail — surface area control
Most people think MCP is just “how Claude talks to Notion or Slack”. It isn’t. MCP is the moment your chatbot becomes an agent that actually does things — across your real tools, with your real data.
This video walks through 3 MCP connectors I actually run — and the one rule that decides whether you should add another.
Full transcript
MCP. Most people think it’s just ‘how Claude talks to Notion or Slack’. It isn’t. MCP is the moment your chatbot becomes an agent that actually does things across your real tools, with your real data. Today: three connectors I run, and the one rule for adding more. In 30 seconds. An MCP server exposes a set of tools. Claude sees those tools at runtime — search this, read that, post here — and uses them mid-conversation. Auth lives inside the server, scoped to your account. From Claude’s view: I can search Gmail. Right now. From yours: a clean boundary that you control. That’s the entry level. Today, what really matters — how to choose and how to scope. Connector number one: Gmail. Letting Claude read your inbox sounds risky. And by default, the Gmail MCP server offers a send tool too. We do not enable it. What Claude gets: search, read, list drafts, and create drafts. What Claude does not get: send, delete, label. Here’s the point. This isn’t a Gmail permission restriction. The MCP server provides those tools. We deliberately pick a subset. Drafts go through Claude. Send goes through me. The boundary isn’t in Gmail. It’s in the tool list we expose. That’s MCP purpose number one — surface area control. Connector number two: Notion. Notion in your head is scattered text. Notion in the app is structured databases and hierarchy. Without MCP, Claude sees them as the same thing — a blob of text. With MCP, Claude queries the database directly. Find the meeting note from last Thursday tagged P-R-D — that’s no longer a copy-paste prompt. It’s an actual query. We expose: search, fetch, create page, update page. We hold back: database structural changes, property additions or deletions. Those require human review. That’s MCP purpose number two — turning structure itself into a tool Claude can use. Connector number three: Slack. Why Slack? Because your team’s decision context lives in Slack threads. What did we decide about pricing on Monday — isn’t a memory problem. It’s a Slack search problem. But Slack is also dangerous. Chat tools are where ‘accidental send’ happens. So what we let Claude do: read only. Read channels, read threads, run searches. Send: completely disabled. Context goes in. Statements come from a human. That’s MCP purpose number three — pulling context on demand. Three connectors. Three different jobs. Three different ways of locking it down. But all three follow the same rule. Don’t connect what you wouldn’t audit. What that means: every time you add a connector, ask yourself — if Claude did something unexpected with this, would I notice? Could I check? If the answer is no — don’t enable. Gmail without send: I can audit drafts before they go. Notion without structural changes: I can audit content edits. Slack read-only: I can audit search queries. Every connector you add is one more place Claude can act on your behalf. Add slowly. Audit constantly. MCP isn’t ‘how Claude talks to your tools’. It’s how Claude becomes an agent inside them. Three connectors. One rule. Audit-ready, or unplugged.