This article is adapted from a post that originally appeared on Rich’s blog, 365 Insights.
In November 2024, right before Microsoft Ignite, I interviewed Merill Fernando on the Practical 365 Podcast. We talked about his open-source security framework, Maester.dev, and what to expect at Ignite that week. MCP barely existed yet in most people’s minds.
A few months later, Merill shipped Lokka, a Microsoft Graph MCP server. I remember the exact moment it clicked for me. I started using it to manage tasks in my own Microsoft 365 tenant with plain language instead of scripts or admin portals. The first version was already useful. Every version since has gotten more powerful.
That was the moment I knew MCP wasn’t a fad. It was infrastructure.
That personal discovery turned out to be the first chapter in a much longer story, one that ended on the day we shipped.
The Hackathon That Started It
In 2025, one of our engineering teams brought a Syncro MCP server to an internal hackathon. It spread fast. Engineering, QA, and product all started experimenting with it on our own.
That two-day prototype surfaced real problems. Our API keys and subdomain model weren’t built for this kind of access pattern. We also learned hard lessons about MCP design itself, lessons that mattered even more as the protocol matured.
When we built the production version, we didn’t polish the hackathon code. We threw it out and started over.
The Copilot Detour
By late 2025, we were testing Microsoft Copilot as another interface into Syncro data, built inside the Microsoft ecosystem. We created a common gateway to support it and learned a lot doing it. The lesson that stuck: betting too heavily on any single ecosystem was a mistake.
Meanwhile, Claude was taking off quickly among the organizations we work with, in daily operational use, not as a novelty. We had a choice. Invest more deeply in a single AI ecosystem, or step back and build the platform so Syncro could work with whichever interface our customers chose.
We shifted. The gateway infrastructure we’d built stayed useful. The strategy didn’t.
Headless Syncro: Three Pillars
That shift led directly into a broader strategy conversation in product. We were watching some of our most advanced customers connect data across tools and increasingly use a common LLM, like Claude or ChatGPT, as the interface. Some were building their own MCP servers. Others were adopting third-party ones. A few vendors were even building MCP servers using Syncro’s name without us.
The market was telling us something plainly: build the official one, or someone else will fill the gap.
But the bigger idea became more important than the MCP server itself. What if Syncro’s capabilities didn’t have to live exclusively inside the Syncro UI? What if customers could securely use their Syncro data and workflows through whatever AI client, automation platform, or interface made the most sense for the job?
That became Headless Syncro, built on three pillars.
MCP server. A standard, governed interface that lets AI clients and automation tools work directly with Syncro data and capabilities. Claude, ChatGPT, and Copilot today. Cursor, automation platforms, and whatever comes next. [RICH CONFIRM: original said ‘Claude today’; changed to match launch comms. Which is technically accurate?]
API modernization. OAuth 2.1 and standards-based client registration, so these tools can authenticate securely without falling back to long-lived API keys. Paired with permission inheritance, so a user’s existing Syncro permissions carry into the MCP session exactly as they are, and activity logging so every action can be attributed to the person who took it.
Builder marketplace. A space for MSP Partners to eventually build and monetize their own tools on Syncro. It’s the longer-term pillar, and we’ll have more to say about it as adoption grows.
The point of Headless Syncro isn’t to predict which AI interface wins. It’s to make sure Syncro doesn’t have to.
Launch Day
Three things came down to the wire for this launch, and one of them landed on GA day itself: our listing in the Anthropic Claude Connector Directory. We had no idea it was happening that day. I saw the email on my phone about three minutes after it landed, jumped out of my chair, and ran to tell the team. The reaction across every internal channel was immediate excitement.
The second is our Claude plugin, publishing shortly with four skills: a ticket researcher that surfaces past solutions for a current open ticket, an on-site prep skill that makes sure a technician isn’t missing work or duplicating a visit, a call-to-ticket skill for technicians in the field who need to log a ticket quickly without missing important details, and a documentation search skill that finds the right knowledge base article and formats it cleanly. [RICH CONFIRM: is ‘publishing shortly’ still accurate, and are we OK naming all four skills?]
The third is publication across the other major MCP registries, making sure that when someone goes looking for a Syncro MCP server, the official one is the one they find.
What This Means If You Run an MSP
If you’ve already built or adopted your own MCP server, there’s one question I’d ask first: what does your authentication actually look like?
If your MCP server relies on a shared API token, every action may effectively happen under the same identity. You can’t reliably tell John’s activity from Jane’s. That’s not a small implementation detail. It’s a security and audit problem.
Our public MCP server runs on OAuth. You authenticate as yourself, every action is attributable to you, and you get exactly the permissions you already have in Syncro. Nothing extra to configure. No separate MCP super-user. The MCP session isn’t a privileged back door into Syncro. It’s another interface operating with the permissions you already have.
And you don’t have to maintain the server yourself. We do that, with full support, on every plan.
If you haven’t started experimenting with MCP yet, my advice is different. Don’t try to convince your whole team at once. Start with the owner, operator, or technical leader who has the most influence over which tools the business adopts. Let that person connect Syncro to whichever LLM they trust and run a real workflow or two.
Research a difficult ticket. Prepare a technician for an on-site visit. Turn a field call into a properly documented ticket. Find the right internal documentation without hunting through a knowledge base.
Once someone sees what it feels like to interact with operational data this way, the conversation changes. Then rolling it out to technicians, billers, and the rest of the team gets a lot easier.
Full Circle
I started this journey querying my own Microsoft 365 tenant through Lokka, curious what an MCP server could actually do. I ended it having shipped one, on a day I didn’t see coming, for a platform used by thousands of MSPs.
But the MCP server itself may not be the most important part. The bigger lesson is that the interface to software is changing.
For years, software companies assumed customers would come to our application, navigate our UI, and use the workflows we designed for them. AI is starting to break that assumption. Increasingly, the interface may be Claude. Or ChatGPT. Or Copilot. Or an automation platform. Or an agent that doesn’t look much like a traditional application at all.
Our job isn’t to guess which one wins. Our job is to make Syncro secure, accessible, and useful through all of them.
The tools got better. The strategy got sharper. The lesson stayed the same: this isn’t a trend to watch. It’s infrastructure to build.
The Syncro MCP Server is live now, included in every Syncro plan. Learn more and turn it on today.
Adapted from “Building a Production MCP Server: What It Took to Get to GA,” which originally appeared on 365 Insights.
Share
Related Resources
