Building a Production MCP Server: What It Took to Get to GA

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, fittingly, on the day I'm writing this.

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 was that betting too heavily on one ecosystem was a mistake.

Our Copilot approach kept us largely inside Microsoft-owned experiences, and we hit real limits on response quality and control. 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 today. ChatGPT, Copilot, Cursor, automation platforms, and whatever comes next.

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/partner marketplace. A space for MSP partners to eventually build and monetize their own tools on Syncro. We paused this pillar. We want real adoption evidence and a more complete AI story across the platform before investing further. We'll revisit it in 2027.

The point of Headless Syncro isn't to predict which AI interface wins.

It's to make sure Syncro doesn't have to.

GA Day

Three things came down to the wire for this launch, and one of them landed today, the same day I'm writing this post.

The first was our listing in the Anthropic Claude Connector Directory³.

We had no idea it was happening today.

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.

Two came from a key partner: a ticket researcher that surfaces past solutions for a current open ticket, and an on-site prep skill that makes sure a technician isn't missing work or duplicating a visit.

Two we built ourselves: 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.

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 tier.

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'm ending 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.

1. "Identity Management Deep Dive with Microsoft's Merill Fernando," The Practical 365 Podcast, S4E31, November 22, 2024. practical365.com

2. Lokka, a Microsoft Graph and Azure MCP server built by Merill Fernando, first released March 2025. lokka.dev

3. Anthropic's Claude Connector Directory. claude.ai/directory/connectors/syncro.

Email

rich.dean@nomadic.consulting

Socials