Jonathon's AI Wiki

Module 3 — Connecting Claude to Your Tools

18 min read

Source: wiki synthesis: skills-vs-mcp-vs-plugins, essential-mcp-servers, skills-mcp-synergy, surfaces-decision-framework, Intro Module 6

Time: Read 12 min | Watch 20 min | Practice 45 min — total ~75 min

Watch First

Two short videos before you read the rest of this module. Both are linked from intro Module 6 and worth re-watching with intermediate eyes — you’re past “what is a Skill” and into “which shape do I pick.”

If you only have time for one, watch the second one. It shows the actual surface of what we’re talking about.

Why It Matters at WEO

Claude is only as good as what it can see. A blank-slate model is a writing assistant. A model with read access to a client’s brief in Drive, the campaign schedule in Calendar, and the content library in Notion is a working teammate. The lift compounds with each integration.

The catch: every tool you connect is another door into your data — and into your client’s data. A badly-scoped Connector or a third-party MCP server installed without thinking about scope can expose information that has contractual, regulatory, and (for patient-adjacent dental marketing work) patient-safety implications.

That’s why this module spends time on choosing what to install — not just how to install it. Knowing how to evaluate a tool integration is a core intermediate skill, even if your team’s actual approval process is handled by someone else.

Section 1 — The Three Shapes (MCP / Connectors / Skills)

Three different things get conflated in casual conversation. They do different jobs. The kitchen analogy from Skills vs MCP Servers vs Plugins is the cleanest way to remember which is which.

Skills — recipes and playbooks

A Skill is a markdown file (sometimes with a folder of supporting scripts) that tells Claude how to do a task. Think recipe card: “When the user asks for a dental landing-page audit, follow these eight steps, use this rubric, output in this format.”

  • No external runtime. A Skill is just instructions Claude reads when triggered.
  • No data access by default. A Skill cannot read your Drive on its own.
  • Composable with other shapes. A Skill can invoke a Connector or MCP tool that’s already authorized — but the data access lives in the Connector/MCP layer, not in the Skill.
  • Where they live. Anthropic-curated Skills are in the public Skills marketplace. Custom Skills live in your project repo (.claude/skills/) or in a Skill bundle published internally.
  • Examples relevant to WEO: the Marketing Skills Bundle (copywriting, ad creative, SEO audit, email sequence), the Smile Springs voice-guide Skill, the WEO blog QA Skill.

If the question is “I want Claude to be more consistent at this thing I do every week,” the answer is usually a Skill.

Connectors — first-party plugs

A Connector is an Anthropic-maintained integration with a SaaS app. Gmail. Drive. Slack. GitHub. Linear. Notion. The full list is in your claude.ai settings pane and grew past 50 by early 2026 (intro Module 6 has the category breakdown).

  • OAuth-based. You authorize the Connector with your account credentials; Claude gets a scoped token.
  • Read or read-write per scope. Drive read-only ≠ Drive read-write. Pay attention to the scope on install.
  • Maintained by Anthropic. Schema changes, auth refreshes, rate limits — Anthropic keeps the integration working. You don’t.
  • Where they live. Pre-installed in the claude.ai surface (when enabled by your admin); also available in Claude Desktop, Claude Cowork, and Claude Code via the same auth flow.

If the question is “I want Claude to read or write data in a SaaS tool we already use,” the answer is usually a Connector — if one exists for that tool.

MCP servers — the generic outlet

MCP (Model Context Protocol) is an open spec for tool servers. Anyone can build one. Anthropic publishes the protocol; the ecosystem builds the servers.

  • Open protocol. A first-party Connector and a third-party MCP server look identical to Claude — the protocol is the same. Connectors are mostly just MCP servers Anthropic wraps with first-party auth and UX.
  • Anyone can build one. Tavily (web research), Context7 (current library docs), Cloudflare’s MCP suite, Sentry’s error context, and dozens of others are third-party MCP servers.
  • You run the auth. Most third-party MCP servers want either an env var (API key) or a self-hosted OAuth callback. You manage the credential. You manage rotation.
  • Where they live. Configured in .mcp.json for Claude Code, or installed via the Desktop/Cowork plugin pane.

If the question is “I want Claude to read or write data in a tool that doesn’t have a Connector yet,” the answer is usually an MCP server. If the question is “I want Claude to access a specialty data source that no SaaS app covers” (live web search, current docs, geospatial, blockchain) — also MCP.

Decision tree (memorize this)

Need to teach Claude HOW to do something? → Skill. Need Claude to read or write data in a SaaS app?     → First-party Connector exists? → Connector.     → No Connector? → Third-party MCP server. Need both a methodology AND a data source? → Both. Skill orchestrates the Connector/MCP call. See Skills-MCP Synergy.

Common misconceptions to call out

  • “Skills can read my Drive.” No. A Skill is text instructions. Only Connectors or MCP servers move data. A Skill that says “read the brief from Drive” works only when a Drive Connector is already authorized in that surface.
  • “MCP and Connectors are different things.” Mostly false. Connectors are MCP under the hood — Anthropic just wraps the auth and UX so you don’t have to manage tokens. The difference is who maintains the server and who handles auth.
  • “Installing a Skill exposes my data.” No. A Skill installed without any data Connectors authorized has nothing to expose. It’s a recipe with no kitchen access.
  • “All MCP servers are equally trustworthy.” Definitely false. A first-party Connector goes through Anthropic’s review. A third-party MCP server is whatever the publisher decides it is. This is the reason most teams gate tool installs through some kind of vetting process.

Surface awareness — and Cowork in particular

Which surface you’re using changes which integrations are even available. See Surfaces Decision Framework for the full breakdown:

  • claude.ai web — the chat surface. Connectors yes; Skills (some, via .skill upload); third-party MCP no (without enterprise plumbing). Where most marketing work happens today.
  • Claude Desktop — same chat experience as web with more local hooks. Connectors yes; Skills yes; third-party MCP yes via the plugins pane.
  • Claude Cowork — file-and-folder native rather than chat-native. You point Cowork at a directory (a project folder, a client workspace, a brand asset library) and Claude works on the files in place — read, edit, generate new files, organize, summarize across them — without copy/pasting content into a chat. Connectors yes; Skills yes; third-party MCP yes. Cowork’s flagship intermediate feature is Dispatch: send Claude off to work autonomously on a task in its own desktop workspace, then come back later for the result. Operator-track folks who want multi-step async work without learning Claude Code should look at Cowork first. Module 5 covers Dispatch in depth.
  • Claude Code — terminal-based, scriptable, the most flexible surface. Connectors yes; Skills yes; third-party MCP yes via .mcp.json. Builder-track territory; Module 6 covers it.

If a teammate says “the Tavily MCP isn’t working in my chat,” your first question is “which surface are you on?” If it’s plain claude.ai web, third-party MCP isn’t available there. The mental model: the surface determines the ceiling on what Claude can do.

Plan tier matters too

Most intermediate Claude features are gated by plan tier. Quick map:

  • Claude Free / Pro (individual). Personal use. Connectors yes (limited list). Skills yes. Cowork yes. Memory yes. Third-party MCP available on Desktop / Cowork / Code surfaces. Not appropriate for ongoing client-confidential work — no team admin layer means no centralized governance over who uses what.
  • Claude Team plan. The right tier for an agency operating under shared governance. Admin-managed Connectors (admins enable or disable which Connectors team members can use), centralized billing, shared usage analytics, larger MCP per-tool result-size cap, Cowork team-wide, and access to Routines / Scheduled Tasks / Channels (covered in Module 5). The admin layer is the actual value — every individual Pro account is otherwise its own audit surface.
  • Claude Enterprise. Adds SSO, audit logs, custom retention policies, admin-managed governance APIs. The right tier when client contracts require formal data-handling commitments.

If your team is on a mix of individual Pro accounts, that’s a flag to raise with your lead. The Team plan’s admin layer pays for itself the first time a teammate’s role changes and you need to revoke their Connector grants in one place.

Section 2 — Choosing What to Install

The decision to install any Claude tool integration has five dimensions you should think through up front, regardless of how your team approves things. Most “obviously safe” installs that turn out badly skipped at least one of these.

The five dimensions

1. What data does the tool touch? Read-only or read-write. One folder or all of Drive. One repo or the whole org. The smallest scope that lets you do the job is the right scope — Claude can’t constrain itself to a smaller subset later, and a Connector you authorized for “all of Drive” can read everything in your Drive whenever Claude calls it.

2. What’s the auth model?

  • First-party Connector — OAuth, scoped to your account, refreshes managed by Anthropic. Easiest model.
  • Third-party MCP server — you manage the credential. Often an env var (API key); sometimes a self-hosted OAuth callback; occasionally anonymous. You handle rotation.
  • Custom MCP server — your team builds the server. You manage everything.

The auth model shapes how revocation works. First-party Connectors revoke through the Connectors pane. Third-party MCP credentials revoke at the source service (rotate the key, regenerate the token). Knowing where the credential lives matters when a teammate changes roles.

3. Where does the data go? Your prompts and the tool’s responses pass through whichever Claude surface you’re using (claude.ai, Desktop, Cowork, Code). Anthropic logs prompts per their data policy. The tool itself may also log requests on its side — most third-party MCP servers log requests for debugging, often with a 30-day retention window. For client-confidential data, both sides matter.

4. What does it cost? Per-seat, per-call, free with limits. Most first-party Connectors are included in your Claude plan. Most third-party MCP servers have a free tier with rate limits and a paid tier above that. Tavily is free up to 1,000 searches/month; Context7 is free; many Cloudflare MCPs are free; some specialty servers (Apollo.io, Salesforce-style) charge per call.

5. Does it actually fit? The cleanest test: write down the three prompts you’d run with this tool in a normal week. If you can’t list three, you don’t need the tool yet — you’re scratching an itch, not solving a workflow. Many “I want to try this” requests fail this test, and the install would just be a credential left lingering.

If your team has an approval process, run these answers through it

Different teams handle tool approvals differently — some have a formal intake and a review committee, some require a quick lead approval, some leave it to individual judgment. Whatever your process, the five dimensions above are what you should have answered before installing. If your team’s process isn’t finalized yet, those five answers are a reasonable starting checklist.

Worked example — installing a Drive Connector for Smile Springs

Mel wants Claude to read the Q2 brief from Drive and help draft patient-reactivation outreach. The walk:

  1. Decide the shape. First-party Drive Connector exists. → Connector.

  2. Decide the scope. Read-only on the specific folder /clients/smile-springs/2026-q2/, not all of Drive. The folder share is already in place from the client.

  3. Authorize. In the Smile Springs Project on claude.ai, click Connectors → Drive → connect → in the Google OAuth dialog, choose the specific folder when prompted. Same flow for Gmail (compose-only scope, no send).

  4. Run a real prompt. “Pull smile-springs-q2-brief.docx. Summarize the three highest-priority campaign messages. Then draft a patient-reactivation outreach email for adult patients aged 35–55 who haven’t booked in 12+ months. Use the warm-and-trustworthy voice in the brief. Include a disclosure footer noting the email was drafted with AI.”

  5. Review and edit. Claude returns the campaign messages and a drafted email. The email closes with the disclosure footer:

    This email was drafted with Claude (AI) — please review carefully before sending.

    Mel reviews, edits the subject line, removes one sentence that overemphasized Saturday appointments (Smile Springs offers weekday and Saturday slots — Claude picked up the Saturday cue from the brief and overcompensated), and saves it as a Gmail draft. Send is manual, after a human re-read.

That’s the install + first-use chain. Two integrations, one disclosure, no surprises.

A note on disclosure

If Claude drafts a client-facing email, social post, or any external comm, include a disclosure footer noting AI involvement. It’s good practice for transparency and it makes the human review step explicit (“read this, don’t send blind”). Most agencies have a specific disclosure phrase — use yours.

Section 3 — Troubleshooting MCP Failures

When you start using MCP servers and Connectors regularly, things break. Tokens expire. Schemas drift. Rate limits hit. Here are the five failure modes you’ll see most often, what they look like in chat, and what to do.

1. Auth expired

Looks like: “I tried to call gmail.search_threads but the request returned 401 Unauthorized.” Or Claude says “I can’t access your Drive right now — please re-authorize the connector.”

Why: OAuth tokens have a TTL. Drive tokens last around an hour for short-lived sessions; refresh tokens longer but they also expire (often 90 days). Token refresh sometimes fails silently when the upstream rotates a credential.

Recovery: Open the Connectors pane, click “Reconnect,” step through the OAuth dialog, retry the prompt. Takes 30 seconds. If reconnect fails repeatedly, open a ticket with IT — it’s usually an admin-level OAuth grant problem, not a user issue.

2. Scope denied

Looks like: “I called the Drive read tool but got insufficient_scope for the file you specified.” Or Claude does part of a task then stops with “I can’t write to that doc — my current Drive scope is read-only.”

Why: You authorized a narrower scope than the task needs. Common when a request was originally Tier 1 read-only but later grows into a Tier 2 read-write workflow.

Recovery: Don’t quietly self-promote scope. Re-run the OAuth flow with the broader scope you actually need — that’s an explicit re-authorization, not a silent expansion. If your team has a tool-approval process, run the scope change through it first.

3. Rate-limited

Looks like: “The Tavily MCP returned 429 Too Many Requests — please retry in 60 seconds.” Or Claude trying to read 30 Drive files in one prompt and stalling halfway through.

Why: Most APIs cap requests per minute or per day. Tavily defaults to 1000 requests/month on the free tier; Drive caps API reads per second per user. Bulk operations hit limits fast.

Recovery: Three options.

  • Back off. Wait the cooldown window, retry.
  • Batch. Ask Claude to operate in smaller chunks — “read 5 files at a time, summarize, then continue with the next 5.”
  • Upgrade. If the rate limit is structural (you legitimately need more), the integration may need a paid tier — flag the cost to whoever runs your tool budget.

4. Schema mismatch

Looks like: Claude returns “the response from notion.search_pages doesn’t include the last_edited field I expected — the schema may have changed.” Or output looks malformed: missing keys, wrong nesting, fields that used to be strings now objects.

Why: SaaS APIs change. Notion adds a field. Slack restructures a response. The MCP server’s schema (or the Skill calling it) was written against the old shape.

Recovery: Two paths.

  • First-party Connector? Anthropic usually catches schema drift within days. File a bug via the Connector pane. Wait, retry.
  • Third-party MCP? Update the server (npm update, pip install --upgrade) or update the Skill that calls it. If the Skill encodes specific field names, those need a quick edit.

5. Tool selection ambiguity

Looks like: Claude says “I have both a Drive read tool and a Notion read tool — should I use Drive or Notion to find the brief?” Or worse, silently picks the wrong one and returns content from a stale doc.

Why: When multiple tools could plausibly answer the same question, Claude picks the highest-confidence match. Sometimes it picks wrong.

Recovery: Force-name the tool in your prompt.

  • Bad: “Pull the Smile Springs brief.”
  • Good: “Pull the Smile Springs brief from Drive, file smile-springs-q2-brief.docx.”
  • Better: “Use the Drive Connector to read the file at /clients/smile-springs/2026-q2/smile-springs-q2-brief.docx.”

For repeated workflows, encode the tool selection in a Skill so you don’t have to spell it out every time.

Common Anti-Patterns

  • Installing a third-party MCP server without thinking through scope. Even if you uninstall it that afternoon, the credential — and any data it touched — is in the wild. Decide what data the server should see before you authorize, not after.
  • Over-scoping “just in case.” If you ask for read-write on all of Drive when you really need read-only on one folder, you’re carrying risk you didn’t need. Request the minimum scope from the start.
  • Skipping the AI disclosure on client-facing emails. If Claude drafts a message that goes to a client, include a disclosure footer. Transparent is faster than retroactive cleanup.
  • Letting old credentials linger. When a teammate’s role changes or a project ends, revoke the OAuth grants. Stale credentials are exactly the kind of thing audits flag.

Key Takeaways

  • Three shapes, three jobs. Skills teach Claude how; Connectors and MCP servers give Claude what to act on. They compose; they’re not interchangeable.
  • Connectors are MCP under the hood. The difference is who maintains the server and who handles auth.
  • Surface determines availability. Third-party MCP servers don’t run in plain claude.ai — know which surface your teammate is asking about before troubleshooting.
  • Five dimensions before installing any tool integration: what data it touches, the auth model, where data goes, cost, fit. If your team has an approval process, run them through it.
  • Disclosure on AI-drafted client-facing comms. Generic best practice; non-negotiable in regulated domains.
  • Credentials need lifecycle management. When teammates change roles or projects end, revoke the OAuth grants.

Try It

[Both] Walk the decision (~30 min)

  1. Pick one tool you use weekly. Drive, Slack, Gmail, GoHighLevel, Notion, Linear — anything. Pick the one where you most often think “I wish Claude could just see this.”
  2. Identify which shape it should be. First-party Connector exists? → Connector. No Connector? → MCP server. Just a methodology? → Skill. Use the decision tree from Section 1.
  3. Walk the five dimensions. What data does it touch? What’s the auth model? Where does the data go? What does it cost? Does it fit your actual workflow (can you list three prompts you’d run with it next week)?
  4. Identify the smallest scope that gets the job done. Be specific — folder, channel, repo, mailbox. The smallest scope that lets you do the work is the right answer.
  5. Write the prompt. What’s the first prompt you’d run if this integration were live tomorrow? Specific, with file paths or channel names where relevant.

If you got stuck — especially on scope or data sensitivity — you found the right place to ask for help. Bring those questions to your manager or whoever runs your team’s tool-approval process.

[Builder] Wire one MCP server into Claude Code (~45 min, optional)

  1. Pick one third-party MCP server. Tavily (web research), Context7 (current docs), or Cloudflare’s MCP suite are common starting points. Confirm with your lead which servers your team has approved before you install.
  2. Add it to your project’s .mcp.json. Most servers document the exact JSON snippet. Save the config in the project repo.
  3. Document what auth pattern it uses. Env var (API key)? Self-hosted OAuth? Anonymous? Note it in your project’s CLAUDE.md so future-you (or another teammate) doesn’t have to figure it out.
  4. Run one successful tool call. Open Claude Code, ask a question that exercises the new server (Use Tavily to find the top 5 dental SEO articles published in 2026). Confirm the response includes data from the MCP server, not Claude’s training data.
  5. Document the scope. What can this server read? Write? Note it next to the auth pattern in CLAUDE.md.

When you’re done, you should be able to answer for any installed MCP server: who maintains it, what auth it uses, what scope it has, what tool names it exposes, and where the credential is stored.

Done? Move on to Module 4.

Graph View

Backlinks