Connecting Claude with MCP
Everything so far ran on material you pasted in. The next level is Claude working with your systems directly — reading the CRM, checking the ticket queue, querying the database. The Model Context Protocol, or MCP, is how that happens: one standard way for Claude to use approved tools and data sources, instead of custom wiring for every system. Think of it as a standard port — the company decides exactly which cables exist and who may plug in.
The design question is never "how much can we connect?" It is "which narrowly defined access does a proven workflow require?" — which is why this lesson comes after your workflow already works on pasted data.
The connection model
Four layers, each with its own owner:
- The Claude surface hosts the user experience.
- An MCP server exposes specific tools or resources — "read open opportunities," not "access Salesforce."
- The company system remains the source of truth; nothing is copied out of its home.
- The identity and permission layer decides what this user, through this tool, may touch.
Potential systems include Salesforce, Slack, Google Drive, Jira, and internal databases. One principle governs them all: a connection inherits the user's existing permissions — it never expands them. If Maya cannot see another region's pipeline in the CRM, Claude working for Maya cannot either. The moment a connector becomes a way around existing controls, it is a security incident with a friendly interface.
Design from the task, not the system
For each action a workflow needs, answer six questions:
| Question | Example |
|---|---|
| What must Claude do? | Read open opportunities for one sales region |
| What is the minimum scope? | Selected fields, read-only, active quarter |
| Who may invoke it? | Assigned sales managers |
| What requires approval? | Any update to the CRM |
| What must be logged? | User, tool, record, time, result |
| What happens on failure? | Stop and show the unresolved exception |
Two disciplines from these answers do most of the protective work. Start read-only — reading the pipeline is low-risk and delivers most of the value; writing to it can wait until accuracy is proven. And separate retrieval from action: a tool that reads and a tool that writes are different tools with different approval bars, never one convenient tool that does both.
Enterprise-managed access
Individually configured connectors do not scale past the first enthusiast — and they quietly break the moment that person changes roles. IT and administrators manage eligible connectors through the organization's identity provider and approved Claude controls, so group membership, role changes, offboarding, and periodic access review flow through the same governance as every other system. When someone leaves the sales team, their pipeline access ends everywhere at once — including through Claude.
Practice
Draft the connector brief for your capstone workflow:
- Business purpose and owner
- Systems and the exact data required
- User roles and authentication path
- Read and write permissions, listed separately
- Approval points for consequential actions
- Logging, retention, and the incident owner
If the brief is hard to write, the connection is not ready to build — that difficulty is the review working early, while it is still cheap.
Definition of done
The proposed connection has a clear business need, least-privilege scope, accountable ownership, and a safe response when the tool or source fails — and it grants no one anything they could not already see.