It's an honest opinion that I had put into a blog post. It's written by me, though I did use LLMs to review and improve it (no copy pasting). I still feel like the analogy between early browsers and the current state of AI stands. There is in a sense a war being fought out and there are emerging standard and there is lot's of glue around that to make it work.
The war part is more about the competing AI companies. It's meant to be an analogy to the "browser wars" (https://en.wikipedia.org/wiki/Browser_wars). Not meant to be BS, I just wanted to use the terms that were used during the early days of browsers.
That looks very interesting. Though, we’re also a hosting platform in addition to the nice APIs and SDKs. Plus, we provide observability and much more. Still, something to explore. Thanks for sharing.
That's a great idea. We'll add that asap. More broadly, we're working on documentation that explains Metorial, and it's sub-components, in more detail.
Just for context, it's as simple as 1) creating an OAuth Sessions (https://metorial.com/api/oauth-session) which includes a URL which you 2) pass on to your user's to authenticate at and you're done.
Thanks for sharing and adding us to your list. The point about the lambdas is fair, though we do support other execution modes to combat this. Please let me know if you have any feedback or encounter hiccups :)
Thanks for pointing that out. Ultimately, we wanted to strike a balance between being fair and open to the community, welcoming contributions, and ensuring that people can self-host without having to worry about licensing issues, while also ensuring that Metorial, as a company, can exist and work on OSS sustainably. This isn't easy and I don't think there's a right answer. To us FSL strikes a pretty good balance. Allowing the community to use and participate while ensuring that Metorial makes sense as a business as well.
That's a really interesting point. We've actually been discussing this quite a bit. We felt like putting an emphasize on the "dev tool" aspect (like Vercel) makes more sense, but the way you put it we might want to reconsider that. Thank for your interest!
If you want to run your own remote servers (for your product/company) Railway or Render work great (Vercel is a bit more difficult since Lambdas are very expensive if you run them over long periods of time). Metorial targets developers who build their own AI agents and want to connect them to integrations. Plainly, we do a lot more then running MCP servers; we give you monitoring, observability, handle consumer-facing OAuth, and give you super nice SDKs to integrate MCP servers with your agent.
Regarding the second question, Metorial has three execution modes depending on what the server supports: 1) Docker - this is the most basic one which any MCP server should support. We did some heavy optimizations to get those to start as fast as possible and our hibernation system supports stopping and resuming them while restoring the state. 2) Remote MCP - we connect to remote MCP servers for you, while still giving you the same features and ease-of-integration you get with any Metorial server (I could go more into detail on how our remote servers are better than standard ones). 3) Servers on our own lambda-based runtime. While not every MCP server supports this execution mode, it's what really sets us apart. The Lambdas only run for short intervals, while the connection is managed by our gateway. We already have about 100 lambda-based servers and working on getting more on to that execution model.
There's a lot about our platform that I haven't included in this. Like our stateful MCP proxy, our security model, our scalable SOA, and how we transform OAuth into a single REST API calls for our users.
Let me know if you have any additional questions, always happy to talk about MCP and software architecture.