MintMCP

When an agent remembers last week's context and can act right in the Slack channel my team already works in, it starts to feel like a teammate. That's a real shift in how we work, and it's why we're excited to be building it with MintMCP

The best AI investment you can make is something where you build it and then everybody can benefit

My concern was less about the technology itself and more about the lack of visibility and consistency across the company

I didn't want someone to have to add 60 different MCPs. If they're a developer, they can just install a developer package and they're ready to go. If they're in product management, they can install a productivity package and they're ready to go

AI adoption was accelerating rapidly across the company, but the supporting infrastructure and governance were still catching up. MCP usage was growing quickly as teams looked to connect internal data with AI tools, often in decentralized ways. My concern was less about the technology itself and more about the lack of visibility and consistency. If someone had asked, ‘What MCP tools are available across Coursera?’ there wasn’t a single, reliable answer

We've all seen popular open-source packages get compromised, where someone uploads a version that does things it's not supposed to on developer machines. It was eye-opening to see what could happen if you didn't control the secrets around MCPs or tokens. That was one of the factors why I started looking at MCP gateway solutions

The security concerns are completely valid; that's why you need some governance, some structure to using these tools. But when you block certain tools, you see people use patterns that are unsafe. If you block MCP access, they'll start copying data from one place to another or creating some temporary data store, which is worse from a security perspective. The primary goal is to enable everyone, so my first instinct is not to block access but to see what is the right way to enable people with the tools

We did an analysis of MCP gateways and found MintMCP to be easy to set up and use. We needed to be able to host our own MCPs, and we didn't want a different solution for that, because it needs to be done in a secure way as part of the gateway setup. The other thing that's important is setup time. I didn't want someone to have to add 60 different MCPs. That enablement needs to either be automatic or a very simple click somewhere

Virtual MCPs. We bundle multiple servers and control individual tools. We knew LLM users shouldn't be able to fork a repo or change repo permissions; we want that done manually if at all. Being able to click tools on and off, and roll out new MCPs to a bundle, means a developer points at the dev bundle once and automatically gets whatever we push out next. We don't have to send anything around

We work hand in hand with them. They wanted to know what people were doing and to make sure usage wasn't creating unnecessary risk. The insights dashboard shows the servers people use and how they're using them, and the rules engine (built-in rules, custom tools, and a tool allow-list) lets us enforce it. We blocked all sudo calls from the LLMs and limited reading of certain env files

If we see a trend toward a particular server, we bring security in, review it, and roll it out, because there's clearly value there. And when someone uses a random unofficial GitHub MCP, the dashboard lets us reach out: please switch to the official one, here's the one-line command, carry on

There's always a build-versus-buy discussion. We could have self-hosted an open-source option, but maintaining it and adding all the features you get out of the box would be a lot more overhead. You can write it and ship it, but then you have to maintain it and make sure it works correctly, which is the other half of the battle

Work with your security team, work with your InfoSec team to do it in the right way, so that the enablement happens at enterprise security scale and you're still compliant, doing all the right things to protect your data. The key message around enablement and leaning in is important because AI is changing a lot of workflows. Any function can benefit and securely use these sophisticated capabilities if they have the right kind of tools

The problem isn't getting people to use AI. It's that every workflow was held together by personal API tokens sitting in a dotenv file on someone's laptop

Everybody had access to tokens, so everyone would spin up their own thing, and before we knew it, we had too many of the same things

When I drew that matrix out, it was obvious we needed a gateway layer between the systems, the individuals, and the roles they actually had

We wanted everyone using ChatGPT and Claude to reach our internal systems. But when it's an LLM making the calls, not a UI or API keys you manage, you need guardrails you can trust to sleep at night

We asked someone to share their config file when we were debugging. They posted it in Slack, and it had all their API keys in it

We did an analysis of MCP gateways and found Mint to be easy to set up and use. We needed to be able to host our own MCPs, and we didn't want a different solution for that, because it needs to be done in a secure way as part of the gateway setup. The other thing that's important is setup time. I didn't want someone to have to add 60 different MCPs. That enablement needs to either be automatic or a very simple click somewhere

I have people in HR or sales that need access to our CRM. I can't get them the API key, and I shouldn't be able to