What is MCP, and what does it change for your CRM?

MCP, the Model Context Protocol, is an open standard that lets an AI assistant connect to your business systems the same way every time, instead of needing a custom integration per tool. Anthropic released it in November 2024 and it has since been adopted broadly across the industry. In practice it means the work of connecting Claude or another assistant to your CRM stops being a bespoke project and starts being a connection.

If you only needed the definition, that is it. Here is why it matters and where it is oversold.

The problem it solves

Before MCP, every assistant that needed to read your CRM required somebody to build a connection specific to that assistant and that CRM. Then another one for your ticketing system. Then another for your data warehouse. Each one a separate build, separately maintained, breaking separately.

Multiply that across a handful of tools and a couple of assistants and you get the thing every ops lead recognises: a spaghetti of point integrations nobody wants to touch, held together by one person who is currently on annual leave.

MCP replaces that pattern with one protocol. A system exposes what it can do once, in a standard shape, and any assistant that speaks the protocol can use it. Build the connection once instead of once per assistant.

What it actually looks like

Three parts, and it is worth knowing the words because vendors will use them at you.

• The host is the assistant. Claude, or an app you have built.
• The server is the thing wrapping your system. A HubSpot MCP server exposes your portal: read a deal, search contacts, create a note.
• The client is the plumbing between them, which you will never think about.

The server declares what is available and what each capability needs. The assistant reads that declaration and works out what to call. Nobody hand-writes a mapping between the two. The protocol site has the full picture and the specification is readable if you want the detail.

A worked example

Someone asks an assistant: "What is the state of the Acme deal and what should I do before Thursday?"

Without MCP, that is a build. Somebody writes code that authenticates to HubSpot, queries the deal, pulls associated notes and emails, formats it, and hands it to the model. Every new question is more code.

With MCP, the assistant sees that a HubSpot server is available and that it can search deals, read associated activity, and list open tasks. It decides which of those it needs, calls them, and answers. Ask a different question tomorrow and no code changes.

That is the shift. You stop building answers and start exposing capabilities.

Four things it does not do

This is the part the launch posts skip.

It does not fix your data. An assistant reading a portal with three duplicate records for the same company will confidently report on the wrong one. MCP makes bad data more accessible, faster. If your CRM is a mess, this makes the mess arrive quicker.

It does not decide permissions for you. The server decides what is exposed and to whom. Ship one with broad write access and you have handed a language model the ability to change records at scale. That is a design decision and it should be made deliberately and reviewed by someone other than the person who made it.

It is not a product. Nobody buys MCP. It is a standard, like a plug shape. What you buy or build is the server and the thing on the other end.

It does not remove the need for judgement about what to automate. Connecting an assistant to everything is easy now, which makes deciding what it should touch the actual work.

What we would do with a HubSpot portal

Read first, write later. Start with an assistant that can only look: pull a deal history, summarise a company, answer "what happened with this account". Nothing it does can damage anything, so you learn where it is useful and where it is confidently wrong at zero risk.

Then add writes one at a time, each with a bar. Logging a note is low stakes. Changing a deal stage moves a forecast. Sending an email leaves the building. Those deserve different levels of scrutiny and probably a human in the middle for the last one.

And scope the server to the job. The default instinct is to expose everything because you can. Expose what the job needs, which is usually a fraction of it, and you have removed most of the risk before you have written a single guardrail.

Is it worth your attention?

If you are running one assistant against one system, not particularly. Build the integration and move on.

If you are heading towards several assistants across several systems, which most 100 to 300 person businesses are whether they have decided it or not, then yes, and mostly for a boring reason: it makes the connections replaceable. Change your assistant and the servers stay. Change your CRM and only that server is rebuilt. In a category moving this fast, being able to swap one piece without rebuilding the rest is worth more than any individual capability.