Hundreds of monitoring alerts were deduped and triaged into tickets. The techs’ time entries were logged to Autotask against the right tickets, billing friction gone. New webpages went live with their links checked and the deploy visually verified. The biweekly sales and marketing report compiled itself out of Search Console, Clarity, and website form submissions. After-hours tickets got first responses and were queued for morning dispatch or the on-call tech.
None of it was done manually.
This is the story of how we wired Autotask, NinjaOne, IT Glue, Microsoft 365, our phone system, and the rest of our platforms into AI agents using Model Context Protocol, and what it cost us to get here.
At the start of this year, our “AI implementation” was nothing more than a chatbot, a few projects and skills, and a lot of copy-pasting. The model could reason well about our work and help us find basic information, and touch exactly none of our real data. What changed wasn’t the model. It was five layers of plumbing built in a specific order, and the order is what took the longest to get right. Here’s the build, stage by stage, including what broke.
One term first, since it’s in the title: Model Context Protocol is how you hand an AI agent a specific, named set of actions it’s allowed to take inside a system, or across several systems at once. Instead of pointing the agent at a raw API, with all the blast radius, context bloat, and token spend that comes with it, MCP acts as an authentication and abstraction layer in front of a fixed set of small, purpose-built tools that accept parameters. The agent doesn’t write API scripts on the fly and hope they work; we write the script once as an MCP tool, and the MCP server handles all authentication between the agent and the platform. All the agent ever sees is a tool name and its parameters. That’s the whole definition.
Where This Started: One Session, One Terminal
Stage zero was one Claude Code session open in a terminal and a list of things I wanted it to do for Umbrella IT Group, our MSP in Jacksonville.
It could draft a ticket summary. It couldn’t create the ticket. It could explain exactly where our billing hygiene was slipping. It couldn’t fix a single entry. Every answer was good and every answer died in the chat.
The constraint was never model intelligence. It was reach. Every hour spent making the answer smarter improved something that wasn’t the constraint.
The push to go all-in came from an uncomfortable observation: our techs were already using their personal AI accounts to get work done, inefficiently and outside any guardrail, because Copilot wasn’t cutting it for much beyond Teams meeting summaries. So we took the risk and bought the whole team Claude subscriptions. It wasn’t cheap (the Team plan runs $1,200 per seat per year), but it immediately changed how we thought about our processes, and the model was strong enough that “could an agent just do this autonomously?” became a serious question instead of a joke. What we didn’t see coming was how much it would save us by replacing entire vendor platforms we’d been paying for monthly.
There were two ways forward that didn’t involve building: keep copy-pasting between the model and five browser tabs, which is a person performing API calls badly, or find a vendor to sell us the answer. The buy path deserved a real look, and we gave it one.
The Search for an Off-the-Shelf Answer
Not knowing where to start, we went shopping first. We talked to other MSPs and companies across the industry, trying to pin down what we actually wanted versus what was available. The needs rhymed everywhere: AI that can respond to customers and triage tickets in Autotask, automate troubleshooting and ticket resolution, and help techs find relevant data fast. Tools exist that solve some of these. No tool solved them all.
And every platform on the shortlist carried its own implementation lift anyway. I can’t remember the last vendor onboarding that didn’t cost at least a week between setup, staff training, documentation, and verifying everything actually works. If we were going to pay an implementation cost either way, we could pay it building something that fit exactly.
That was the realization: no off-the-shelf product provided the functionality we needed. With coding agents in hand, we could build most of that value ourselves.
Native PSA and RMM Copilots vs. an MCP Agent: Why Built-In AI Stops at the Product Edge
Most people evaluating this have already been pitched a native AI feature inside a tool they already run: the PSA (professional services automation, the ticketing, time, and billing system an MSP runs its business on), the RMM (remote monitoring and management, the software on every managed device that watches and patches it), or something similar elsewhere in the stack. They’re genuinely useful. They summarize, draft, and triage well inside their own product, and if that’s the job, use them.
The limit is structural. A copilot that lives inside your PSA can only see your PSA. It can summarize the ticket. It can’t check the device in your RMM, confirm the documented configuration in IT Glue, verify the tenant’s state in Microsoft 365, log the time, and then read the record back to prove the write actually landed.
Real work crosses tools. Cross-tool action is the gap MCP fills.
So this isn’t either/or. Use the native features where they’re strong and build the connective layer for everything that spans systems. The buy-versus-build question is which layer you’re solving at.
The First Win: Rebuilding the Alert Pipeline
We chose to build, and the first thing we tackled was alerting. Some platforms that send alerts have great Autotask ticket integrations. Some can only manage an email, and a PSA can’t conjure client attribution out of a random vendor notification on its own.
So we stood up n8n, an automation platform, as the connective tissue. We were very close to purchasing Rewst (popular, built for MSPs, and very expensive). Instead we made a decision that shaped everything after it: dedicate internal project time to building our own automations and infrastructure rather than buying another platform. We had the time and the skills, and if we failed, the vendors would still be there to fall back on.
n8n was the right bet. With Claude Code driving the n8n API, integrations that used to be week-long projects became afternoons, and the only new costs were the Claude subscription and a tiny hosting bill. n8n replaced Rewst before we ever bought it and retired Zapier, the legacy hub we’d been paying for. That style of work ran for weeks, API integrations between Autotask and everything else, built conversationally, and it produced results we genuinely hadn’t imagined at the start.
But scheduled automation is still automation on rails. The leap from workflows to agents that act across systems took more than n8n. It took five layers: one MCP server per system, curated context, a central gateway, guardrails, and operating doctrine.
Layer One: An Autotask MCP Server, a NinjaOne MCP Server, an IT Glue MCP Server
Fresh off the n8n win, we thought we understood what an MCP server was. n8n even has an instance-level MCP server built right in. Easy upgrade, we figured: collect all our vendors’ API keys, plug them in, and let the agent loose. What could go wrong?
The first big mistake was not understanding the difference between an API and an MCP server. APIs are raw, built for programmers. The top models can call them just fine, but hand an agent 300+ auto-generated “tools” and it has to read your prompt, pick the right endpoints, and figure out how to chain them into something that happens in the real world. That’s massive context bloat, and when you pay for tokens by the call it gets very expensive very fast, because only the strongest frontier models can hold the plot at all.
MCP servers are not API mirrors, and n8n had no real authentication story between its MCP surface and our Claude sessions either. We’d spent weeks wiring up “MCP tools” in n8n, connecting them to Claude Code and even to n8n’s own AI-agent nodes, hoping they’d understand the tasks at hand. It failed miserably, and we went back to the drawing board.
The rebuild went the opposite direction: one thin server per platform rather than one large server for everything. Autotask PSA for tickets, time entries, and billing. NinjaOne RMM. Microsoft 365 and Graph. IT Glue for documentation. Our VoIP platform. Our WordPress site. Google Search Console. Microsoft Clarity. Our accounting and finance tooling. And n8n itself for scheduled runs that don’t need a conversation to start. We run Autotask, so that’s the server we built first. The same shape applies to a ConnectWise MCP server, or whatever PSA you’re on.
This time, instead of mirroring the API, we built purposeful tools: “search tickets”, “enter billing”, “run script”. Under the old approach each of these took multiple raw API calls, sometimes dozens, especially on platforms that run entirely on entity IDs and codes instead of names. In Autotask, before an agent could do anything useful, it had to make several calls just to gather IDs (user ID, company ID, ticket ID), and only then attempt the actual task without losing the plot. The test we still use: if you can’t name the job a tool does in five words, it’s the wrong tool.
With purposeful tools on thin, platform-specific servers, our sessions turned from chats into force multipliers. From one session we could now work a ticket from open to close: investigate, troubleshoot, resolve, and enter the billing. We hooked the same servers up to Claude Desktop and Claude Code, and because they speak an open protocol, the architecture isn’t a bet on any one vendor’s agent.
The piece still missing was access control. That became its own layer.
Layer Two: Curated Context, Not a Wiki Dump
The next layer was context. You’ve heard “garbage in, garbage out,” and with agents it’s real and it compounds. A model with perfect API access and no business context produces confident, wrong work, fast and at scale. Relevance beats volume.
Our agents read a small, maintained set of files about how our business actually operates: who we are, how we bill, what our documentation standards are, what we’ve already learned the hard way. Not a dump of the entire wiki.
The rule we run on: if a file isn’t accurate enough that I’d hand it to a new hire on day one, it doesn’t belong in the agent’s reading list.
This layer, together with the instructions and guardrails wrapped around it, is what people mean by an “AI agent harness,” and it’s something anyone who uses AI daily should invest in. It’s the cheapest layer to build and the easiest to treat as optional. I maintain a personal harness called OPS that I’ve shared with people both at Umbrella and outside of it; you can find it on my GitHub.
The honest cost is maintenance. Context rots, and rotted context is worse than none, because the agent trusts it completely and can’t tell it’s stale. The harder problem underneath is the documentation system itself: pruning old, stale information at scale. More on that below. For now, plain IT Glue searches and edits through a simple MCP tool call carry the load just fine.
Multi-Tenant Microsoft 365: Why MSPs Can’t Use Single-Tenant AI Connectors
A tenant is one customer’s Microsoft environment: their users, mailboxes, and devices. The M365 connectors shipped by the AI vendors themselves assume you have exactly one: one company, one tenant, one mailbox. We manage many, and we need access that belongs to us as the provider and works across all of them. That’s why CIPP, an open-source multi-tenant management layer for Microsoft 365, is in our stack. It answers a question the single-tenant connectors never ask.
CIPP has since shipped its own built-in MCP server. We stayed on ours anyway: we’d already built it, we curate exactly which tools our agents can see, and authentication stays inside our own gateway instead of being taken at face value from the vendor.
MCP Server Security Risk: Why an MSP’s Blast Radius Spans Every Client Tenant
A single-tenant company that over-permissions an AI agent has a bad day inside its own four walls.
We don’t have four walls. An over-permissioned agent at an MSP reaches into every client tenant at once. That isn’t a company incident, it’s a cross-client incident, and it’s a materially different category of exposure than anything the generic AI-security guidance is written for.
To be clear about the actual threat, because it isn’t a rogue AI: in months of production use we’ve never seen an agent act malicious. What we have seen is relentless. A model fixated on completing its task will sometimes take a path you’d never approve, not out of malice but because it can’t see the bigger picture and you gave it the access. The realistic failure mode is a very fast employee with too many keys and no peripheral vision.
The gateway and guardrails that follow exist because of that math. If you’re an MSP evaluating this, do the same arithmetic first: assume an agent gets exactly the access you gave it and uses all of it in pursuit of its goal, then decide what you’re comfortable handing over.
Integrating your own tools and integrating everyone else’s are different problems. We’re integrating everyone’s.
Layer Three: One MCP Gateway, Scoped Keys Per Consumer
Once we had a server per system, every agent, machine, and scheduled job needed its own connections and credentials. That sprawl is how you end up with credentials you can’t inventory and access you can’t revoke.
What we actually needed was a chokepoint: a single gateway that holds the entry keys, knows the permissions, and routes each request to only the tools that consumer is allowed to reach, whether the consumer is a person, an AI agent, or a dumb scheduled script. We found an open-source gateway project that fit, forked it, hardened it, and now maintain our own version, adding features and improvements as we find them necessary. Every consumer connects to that one endpoint instead of to individual systems.
Three operational wins came out of it. Each consumer gets a scoped key that exposes only the tool groups it needs. Curation happens in one place, so a tool that shouldn’t exist for a given consumer simply isn’t there to call. And revocation is one action instead of a scavenger hunt across a dozen configs and vendor credential pages.
The lesson underneath: least privilege is far easier to enforce at one chokepoint than at twenty edges.
The honest tradeoff is that a single connection point is also a single thing to secure, patch, and keep running. We treat it that way.
Layer Four: Guardrails, Because APIs Lie
APIs return success for writes that did not happen. We’ve watched writes come back clean across more than one vendor’s API, with a success code, a well-formed response, the whole shape of a job that worked, and change nothing at all.
So the rule now is read-back verification. After every write, the agent reads the record back and confirms the state it expected. A write isn’t done until it’s verified. It’s the guardrail that has paid for itself most often.
The rest of the set is short. Human approval gates on consequential writes (money, client-facing records, anything destructive), while lower-consequence work runs without a stop. Audit trails, so every action is attributable after the fact. Least-privilege credentials per consumer. Secrets in a vault, never in a config file and never in a prompt. And content that arrives from outside the system (form submissions, ticket bodies, alert payloads) is treated as data to be summarized, never as instructions to follow.
The calibration lesson is one I got wrong first. We started with approval gates on nearly everything, and over-gating kills throughput until the human becomes the constraint you just spent months engineering around. The gates that survived are the ones tied to consequence.
Layer Five: Doctrine, the Layer That Isn’t Code
The last layer doesn’t look like engineering and matters most over time.
Our internal documentation is written to be read by agents as well as people. That raised the bar on both, because vague documentation produces vague action, visibly and immediately.
We keep lessons files the agents actually load. When something breaks in a way that will break again, the fix gets written where the next session will read it, so a different session doesn’t re-make it next week.
And verify-before-trust applies to the humans too. We check agent output the way we’d check a new technician’s work: spot checks, proportional to consequence.
This layer is the difference between an impressive demo and something that survives months of production.
What Actually Runs on This Today
Monitoring alerts get deduped and triaged into PSA tickets automatically, instead of landing as a pile of near-duplicate noise for someone to sort by hand.
Time entries and billing hygiene are handled conversationally. Describe the work in plain language, or just tell the session “let’s close this ticket” at the end, and it gets logged against the right ticket with the write verified afterward.
Our website is operated end to end by agents: content updates, SEO checks, defect fixes, and verified deployments.
A biweekly sales and marketing intelligence report compiles itself from Google Search Console, Microsoft Clarity, and website form submissions, so the review meeting starts from data instead of a deck someone built the night before. That report now does work we used to pay an outside firm four figures a month for.
Compliance evidence gathering runs the same way.
Two qualifiers. This is months of production use, not a demo. And every one of these still has a human reviewing consequential output, so nothing that touches client-facing records or money lands unreviewed.
What’s still manual: judgment calls, client relationships, and the initial scoping of new workflows and projects. Agents execute the loop well once it’s defined. Defining the loop is still a person’s job.
We’re also deliberate about not automating the parts of the job our people actually enjoy. Some of our techs thrive on complex projects and gnarly tickets, the kind that take real puzzle-solving, and the AI is there if they want help, not instead of them. Client QBRs stay human; our guys like sitting with customers and understanding their constraints, and no model replaces that. The one thing we do know for certain: we would never hire a remote junior tech again. That’s a scary philosophical realization, and it’s a topic for another post.
Where to Start: The First Two Weeks
Week one, no integrations at all. Write your harness and context files. Then pick the system where your team burns the most hours, usually the PSA, and stand up one thin server for it with three to five task-shaped tools, read-only. Read-only means you can be wrong without consequences while you learn what the tools should have been.
Week two, add the write path for exactly one workflow. Ours was time entries. Wire the approval gate and read-back verification in from the first write. Retrofitted guardrails are a rewrite.
Two rules of thumb I’d carry over. Don’t add the gateway until you have a third consumer: earlier is premature, later is a credential-sprawl cleanup project. And don’t scale until the first loop is boring.
The mistake I’d skip: over-tooling the early servers with everything the API offered, then spending time cutting back. Start narrow. Draw a line from a real time sink to the first tool you build, and build only that. It’s exactly how we started with n8n and Autotask: not every possible workflow on day one, but purpose-built workflows solving one issue at a time.
Advanced Steps: Autonomous Agents and Documentation RAG
Everything above describes AI you sit with: a Claude Code or Claude Desktop session, a person driving, the agent reaching through MCP. The advanced step is taking the person out of the loop for selected work. Autonomous agent harnesses (OpenClaw is a well-known open-source example, and part of our own operation runs on a harness we built ourselves) flip the model: agents wake on schedules and events instead of prompts, connect through the same gateway, hold their own scoped keys, and obey the same guardrails. They just don’t wait for anyone to type. The overnight montage this post opened with, the alert triage, the after-hours ticket responses, the self-compiling reports, is exactly that: autonomous agents doing real work with the same MCP tools our interactive sessions use.
The other advanced track is documentation at scale: RAG and vector search over internal documentation, so agents can use institutional knowledge the way a twenty-year tech does. We’re actively exploring it, and it changes enough of the picture to deserve its own write-up.
Both tracks get their own posts later. For now, the point is that the ceiling is much higher than chat-that-can-do-things, and the five layers are what make the higher floors safe to build.
Beyond the MSP Stack: Anything With an API
The MSP stack is just our toolset. Nothing in these five layers is specific to PSA, RMM, or documentation platforms. Swap in an ERP, an EHR, a CRM, or a billing platform and the architecture is identical. If it has an API, it can be integrated this way, and the layer order still holds.
This is a blueprint, not a product.
If you’re an MSP or a company who wants to build this in-house, take the sequence and run with it. If you’d rather have it built for you, that’s the work we do. Reach out through the contact form.
