If you've spent any time reading about AI tools for MSPs, you've probably run into the phrase "MCP server." What you may not have run into is a clear explanation of what actually running one looks like. Docker containers, NPX packages, UV, MCPB, hosted endpoints: the terminology stacks up fast, and the documentation often assumes you already know which flavor you're supposed to pick.

The short answer is that MCP servers can run in a lot of different ways, and the right choice depends on what you're trying to do with them. Running a quick experiment on your laptop is a different job than connecting your whole team to the same set of tools. Local containers make sense for the first. A hosted MCP gateway makes sense for the second.

In this video, Aaron from WYRE AI walks through the actual options. He covers what runs locally (Docker, NPX, UV, MCPB), what STDIO vs. HTTP streaming means and why it matters, and why moving to a hosted server behind a gateway changes what your team can do with AI. It's about six minutes long and lands in plain English.

If you're starting to plug AI into your ticketing system, your RMM, your knowledge base, or the rest of your stack, this is the kind of context that pays off before you start clicking. You'll walk away understanding what "running an MCP server" actually means in practice, and which approach fits where you are today.

A quick note on why hosted gateways come up so often in this conversation: once more than one person on your team needs access to the same tools through AI, running things locally on individual laptops stops making sense. Credentials scatter. Access control gets fuzzy. Audit trails disappear. A hosted MCP gateway (like Conduit) gives you one place to manage all of it, with the AI assistants your team already uses (Claude, Copilot, ChatGPT, or whichever fits your workflow) connecting through a single endpoint.

Have a watch, and if you want to talk through what this looks like for your shop, we're here.