6 ms·
Show HN: Metorial (YC F25) – Vercel for MCP
Hey HN! We're Wen and Tobias, and we're building Metorial (https://metorial.com https://metorial.com), an integration platform that connects AI agents to external tools and data using MCP.
The Problem: While MCP works great locally (e.g., Cursor or Claude Desktop), server-side deployments are painful. Running MCP servers means managing Docker configs, per-user OAuth flows, scaling concurrent sessions, and building observability from scratch. This infrastructure work turns simple integrations into weeks of setup.
Metorial handles all of this automatically. We maintain an open catalog of ~600 MCP servers (GitHub, Slack, Google Drive, Salesforce, databases, etc.) that you can deploy in three clicks. You can also bring your own MCP server or fork existing ones.
For OAuth, just provide your client ID and secret and we handle the entire flow, including token refresh. Each user then gets an isolated MCP server instance configured with their own OAuth credentials automatically.
What makes us different is that our serverless runtime hibernates idle MCP servers and resumes them with sub-second cold starts while preserving the state and connection. Our custom MCP engine is capable of managing thousands of concurrent connections, giving you a scalable service with per-user isolation. Other alternatives either run shared servers (security issues) or provision separate VMs per user (expensive and slow to scale).
Our Python and TypeScript SDKs let you connect LLMs to MCP tools in a single function call, abstracting away the protocol complexity. But if you want to dig deep, you can just use standard MCP and our REST API (https://metorial.com/api https://metorial.com/api) to connect to our platform.
You can self-host (https://github.com/metorial/metorial https://github.com/metorial/metorial) or use the managed version at https://metorial.com https://metorial.com.
So far, we see enterprise teams use Metorial to have a central integration hub for tools like Salesforce, while startups use it to cut weeks of infra work on their side when building AI agents with integrations.
Demo video: https://www.youtube.com/watch?v=07StSRNmJZ8 https://www.youtube.com/watch?v=07StSRNmJZ8
Our Repos: Metorial: https://github.com/metorial/metorial https://github.com/metorial/metorial, MCP Containers: https://github.com/metorial/mcp-containers https://github.com/metorial/mcp-containers
SDKs: Node/TypeScript: https://github.com/metorial/metorial-node https://github.com/metorial/metorial-node, Python: https://github.com/metorial/metorial-python https://github.com/metorial/metorial-python
We'd love to hear feedback, especially if you've dealt with deploying MCP at scale!
- solumos 11mo agoThe distinction between "Vercel for MCP [integrations]" and "Vercel for MCP [servers]" is meaningful — maybe "Zapier for MCP" is a more appropriate "X for Y"?. Congrats on the launch!
- tobihrbr 11mo agoThat'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!
- deleted 11mo ago[deleted]
- ushakov 11mo agocongrats on the launch! why do I need a specialized platform to deploy MCP instead of just hosting on existing PaaS (Vercel, Railway, Render)? also if you're not using VMs, how do you isolate per-user servers?
- tobihrbr 11mo agoGreat questions! 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.