If you hang out in r/msp, you have seen the threads. “MCP in MSP.” “Unofficial ITGlue MCP server.” “How are you handling AI usage for clients?” The conversation has tipped past the curious stage and into the “I need to have an answer for my clients” stage.

Here is the short, honest read on what MCP is, why it is relevant to service delivery, and where it fits if you are running HubSpot portals for clients.

What MCP actually is

MCP - Model Context Protocol - is a thin standard for how AI assistants connect to tools. If you have used Claude Desktop and plugged in a filesystem server, a database server, or a HubSpot server, you have used MCP. The AI talks to the server, the server talks to the tool, and you get real actions instead of a chat that just guesses.

That is the entire concept. It is deliberately boring. The value comes from the fact that the same AI assistant can now talk to dozens of tools through the same protocol, without you wiring a bespoke integration for each one.

Why it matters for MSPs

Three reasons that actually show up in practice.

First, service delivery gets faster. A technician sitting in their AI assistant with MCP wired into a client’s HubSpot, their ITGlue, and their M365 tenant can answer “which users in this client have not logged in for 60 days and have no HubSpot activity” in one query. That is a conversation, not a ticket chain. It collapses the busywork layer of delivery without collapsing the quality.

Second, client-facing AI governance becomes a real topic. The r/msp “How are you handling AI usage” thread is people realising their clients are installing Claude Desktop and pointing it at sensitive data with zero oversight. MCP is the opportunity to say “yes, you can have Claude, but we are the ones who configure which servers it connects to, with which permissions.” You become the MCP administrator. That is a sellable service.

Third, it changes the HubSpot managed services pitch. The MSPs who manage HubSpot for clients have always had to choose between “do it manually and bill hours” and “build a custom integration and maintain it forever.” MCP opens a third path: wire up a good HubSpot MCP server, give your techs conversational access, and turn a lot of three-hour config jobs into twenty-minute conversations.

Where Daeda AI fits

This is the part I am biased on, so take it with the obvious pinch of salt.

HubSpot’s own Remote MCP Server went GA on 2026-04-13 and is now a genuinely useful first-party option - read and write across the standard CRM over OAuth 2.1 + PKCE, free across all hubs and tiers. For most single-portal work it is enough on its own. Where it still falls short for MSPs is the multi-portal story: one OAuth connection equals one portal, and custom object schemas are not exposed yet.

That is why we built Daeda AI. Its Automation Suite lets one workspace hold many connected client portals, supports existing custom objects, and adds human-approved Write Plans so a tech can draft a multi-step change across a client portal, review it, and execute it in one step. You switch between client portals from inside your AI assistant instead of reconnecting every time.

For MSPs, the practical pitch is this: one tool, wired into every HubSpot portal you manage, lets your techs answer questions and execute changes through conversation. Billable hours go down on busywork. They go up on strategy - which is the work you would rather be doing anyway.

The short version

MCP is the standard that lets AI actually touch your tools. For MSPs it means faster delivery, a real governance angle to sell, and a better way to manage client HubSpots. The HubSpot piece is the one we built. The rest - filesystem, ITGlue, Slack - is out there in the wider MCP ecosystem and growing every week.

If the HubSpot portals are the bottleneck in your MSP delivery, Daeda AI is where I would start.