Normally when I write a blog post I try to come up with a funny anecdote or pithy intro to get started, but everything moves so quickly in the world of AI that I’m foregoing that this time. It wasn’t too long ago that I didn’t know what an MCP server was, but now I almost don’t recall the world of LLMs and AI without MCP servers. We’ve had a few notable releases regarding Mux’s MCP server, and today, with the help of our friends at WorkOS, Stainless, and Vercel, connecting your favorite LLM to Mux’s MCP server becomes so much simpler with our official release of mcp.mux.com.
Where we came from
Ages ago (or so it feels with AI but was really the beginning of July), we released our first version of our MCP server; go check out Matt’s blog post if you haven’t seen it already. This was a major milestone in allowing our customers to use Mux through their favorite LLM, but it came with some major drawbacks.
First off, you had to run the MCP server locally, and for those of you that work in the javascript/typescript/node/choose-your-favorite-toolchain, you know how frustrating that can be to set it up. We want to make this easy to use, and this was a major hurdle in adoption across our customer base, despite having an easy-to-install DXT file so you can drag and drop this into Claude. For other LLMs? Sorry, it’s a bit more manual.
Even worse, after you managed to install it to run locally, you had to configure your access token credentials manually in whatever way your LLM required you to set up MCP servers. This required you to log into Mux, create a new access token, and manually copy and paste that over into a configuration file somewhere on your machine. This is supposed to be the world of AI, where everything is good vibes and smooth sailing, not one where you have to copy and paste credentials just to use a product.
Accessing the promised land
While we saw some good usage of our local MCP server, we always knew on the horizon was a world where you can easily connect your favorite LLM to Mux without any hassle. While hosting the MCP server somewhere that’s accessible is its own problem (more on that later), unfortunately there was a larger hurdle we had to overcome — a whole new authentication scheme.
Authentication to Mux comes in two flavors today: authentication via username and password when working with dashboard.mux.com directly, and authentication via an access token for automated workflows. Unfortunately, neither of these are acceptable for a remote hosted MCP server; username and password only works on trusted domains (e.g. our own) but not in the broad world of LLMs, and access tokens have their own problems I mentioned above. What we really wanted was OAuth support, allowing setup to be a breeze
This is from a live demo that one of our founders, Matt, gave at WorkOS’s MCP Night 2.0, which you can view in its entirety here. To make this possible, we partnered with WorkOS, using their new Standalone Connect feature. We rely on them for the heavy lifting of OAuth negotiation and scoping of access, but are able to utilize our standard login flow for our dashboard, making the authentication and authorization process smooth and simple for people using the MCP server.
Where the promised land resides
When it comes to hosting the MCP server, if you watched Matt’s demo, he was using alpha.mcp.mux.com, and you heard him say I “forced” him to reiterate that it was alpha and might, you know, stop working at any time, as with any alpha release. This was due to some OAuth workflows we still needed to support (such as supporting SSO logins), but also due to some shortcuts I took in getting this hosted.
We partner with Stainless to help us automatically generate our SDKs, and they also generate an MCP server that exposes a bunch of customization options (which I’ll cover later) that we wanted to expose to our customers to support different workflows. For the alpha release, however, things just weren’t quite ready to get that hosted in a scalable way, so I duct taped together our SDK, MCP server, and a little express server, all hosted on a single, tiny instance using Fly.io. This works for an alpha, but is lacking features, supportability, and reliability.
In conjunction with our friends from Stainless and Vercel, we’re now hosting mcp.mux.com on Vercel, using Vercel Functions. Additionally, we’ve added some helpful variants, to enable the workflows that you want to use. You can see the full documentation here, but a few notable options include:
- https://mcp.mux.com?tools=dynamic - helpful for exposing three higher-level tools rather than the full suite of tools our MCP server supports, enabling your client to iterate and operate more quickly
- https://mcp.mux.com?resource=video.* - Only exposes tools related to Mux Video, helping control the total number of tools available to the LLMs
- https://mcp.mux.com?resource=data.* - Only exposes tools related to Mux Data, if you're only working with our Data product
If you’re interested, the code that exposes all of this is publicly visible in our Node SDK, but you’ll find that the Functions code is actually quite simple, built on top of the streamable HTTP support from Stainless that comes out of the box.
Getting started should be as simple as connecting your favorite LLM client to https://mcp.mux.com (or any of the URLs in our docs), but of course the local installation is also still possible. Many clients should just work out of the box, but some may require using mcp-remote (such as Goose). Jump in, and please give us feedback! Let us know about any issues you encounter, but more importantly, let us know how you’re using the MCP server!
