Standalone article · part of a sequenced guide

What you'll unlock: MCP collapses the N×M integration problem to N+M — hosts speak to servers, servers speak to your tools. Design connected workflows with least privilege, human gates on writes, and tests like any production integration.

View full guide New here? Start Chapter 1

Tool guideChapter 7 of 10

MCP — The Extensibility Layer

~95 min read

How Model Context Protocol connects Claude to the tools, systems, and data sources that live outside it — the architecture that turns Claude into a platform

Chapter context

Your team copies between Claude and Slack, Drive, Jira, and Gmail — manual glue that doesn't scale and leaks context.MCP is how you close the loop without building bespoke integrations for every tool pair.

Is this chapter for you?

Do you repeatedly paste data from one SaaS tool into Claude?

Yes — evaluate connector for that system (Concept 2) before next paste.

Are you building AI features that need live customer data?

Yes — compare MCP servers vs API function calling (1.5); security 1.7 mandatory.

Has IT asked what systems Claude can access?

Yes — governance checklist 1.7 + connector allowlist before team rollout.

Do workflows span more than one tool (email + docs + tasks)?

Yes — Concept 3 orchestration patterns and connector combinations 2.8.

Chapters 1 and 6 positioned MCP in the ecosystem and Projects as your OS. Chapter 7 goes deep on Model Context Protocol — foundations, pre-built connectors, and production workflows across your stack.Without MCP, Claude is brilliant but isolated. With MCP, it becomes an orchestrator over Gmail, Drive, GitHub, Notion, and the systems where work actually lives.

Chapter insight

MCP collapses the N×M integration problem to N+M — hosts speak to servers, servers speak to your tools. Design connected workflows with least privilege, human gates on writes, and tests like any production integration.

Reference diagrams

MCP architecture

Host, client, server, external system — credentials stay at the server boundary.

HostClaude appOrchestrate

ClientMCP protocolRoute

ServerConnectorAdapt

SystemSaaS/APITruth

Connected workflow loop

Plan → read tools → human checkpoint → write tools → system of record.

PlanSteps + scopesPrompt

ReadFetch contextLow risk

ReviewHuman QAGate

WriteUpdate systemsControlled

Implementation paths

Foundations → connectors → workflows.

Concept 1

MCP Foundations

What MCP is, why it exists, and the mental model that makes the rest of this chapter make sense

1.1

What MCP is

The open protocol that standardises how Claude connects to external tools, APIs, and data sources

Key takeaway

Model Context Protocol (MCP) is an open standard for connecting AI hosts (like Claude) to external systems through MCP servers — a USB-C for tools and data.

Why this matters

Chapter 1 named MCP as an ecosystem surface. This is how Claude stops being a chat box and starts acting on your stack.

MCP defines how a host application discovers, authorises, and calls capabilities exposed by servers — databases, SaaS APIs, local files, custom business logic.

One MCP server speaks the protocol; any MCP-compatible host can use it — Claude Desktop, Claude.ai connectors, Claude Code, third-party agents.

Workflow — do this next

01List systems Claude should read or write (Notion, GitHub, CRM).
02Check if an MCP server exists in the catalogue (1.6).
03Pilot one read-only connector before write access.

1.2

Why MCP exists

The N×M integration problem — every AI connecting to every tool through bespoke code — and how MCP collapses it to N+M

Key takeaway

Without MCP, each AI × each tool needs custom glue code. MCP makes each tool implement once (server) and each host connect once (client) — N+M instead of N×M.

Why this matters

Platform teams drown in one-off integrations. MCP is the architectural bet on reusable connectors.

Pre-MCP: Notion integration for Product A, different integration for Product B, different auth, different schemas. MCP: one Notion server, many hosts.

For your org: prefer MCP connectors over bespoke scripts when available — maintenance moves to community or vendor.

Workflow — do this next

01Inventory current Claude integrations — custom vs MCP.
02Flag bespoke scripts that duplicate catalogue servers.
03Plan migration where security allows.

Real example

Platform team — integration backlog collapse

Team had 6 internal Slack bots with custom API glue. Adopted MCP Slack server for Claude Desktop pilot — one auth path, shared audit. New tool requests became 'enable MCP server' not 'build integration'.

1.3

How MCP works

Client, server, and host — the three roles and how they interact when Claude calls an external tool

Key takeaway

Host (Claude) runs an MCP client; MCP server exposes tools/resources; client negotiates capabilities, auth, and invokes calls on Claude's behalf.

Why this matters

Confusing host vs server causes wrong security scoping and debugging blind spots.

Host. MCP client. MCP server

Flow: user asks → Claude plans tool use → client calls server → server hits API/DB → result returns to Claude → Claude synthesises answer.

Workflow — do this next

01Draw your stack: host → client → server → system.
02Identify where credentials live (server side, not in prompt).
03Log tool calls in pilot for audit.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

MCP roles (text diagram)

USER → HOST (Claude)
         HOST contains MCP CLIENT
         CLIENT ↔ MCP SERVER (protocol)
         SERVER ↔ EXTERNAL SYSTEM (API/DB/files)

Credentials: server / OAuth — never paste in chat

1.4

MCP tools, resources, and prompts

The three things an MCP server can expose to Claude — and when each is used

Key takeaway

Tools = actions (create issue, send message). Resources = readable data (file, record). Prompts = reusable server-side prompt templates. Pick the right primitive.

Why this matters

Misusing tools for read-only bulk data wastes calls; resources are better for static context.

Tools. Resources. Prompts

Read customer record → resource or tool with get. Create ticket → tool. Standard escalation brief → prompt.

Workflow — do this next

01Classify each integration need: read vs write vs template.
02Prefer resources for large read-only context.
03Wrap writes in tools with explicit confirmation in workflow design.

1.5

MCP vs function calling vs plugins

How the three approaches relate and why MCP is the architecture that generalises

Key takeaway

API function calling is host-defined tools in one app. Plugins were early chat extensions. MCP standardises servers reusable across hosts and vendors.

Why this matters

Teams on API-only think they've 'done tools' — but without MCP they rebuild per app.

Function calling — best for custom product logic. MCP

Many production stacks use both: MCP for SaaS connectors, function calling for proprietary business rules.

Workflow — do this next

01Product backend features → API tools.
02Off-the-shelf SaaS → MCP connectors.
03Document boundary in architecture diagram.

1.6

The MCP connector catalogue

The growing ecosystem of pre-built MCP servers — what's available and how to find it

Key takeaway

Anthropic and partners maintain a growing catalogue — Google, Slack, GitHub, Notion, etc. Search catalogue before building custom servers.

Why this matters

Reinventing published servers wastes engineering and skips security review by maintainers.

Find connectors: Claude.ai integrations settings, Anthropic MCP documentation, community registries (verify source before install). Check enterprise allowlists.

Evaluate: official vs community, read/write scope, OAuth vs API key, last updated, org compliance approval.

Workflow — do this next

01Browse catalogue for your top 3 systems.
02Read permission scope before authorising.
03Pilot in personal Desktop before team rollout.

1.7

Security and permissions in MCP

What it means to let Claude access your systems — auth, scoping, and the audit trail

Key takeaway

MCP access is real system access — scope minimally (read-first), use OAuth where possible, log tool calls, and require human approval for destructive actions.

Why this matters

Connector incidents are data exfiltration or accidental writes — not 'AI hallucination'.

Practices: least-privilege OAuth scopes, separate connectors per environment (prod vs sandbox), no customer PII in prompts when tool can fetch directly, audit logs retained, revoke on offboarding.

Enterprise: IT allowlist of approved servers, DLP review, block write tools until policy signed.

Workflow — do this next

01Read scope screen before clicking Authorise.
02Start read-only; add write after workflow tested.
03Quarterly access review — revoke unused connectors.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

MCP connector security checklist

□ Official or vetted server source
□ Minimum OAuth scopes
□ Sandbox pilot before prod data
□ Write tools require human confirm in workflow
□ Audit logging enabled
□ Offboarding revokes connector access
□ DLP/legal sign-off for customer data

1.8

MCP as a platform strategy

Why building or connecting to MCP servers makes your tools agent-accessible — the distribution implication

Key takeaway

Publishing an MCP server for your product makes you callable from Claude and other MCP hosts — distribution channel for agent-era software.

Why this matters

SaaS without agent interface risks disintermediation. MCP is the integration surface buyers will ask for.

Build MCP server when: customers want Claude/Cursor to act on your product, you need standard integration vs bespoke per customer, API already exists.

Expose read resources first, narrow write tools second, document auth and rate limits — treat like public API launch.

Workflow — do this next

01Map customer 'do this in Claude' requests to MCP tools.
02Spec minimal read-only server MVP.
03List on catalogue / docs when stable.

Real example

B2B SaaS — MCP as GTM

Vendor shipped read-only MCP server for reporting API. Enterprise prospects ran Claude against live dashboards in POC — sales cycle shortened. Write tools gated to admin role with audit.

Concept 2

Connectors — The Pre-Built Integration Layer

The MCP connectors available in Claude.ai — what each does, how to connect it, and how to use it effectively

2.1

Google Workspace connectors

Gmail, Calendar, Drive — what Claude can do with access to your Google stack and how to set it up

Key takeaway

Google connectors let Claude read/search Drive, summarise Gmail threads, read Calendar, and draft emails — OAuth scoped minimally; human sends external mail.

Why this matters

Knowledge work lives in Google for many teams — connector removes download-upload loops and stale exports.

Gmail: search threads, summarise, classify priority, draft replies in Project voice — never auto-send v1. Calendar: list conflicts, propose slots, prep meeting briefs. Drive: search by name/content, read Docs/Sheets/PDFs, summarise folders.

Setup: Claude.ai → Settings → Integrations → Google → OAuth → deselect unused scopes. Test prompts: 'Find [doc] in Drive', 'Summarise thread with [person]', 'What's on calendar Tuesday?'

Combine with Ch 9.2.2 email workflow and Ch 7.3.3 meeting intelligence. Write scopes (draft create) only after read SOP stable.

Workflow — do this next

01Connect Drive first — lowest risk.
02Test: 'Find Q2 strategy doc and summarise'.
03Add Gmail when draft workflow defined — human sends.

Real example

Founder — board prep from Drive + Calendar

Claude pulled board deck from Drive, cross-checked calendar for conflict on board date, listed open questions from last Gmail thread with execs. Founder reviewed 15 minutes instead of 90.

2.2

Productivity and project management connectors

Notion, Asana, Jira, Linear — how Claude reads, creates, and updates your work management systems

Key takeaway

Notion, Asana, Jira, Linear, Confluence connectors ground Claude in live tasks and specs — read default; write with ticket template and human approval.

Why this matters

Stale uploaded exports die overnight; connectors keep truth in the system of record.

Notion: search pages, read databases, create rows (approved). Jira/Linear: fetch issue, sprint summary, create issue from artifact. Asana: task lists and status. Confluence: spec search with page URL cite.

Prompt pattern: 'Cite issue/page ID. Before create/update, show draft fields and wait for confirmation.' Sandbox project for write pilots.

See Ch 7.4.3 for Figma + Atlassian combined workflows. Partner Skills may augment connector (e.g. Notion skill).

Workflow — do this next

01Connect read access to one workspace.
02Ask status questions with ticket IDs.
03Enable create/update only after write SOP exists.

2.3

Communication connectors

Slack, Teams — how Claude accesses conversation history, drafts messages, and surfaces information from team channels

Key takeaway

Slack and Microsoft Teams connectors search channel history, draft posts, and surface decisions — channel allowlists and draft-only default.

Why this matters

Channel noise is huge — scope channels, time windows, and confidentiality in Project instructions.

Slack: search #channels, thread summaries, draft standup posts. Teams: channel read, meeting chat context (per plan). Uses: catch-up, decision archaeology, incident timeline.

Policy: no connector on #hr-confidential, #legal, or M&A channels unless compliance signs. Draft-only — human posts. Redact customer names in external shares.

Workflow — do this next

01Allowlist channels in Project instructions.
02Default to draft-only — human posts.
03Redact external sharing of Slack excerpts.

2.4

CRM and sales connectors

Salesforce, HubSpot — what Claude can do with access to your revenue data

Key takeaway

CRM connectors enable account briefs, pipeline summaries, and draft follow-ups grounded in live opportunity data — PII and accuracy rules mandatory.

Why this matters

Wrong CRM write loses deals and violates process; read-first is default.

Read: opportunity stage, last activity, contacts. Write: log note, update stage — often restricted to sales ops. Never auto-send customer email from CRM tool without review.

Workflow — do this next

01Connect sandbox CRM for pilots.
02Template account brief prompt with cite fields.
03Sales manager approves write tool enablement.

2.5

Developer tool connectors

GitHub, GitLab — how Claude accesses repositories, reviews code, and creates issues

Key takeaway

Git connectors let Claude search repos, read files, summarise PRs, open issues — pair with Claude Code for agentic edits vs read-only review in chat.

Why this matters

Engineering workflows need live repo truth, not pasted snippets.

Uses: 'summarise open PRs', 'find usages of deprecated API', 'draft issue from bug report'. GitLab: merge requests, issues, CI status — same patterns as GitHub. Writes (create issue, comment, MR note) need branch protection culture.

Prefer Claude Code for multi-file changes; GitHub connector for visibility and issue tracking.

Workflow — do this next

01Scope OAuth to required repos.
02Read-only trial on one repo.
03Issue creation template in Project.

2.6

Data and analytics connectors

How Claude connects to databases, BI tools, and analytics platforms

Key takeaway

Data connectors range from read-only SQL/BigQuery to BI exports — SQL injection and row-level security are engineering concerns, not prompt tricks.

Why this matters

Executives ask 'what's the number' — connector must respect ACLs, not bypass them.

Patterns: read-only DB user, predefined queries as tools, BI snapshot resources. File storage: Dropbox, Box connectors (where available) for search/read without manual download — same least-privilege rules as Drive.

Avoid giving Claude arbitrary SQL on production without guardrails.

Always show query or source in output for verification.

Workflow — do this next

01Read replica + read-only creds.
02Whitelist views or saved queries.
03Human validates numbers before decks.

2.7

Setting up your first connector

The step-by-step process for connecting, authorising, and testing an MCP connector

Key takeaway

First connector: pick low-risk read-only → authorise minimum scope → run 3 test prompts → document in Project → expand scope only after pass.

Why this matters

Rushing write access on first connect causes incidents.

Steps: Settings/Integrations → choose connector → OAuth/API key → accept scopes consciously → enable in chat → test retrieval → log failures → add to Project INDEX.

Workflow — do this next

01Choose Drive or GitHub read as first connector.
02Run test suite: find, summarise, cite.
03Document connector + scope in team wiki.
04Revoke and reconnect if wrong scope clicked.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

First connector setup runbook

1. Select connector (read-only preferred)
2. Review OAuth scopes — deselect unused
3. Authorise in sandbox account if available
4. Test prompts (3): find / summarise / cite
5. Add to Project INTEGRATIONS.md
6. Team announcement with do/don't
7. Schedule 30-day scope review

2.8

Connector combinations

The multi-tool workflows that become possible when Claude can access multiple systems simultaneously

Key takeaway

Multi-connector power is orchestration — Claude plans across Gmail, Drive, Notion, GitHub in one thread when hosts allow multiple active servers.

Why this matters

Single-connector thinking underuses MCP; combinations are the productivity jump.

Examples: GitHub issue → Notion spec link → Slack digest. Calendar + Gmail + Drive for meeting prep. Jira + GitHub for sprint review.

Design: explicit workflow prompt naming systems in order; human checkpoint between write steps.

Workflow — do this next

01Enable two read connectors.
02Run one cross-system test workflow.
03Add write on one system only after read chain stable.

Real example

PM — Linear + Notion + Slack

Monday brief: Claude pulled sprint from Linear, spec gaps from Notion, blockers from #eng Slack. One artifact for standup. PM validated IDs — 20 min saved, no manual tab switching.

Concept 3

Building MCP Workflows

Designing end-to-end workflows that use MCP connectors — the production-grade patterns for Claude connected to the real world

3.1

The connected workflow mindset

Thinking about Claude as an orchestrator across your tool ecosystem rather than a standalone tool

Key takeaway

MCP workflows treat Claude as orchestrator: plan → call tools in order → verify → write to system of record — not 'answer in chat and copy-paste'.

Why this matters

Copy-paste from chat defeats connectors — value is closed-loop execution with guardrails.

Shift: deliverable lives in Notion/Drive/Jira, not chat bubble. Chat is control plane; tools are data plane.

Pair with Projects (Chapter 6) for workflow instructions and Chapter 4 prompts for step templates.

Workflow — do this next

01Define system of record per output type.
02Ban 'copy from chat' in SOP when connector can write.
03Human approval at write boundaries.

3.2

The research-to-document workflow

Claude searches the web, reads Drive files, writes a document, and saves it — end to end

Key takeaway

Chain: web search (if needed) → Drive resource fetch → synthesis in artifact → save to Drive doc — with citation and human publish approval.

Why this matters

Research workflows are the most common connected pattern for knowledge workers.

Prompt shell: SOURCE RULES → search if public facts needed → pull internal files via Drive → output markdown artifact → 'prepare Drive create' if write enabled.

Human: verify cites, click save/share. Auto-publish without review forbidden for external docs.

Workflow — do this next

01List internal vs external sources.
02Run dry-run in artifact only.
03Enable Drive write after cite QA passes 3 times.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Research-to-document prompt

WORKFLOW: Research → Document
1. If public facts needed: web search with SOURCE RULES
2. Fetch [Drive paths] via connector
3. Synthesise in artifact — cite each claim
4. Human reviews artifact
5. If approved: create/update Drive doc [folder]

Do not publish externally without human confirm.

3.3

The meeting-to-action workflow

Claude reads calendar, pulls Slack context, attends the briefing, creates Notion tasks, and sends the follow-up

Key takeaway

Pre-meeting: Calendar event + Slack thread summary + Drive agenda. Post-meeting: Notion tasks + draft follow-up email — human sends.

Why this matters

Meetings generate action items that die in notes — connectors push to systems teams actually use.

Pre: 'For event X, pull Slack #channel since yesterday, summarise agenda doc, list open questions.' Post: 'From these notes, create Notion tasks assigned [template], draft follow-up email.'

Workflow — do this next

01Connect Calendar + Slack read.
02Post-meeting template in Project.
03Notion write with task template — manager reviews assignments.

Real example

Product sync — auto task capture

Team ran post-meeting prompt with Notion connector. Claude proposed 8 tasks with owners from thread context. Lead deleted 2, edited 3, accepted 5 — still faster than manual entry.

3.4

The inbox-to-brief workflow

Claude reads Gmail, surfaces priorities, drafts responses, and updates CRM — the executive assistant pattern

Key takeaway

Morning brief: unread priority threads, CRM account context, draft replies in drafts folder — executive approves sends and pipeline updates.

Why this matters

High-leverage pattern for leaders; highest risk for misfire sends — drafts only by default.

Tiers: FYI summary (no draft), respond today (draft), escalate (flag only). CRM update: log call summary as note — not stage change without human.

Workflow — do this next

01Define priority rules in Project (VIPs, keywords).
02Gmail connector → summarise only week one.
03Add draft replies week two — never auto-send.

3.5

The code-to-issue workflow

Claude reviews GitHub, identifies bugs, creates Jira issues, and drafts the fix — the developer workflow

Key takeaway

GitHub read PR/diff → analysis artifact → Jira issue creation with repro steps → optional Claude Code branch for fix PR — human merges.

Why this matters

Connects review, tracking, and implementation without losing audit trail.

Separate read (analysis) from write (issue, PR). Issue body must reference commit/PR link. Fix in branch with CI green before merge.

Workflow — do this next

01Pilot on one repo.
02Template Jira issue fields in prompt.
03Require engineer approval before issue create tool fires.

3.6

Multi-step MCP orchestration

Chaining multiple tool calls in sequence — how Claude reasons about dependencies between systems

Key takeaway

Claude plans tool DAG implicitly — help it with explicit step order, dependencies, and stop conditions in the prompt.

Why this matters

Ambiguous orchestration causes wrong-order writes (update CRM before email sent).

Prompt pattern: 'STEP 1 (read only): ... STEP 2: only if STEP 1 found X ... STOP if missing data.' For API builders, implement explicit state machine; in Claude.ai, rely on clear instructions.

Long chains: break into sub-chats or prompt chain (Chapter 4) with checkpoint artifacts.

Workflow — do this next

01Write numbered steps with inputs/outputs.
02Require Claude to state plan before tool calls.
03Human checkpoint between write steps.

3.7

Error handling in MCP workflows

What Claude does when a tool fails, returns unexpected output, or times out — and how to design for resilience

Key takeaway

Design for failure: timeouts, partial data, permission denied, rate limits — instruct Claude to report error, not hallucinate success.

Why this matters

Silent failure produces confident wrong actions in downstream systems.

Prompt rules: 'If tool errors, stop and report error text. Do not fabricate data. Suggest retry or human.' Log tool failures for connector owners.

Idempotent writes where possible; confirm before duplicate create.

Workflow — do this next

01Test permission-denied path deliberately.
02Add ERROR HANDLING section to workflow prompts.
03Weekly review connector error logs.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

MCP error handling block

ON TOOL ERROR:
- Stop workflow immediately
- Report: tool name, error message, step number
- Do NOT continue to write steps
- Suggest: retry | alternate source | human

ON PARTIAL DATA:
- Label response PARTIAL
- List what was missing

3.8

Testing and debugging MCP workflows

How to validate that connected workflows are working as intended — the quality assurance practice for tool-connected Claude

Key takeaway

MCP QA: sandbox credentials, golden-path tests per workflow, regression after connector scope changes, compare tool output to source UI.

Why this matters

Connectors change APIs; workflows rot without tests like code.

Test matrix: happy path, empty result, permission error, large payload, multi-connector order. Record expected tool calls for golden path.

Debug: check OAuth expiry, scope, rate limit, host connector status, prompt step order.

Workflow — do this next

015 golden tests per workflow in Project.
02Run before and after any scope change.
03Assign workflow owner for failures.

Real example

Ops team — workflow test suite

Three MCP workflows (research-doc, standup brief, incident ticket) each had 5 golden tests in sandbox. Connector upgrade broke Jira field mapping — caught in test run, not production.

Concept 4

Complete Connector & Integration Catalog

Every major connector type — prebuilt, directory, Microsoft 365, design, dev, data, MCP Apps, and enterprise distribution

4.1

Prebuilt first-party integrations

Anthropic-native connectors — Google Workspace, GitHub, Slack, and Microsoft 365 setup and scope patterns

Key takeaway

First-party connectors: authenticate once in Claude.ai/Desktop → minimum OAuth scopes → test read → enable write only with SOP.

Why this matters

These are the default enterprise connectors — teams should standardize on this list before custom MCP.

Google: Gmail, Calendar, Drive. Microsoft 365: Outlook, Calendar, OneDrive, Teams (availability per plan/region). GitHub: repos, issues, PRs. Slack: channels, search, draft posts.

Workflow — do this next

01Integrations settings → connect service.
02Deselect unused scopes at OAuth.
03Run 3-test prompt suite per connector.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

First-party connector matrix

Gmail       | read threads, draft (human send)
Calendar    | read events, propose slots
Drive       | search, read docs, summarize
GitHub      | search code, PR summary, issues
Slack       | channel search, draft message
Microsoft   | mail, files, calendar, Teams

4.2

Microsoft 365 connector — depth

Outlook, Teams, OneDrive, SharePoint — workflows for Microsoft-centric enterprises

Key takeaway

M365 connector grounds Claude in Outlook threads, Teams decisions, and SharePoint docs — critical for orgs not on Google Workspace.

Why this matters

Playbooks skew Google — M365 is half the enterprise market.

Workflows: Teams thread → decision log; Outlook → draft reply queue; SharePoint → policy search with cite. Respect DLP labels — do not exfiltrate restricted sites.

Workflow — do this next

01Connect OneDrive/SharePoint read first.
02Add Outlook draft workflow with HITL.
03Teams: allowlist channels in Project.

Real example

Enterprise PM — Teams + SharePoint brief

Claude pulled PRD from SharePoint, summarized #product Teams debate, drafted stakeholder email. PM verified SharePoint version ID — 30 min Monday brief vs 2 hours.

4.3

Design & Atlassian connectors

Figma, Notion, Jira, Confluence, Linear — specs, design handoff, and ticket workflows

Key takeaway

Figma MCP/skills for design context; Notion for docs; Jira/Linear for tickets — combine for spec-to-ticket pipelines with human approval on writes.

Why this matters

Product/engineering glue is these four systems — connectors must be documented together.

Figma: read frames/comments for implementation briefs. Notion: search pages, create database rows. Jira/Confluence: ticket context, spec search. Linear: sprint status. Partner skills may augment MCP.

Workflow — do this next

01Read Figma + Notion in research thread.
02Create Linear/Jira issue only after spec approval.
03Link artifact URLs in ticket body.

4.4

CRM, support & revenue connectors

Salesforce, HubSpot, Intercom, Zendesk — account intelligence and support workflows

Key takeaway

CRM/support connectors: account briefs, ticket summarization, draft replies — PII rules and sandbox pilots mandatory.

Why this matters

Customer data + AI without connector discipline causes compliance incidents.

Salesforce/HubSpot: opportunity context, activity timeline. Zendesk/Intercom: ticket thread summary, suggested response — agent reviews before send. Log connector access for audit.

Workflow — do this next

01Sandbox CRM for pilot.
02Redact customer PII in prompts when possible.
03Manager approves write tools.

4.5

Data warehouse & BI connectors

BigQuery, Snowflake, Databricks, Postgres — read-only analytics and governed query patterns

Key takeaway

Data connectors: read-only roles, predefined views, query in output for verification — never production write creds in Claude host.

Why this matters

Ad-hoc SQL from LLM on raw production DB is a data breach waiting to happen.

Patterns: semantic layer views, saved queries as MCP tools, row-level security enforced at DB. Output includes SQL + row count + caveats.

Workflow — do this next

01Create claude_readonly DB user.
02Expose views not raw tables.
03Analyst validates SQL before exec if manual.

4.6

Automation & iPaaS connectors

Zapier, Make, and custom webhooks — when MCP bridges to existing automation stacks

Key takeaway

Zapier/Make MCP servers expose thousands of apps — use for long-tail integrations; prefer first-party MCP when available for tighter auth.

Why this matters

Not every SaaS has first-party MCP — iPaaS fills the long tail at maintenance cost.

Use for: niche SaaS, legacy internal APIs wrapped as Zapier actions. Avoid: duplicating first-party connector with fragile Zap chain.

Workflow — do this next

01Check Connectors Directory first.
02If missing, evaluate Zapier MCP with least actions.
03Document zap ownership and failure alerts.

4.7

MCP Apps, Bundles & Desktop Extensions

Interactive UI in chat, MCPB distribution, and enterprise desktop extension rollout

Key takeaway

MCP Apps render charts/forms/maps in chat. MCP Bundles (MCPB) package local servers for Desktop Extensions gallery — IT-friendly distribution.

Why this matters

Text-only tool results underserve exec dashboards and form approvals — MCP Apps close the gap.

MCP Apps MCPB: signed bundles with deps for enterprise Desktop deployment. Local npm servers → package as MCPB or plugin, not directory-listed raw.

Workflow — do this next

01Pilot one MCP App connector in sandbox.
02IT tests MCPB install via MDM.
03Version pin bundles like production deps.

4.8

Connectors Directory & team governance

Verified third-party servers, allowlists, custom remote MCP, and plugin directory submissions

Key takeaway

Connectors Directory = vetted third-party MCP. Teams publish ALLOWLIST.md, vet custom servers, submit internal plugins to directory when ready.

Why this matters

Ungoverned connector sprawl is the MCP era's shadow IT.

Process: security review → pilot → allowlist → document scopes → quarterly recertify. Custom remote MCP for internal APIs — OAuth, audit log, rate limits required.

Workflow — do this next

01Maintain CONNECTORS_ALLOWLIST.md.
02Block unlisted servers on managed devices.
03Recertify on OAuth scope changes.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Enterprise connector allowlist template

| Connector | Type | Read/Write | Owner | Review date |
|-----------|------|------------|-------|-------------|
| GitHub    | 1st party | R/W | Eng | 2026-09 |
| Salesforce| Directory | R | Sales Ops | 2026-06 |
| Internal CRM MCP | Custom remote | R | Platform | 2026-07 |

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

MCP workflow charter

One page per connected workflow before production.

WORKFLOW NAME:
SYSTEMS (read/write):
CONNECTORS + SCOPES:
HUMAN GATES:
SYSTEM OF RECORD:
GOLDEN TESTS (5):
OWNER:
ERROR HANDLING: [link block 3.7]
LAST TESTED:

Team connector allowlist

APPROVED CONNECTORS:
| System | Server | Read | Write | Owner |
|--------|--------|------|-------|-------|
| Drive  | Google | ✓    | ✓*    | IT    |

*Write requires workflow charter + manager approval
BLOCKED: [list]
REVIEW: quarterly

MCP roles (text diagram)

USER → HOST (Claude)
         HOST contains MCP CLIENT
         CLIENT ↔ MCP SERVER (protocol)
         SERVER ↔ EXTERNAL SYSTEM (API/DB/files)

Credentials: server / OAuth — never paste in chat

MCP connector security checklist

□ Official or vetted server source
□ Minimum OAuth scopes
□ Sandbox pilot before prod data
□ Write tools require human confirm in workflow
□ Audit logging enabled
□ Offboarding revokes connector access
□ DLP/legal sign-off for customer data

First connector setup runbook

1. Select connector (read-only preferred)
2. Review OAuth scopes — deselect unused
3. Authorise in sandbox account if available
4. Test prompts (3): find / summarise / cite
5. Add to Project INTEGRATIONS.md
6. Team announcement with do/don't
7. Schedule 30-day scope review

Research-to-document prompt

WORKFLOW: Research → Document
1. If public facts needed: web search with SOURCE RULES
2. Fetch [Drive paths] via connector
3. Synthesise in artifact — cite each claim
4. Human reviews artifact
5. If approved: create/update Drive doc [folder]

Do not publish externally without human confirm.

MCP error handling block

ON TOOL ERROR:
- Stop workflow immediately
- Report: tool name, error message, step number
- Do NOT continue to write steps
- Suggest: retry | alternate source | human

ON PARTIAL DATA:
- Label response PARTIAL
- List what was missing

First-party connector matrix

Gmail       | read threads, draft (human send)
Calendar    | read events, propose slots
Drive       | search, read docs, summarize
GitHub      | search code, PR summary, issues
Slack       | channel search, draft message
Microsoft   | mail, files, calendar, Teams

Enterprise connector allowlist template

| Connector | Type | Read/Write | Owner | Review date |
|-----------|------|------------|-------|-------------|
| GitHub    | 1st party | R/W | Eng | 2026-09 |
| Salesforce| Directory | R | Sales Ops | 2026-06 |
| Internal CRM MCP | Custom remote | R | Platform | 2026-07 |

Product-led growth team — MCP workflow stack

A PLG team lived across Gmail, Notion, Linear, GitHub, and Slack. PMs exported CSVs into Claude. Context was stale; actions never made it back to tools.

Before

No connectors. Manual copy-paste. No audit. Sales and product data diverged.

After

MCP rollout: read connectors week 1, three chartered workflows (research-doc, standup brief, code-to-issue), write gates on Linear/GitHub. Project per initiative with INTEGRATIONS.md.

Manual export time → down 65%
Action items captured in Notion/Linear → up from ~40% to ~92%
Connector security incidents → 0 (read-first policy)
Workflow regression caught in test → 1 before prod (Jira mapping)

What goes wrong

Full write scopes on day one — accidental mass updates.

Read-first setup 2.7; human gates on writes 3.1.

Treating tool output as verified truth.

Spot-check against source UI; citation rules Chapter 4.

No workflow tests after connector upgrade.

Golden tests 3.8; run on any scope change.

Building custom server when catalogue connector exists.

Catalogue first 1.6; build only for proprietary systems.

Vetted by Krishna KumarCurator, FactorBeam

Discussion

Discussion coming soon

Shared comments for this playbook are not live yet. When they are, you'll be able to ask questions, share what worked, and see replies from other readers.