Background
A managed services business runs on a wide and uneven landscape of operational tools — an RMM platform for endpoint management, an IT documentation system, a network controller for switches and access points, a VoIP phone system, an email security stack, an identity directory, and several more. Each has its own API, its own auth model, and its own quirks.
AI assistants are good at moving between systems and summarizing what they find. The friction is that they need a structured way to call those APIs — not generic HTTP, but typed tools with clear inputs, outputs, and error semantics. That is what the Model Context Protocol is for.
I started building MCP servers for each operational platform we use, one at a time, as the protocol was stabilizing. The collection has grown to more than a dozen.
What I built
Each MCP server exposes a focused set of typed tools for one platform. A server for the RMM platform exposes tools to look up tickets, query asset inventory, and pull customer billing context. A server for the IT documentation system exposes tools to search articles, fetch credentials with audit logging, and update structured asset records. The network controller server exposes site, device, and client lookups. The phone system server exposes call history, extension routing, and queue status.
The shape is consistent — narrow, well-typed tools that map cleanly to real operational questions — but the implementations vary by what each platform offers. Some servers are read-only summarizers. Others write back into the system of record. A few sit behind an OAuth-protected token portal so they can serve multiple users without leaking credentials.
How they fit together
The servers split roughly into two language camps. The Python servers use the official MCP SDK with a FastMCP-style decorator pattern — fast to write, easy to add tools incrementally, and a good fit for the platforms whose SDKs already speak Python. The TypeScript servers use the JS SDK and target the platforms with Node-native client libraries or richer streaming APIs.
Deployment varies with the platform. Some servers run as local stdio processes, launched by the assistant on demand. Others run in Docker behind Traefik with TLS termination, exposed only over a private network. The ones that handle multi-user access sit behind a small web-facing token portal that issues per-user credentials and brokers the upstream API calls, so the assistant never sees the underlying platform token.
Why it matters
The interesting part is not any single server — most of them are a few hundred lines of glue between a stable API and a typed tool surface. The interesting part is the shift in how operational work gets done once an assistant can reach into every system at once. Cross-system questions that used to require opening four tabs (“which customer does this asset belong to, what is the open ticket, who is the contact, and what is their phone extension”) collapse into a single prompt.
Building this collection early — while MCP was still settling — meant accepting that some servers would need to be rewritten as the protocol matured and the SDKs gained features. That tradeoff was worth it. The day-to-day value of having structured AI access to the operational stack has already paid back the rebuild cost several times over.