Comment by fsto
8 hours ago
We’ve just begun implementing Composio. Would love to reconsider if you help clarifying the main differences. From my perspective it looks like you have more robustness features to me as a developer and you’re fully open source (not just the client) whereas Composio has more integrations. But would love your input to clarify. Congrats on the launch!
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).