MCP in plain English, connecting your existing tools to Claude without rebuilding anything

Most weeks an operator comes to us with the same brief: we have an AI tool that almost works, but it cannot see our data.

Their CRM is full of leads the AI cannot read. Their helpdesk has tickets the AI cannot answer about. Their order system has the orders the AI cannot reference when a customer asks "where is mine." The AI is fluent and useless at the same time.

The thing that fixes this, in 2026, is MCP. And the thing nobody is telling you is that wiring it up is the easy part. The hard part is deciding what to expose and how.

What MCP actually is

MCP is the Model Context Protocol. Anthropic shipped it to standardize how a model talks to an external tool, a database, or an API. Think of it as a universal adapter cable: instead of every AI tool inventing its own way to query your CRM, MCP says "here is the cable. Build it once. Plug it into anything Claude-shaped."

In practice, MCP looks like a small server. The server exposes a set of tools, search_customer, get_open_orders, create_ticket, and Claude can call them as if they were native model abilities. You do not write prompts that say "imagine you have a customer database." You give Claude the actual database, mediated by a server you control.

Three things follow from that:

1. The model can read your real data, not a pretend version
2. You control what it sees and what it can change
3. You can audit every call, because every tool invocation goes through your server

That third one is the part most operators do not internalize until they see it in production. MCP makes AI auditable.

Where MCP fits, in plain English

If you are running a business that is not a dev shop, here is the translation:

You have software your team uses every day. A CRM, a ticketing system, an order management system, a calendar, an inventory tool. Things with logins and dashboards.

You want an AI that can help your team use that software faster. Not a chatbot bolted on to the side. An AI that knows the customer's history when it answers, knows the current backlog when it triages, knows the inventory when it quotes.

MCP is the wire that connects the AI to that software. Without it, the AI is making things up or you are pasting things into a prompt manually. With it, the AI is reading from the same source of truth your team is.

The reason MCP matters now, more than the previous attempts at the same idea, is that Anthropic has standardized it and the connector ecosystem is real. We do not have to build a custom integration for every tool any more. We pick from a catalog, plug it in, configure permissions.

What we look for before we wire it up

When a client says "we want to connect our CRM to Claude through MCP," our first questions are not technical. They are operational.

Who is allowed to ask what. An AI with read-access to your CRM is great. An AI with delete-access to your CRM is a liability waiting for somebody to type a bad prompt. We map permissions before we write any code.

What the AI should not see. PII fields, salary data, internal-only notes, draft contracts. There is always a "do not surface this to the AI" list. We define it explicitly, not implicitly.

Where the call gets logged. Every MCP invocation should produce a log entry that says "Claude on behalf of user X called tool Y with arguments Z at time T." For most clients, that log goes to whatever observability stack they already have. For regulated clients, it goes to a tamper-evident store with retention.

What happens when the AI gets it wrong. No agent is right 100% of the time. We define the unhappy paths up front: when does the AI escalate to a human, when does it apologize and stop, when does it retry, and what does the user see in each case.

Who owns the MCP server. If we build it, we hand it back with documentation. If we host it on retainer, that is its own engagement shape. If your internal team owns it, we do training. Whoever owns it is the same person who handles permission changes, which means it cannot be ambiguous.

This is the part that distinguishes a real MCP integration from a demo. The demo is easy. The integration that survives six months in production is the one where these five questions were answered before anything got wired.

A real-world shape

A retailer we are scoping with has a Shopify storefront, a Klaviyo email platform, and an internal customer service desk built on Zendesk. They want a Claude-based assistant that can answer customer questions about "where is my order" or "can I exchange this" without a human reading the email first.

The MCP build looks like this:

• A connector to Shopify Admin API (orders, customers, refunds, returns)
• A connector to Zendesk (open tickets, ticket history, customer profile)
• A connector to Klaviyo (subscription status, recent campaigns)
• Read-only by default. Write actions (issuing refunds, sending custom emails) require a human approval step

The agent never gets to fire a refund autonomously. It gets to draft one, surface it to the support team, and let a human approve in one click. That is a meaningful workflow reduction without exposing the business to an autonomous AI making payment decisions.

Three weeks to build, two weeks to evaluate against real ticket history, two weeks of soft launch with one support agent. By week eight, the team is processing twice the volume with the same headcount and the agent has handled 2,000 tickets with zero refund mistakes.

The reason this works is not the AI. It is the wiring. MCP gave us the predictable, auditable connection between Claude and the three systems that hold the customer reality.

What this is not

MCP is not magic. It will not make a poorly defined process into a clean one. If your CRM is full of duplicate records and stale notes, Claude reading from it will be confidently wrong. We have walked away from engagements where the data hygiene problem was the actual problem and AI was a distraction from fixing it.

MCP is also not the only way to wire a model to your data. OpenAI's function calling and the Responses API do similar work with a different shape. Google's Vertex AI Agent Builder has its own connector model. We pick MCP when the integration needs to be Claude-flavored and standardized; we pick OpenAI's tool-calling when the team is already on GPT and the orchestration is simple; we pick Vertex when compliance or multimodal reasoning is the constraint. Same goal, three implementations.

MCP is also not the right tool for every integration. If you need real-time bidirectional sync, say, the AI and your CRM both updating the same record without locking, you want a database-level integration, not an MCP tool. If you need offline access, you want a different architecture entirely.

The way we think about it: MCP is great for workflows where the AI is a helpful agent on top of human-owned systems. It is not for workflows where the AI is the system of record.

What this means for you, today

If you have a CRM, a ticketing system, an order management platform, or a calendar, and you have been wanting an AI that can actually help your team use those tools. MCP is now the right shape of project, and we can scope it in an hour.

Book a consultation · Read the approach