Comment by wenyers
9 hours ago
Wen here, the co-founder. I actually spent a couple hours today to take the time to give you a comprehensive answer.
1. As you said, Composio doesn’t allow self-hosting and the source code isn’t available. We want to follow PostHog’s playbook in letting devs run everything on their own infrastructure and open sourcing all our MCP containers.
2. A huge benefit of this approach is that we can let you fork any MCP server through our dashboard so that you can manage it yourself and make any adjustments you might need. We’ve heard the importance of doing this repeatedly from our enterprise customers.
3. I do believe that we offer more robustness features, like environment provisioning, deployment versioning, server pooling, in-depth logs of server startup, as well as a complete trace of the entire MCP session.
4. On the integrations side, Composio does indeed have more integrations right now, but we already have around 600 MCP servers (all with multiple tools of course) of which many are being modified by us every day to make them better. Since we support open source contributions, the catalog also grows with the community. (Quick note that you can have private servers scoped to your org).
5. I tried to benchmark our architecture vs Composio’s in terms of speed. As we mentioned in the post above, one thing that we spent a lot of time on was optimizing how fast we can do serverless with MCP servers. However, since Composio has neither source available nor any technical documentation on how they handle their servers, I couldn’t actually find any information on their architecture. One thing that they enforce as default is having a meta-tool layer with tools like composio_search_tools and composio_execute_tool. Assuming that this is a long living process, I still found that our implementation returned a list_tools response quicker (including the cold start time). If you factor in the time that it takes for them to find the right tools, their response took close to double the time. While we might explore a similar meta tool layer as an optional MCP server in the future, we do seem to on average have a better architecture in terms of speed, though the benchmarking was not entirely rigorous. (I am also unable to answer how they handle multiple users connecting to one MCP server with different OAuth configs because they don’t share that information). I plan on making a more rigorous comparison in a blog post soon, also comparing to hosting on Vercel, Cloudflare, etc..
Let me know if you have any follow up questions.
If you want to talk more, please feel free to DM me on LinkedIn (https://www.linkedin.com/in/karim-rahme/) or X (https://x.com/wen_rahme).
Wow, thanks a LOT for that comprehensive answer! Very helpful!
Two questions I didn’t manage to find answers to: * Do you have or plan support for webhooks? The scenario for us is that we’d ideally have one platform for setting up customer integrations for which we will make requests to and await request from * When you host, do you expose the access and refresh tokens for the connected integrations? The use cases for us are: * If we wanna make a feature / request that seems out of scope for Metorial * If we wanna migrate from Metorial, we don’t want to force our customers to have to reconnect * I love that we can bring our own OAuth apps which would be the default for us. But to try out an integration out or for (from our perspective) low prio integrations we’d still like to offer - do you offer your own OAuth apps that we can piggy back on. Just to save the customer from the effort of having to set up an OAuth apps foe each service. I know it comes with a lock in, but it’s worth it in some cases for us.
You’ve made me very excited to try you out, so I’ll implement support for both Composio and Metorial.
Thanks again for taking the time and efforts to answer so thoroughly!
Sent a connection request to you on LinkedIn.