What’s the hardest part about building your MCP-Server?

by•

We did our first launch of (a platform to build hosted MCP-Servers) a few months ago and since then learned so much from talking to users, getting our first paying customers and also listening to the ones we didn’t close.

One thing became very clear from all those learnings:

Coding an MCP-Server is not the hardest part anymore. It’s what comes afterwards.

Hosting it, keeping it versioned, making sure it stays online, debugging, monitoring what actually happens and adding proper security. Especially in bigger companies and enterprise setups, a basic MCP-Server is often not enough. Security, authentication, observability and securely connecting internal systems quickly become just as important as the MCP-Server itself.

We put all those learnings into our platform and will have our second Product Hunt launch tomorrow with a completely new version of . 🚀 Super exited for your feedback.


What do you think is the hardest part about building and running an MCP-Server?

135 views

Add a comment

Replies

Best

I think deployment is the easy part compared with ongoing maintenance?

 You are right, in basic setups, the deployment is mostly easier then keep it running and maintained over the upcoming months / years. Definitely in bigger teams when you have a constant flow of new people joining or people leaving.

Still as a developer I think deployment can be very annoying when you just want to test your connector and instead have to setup your server and infra first ^^ What do you think? DevOps people would probably disagree :)

when it comes to enterprise compliance, there's no doubt about it. Large companies are all in on the idea of MCP, but then their infosec teams start asking the tough questions: Where do the logs end up? How is access monitored? and who's in charge of the rotatiing secrets? Addressing the post-deployment layer is definitely a savvy move.

It´s launch day🚀

Make sure to checkout our launch and have a look @ how we try to tackle those challenges:

the part that bit me was the tool surface, not hosting. every tool you expose gets paid for in context on every single request, and when it goes wrong the model doesnt crash, it picks the wrong tool with complete confidence. a healthy server with forty tools still makes the agent worse, and monitoring never flags it because by every metric you have the server is fine. permissions were the other one. auth only answers who is calling. the mcp tool i run locally ships a default deny allowlist and that ended up being the setting i actually cared about, because it whitelists the specific actions instead of trusting the caller.