Composio: The Tool Registry That Wants to Be the npm of Agent Capabilities
A hosted catalog of 1000+ toolkits with auth handled for you. The honest case for and against the registry model.
The tell on every agent integration story is the OAuth flow nobody wants to write. You can wire a model to a Gmail-send tool in twenty minutes. You can wire it across forty users, three Google Workspace tenants, a token-refresh background job, and a revocation path that survives a compromised laptop in about six weeks. That gap is the entire reason hosted tool registries exist, and it is the reason Composio has built the project that it has.
Composio is an open-source toolkit catalog with the ComposioHQ repo sitting around 28,500 stars this week and a pushed-at timestamp from two days ago, which already says more than the marketing does. The pitch is a single line: 1000+ pre-built toolkits, tool search, context management, authentication, and a sandboxed workbench, sold as the connective tissue between your agent and every SaaS your customers already use. The CLI is shipping beta releases on a roughly daily cadence right now, with @composio/cli@0.2.31-beta.256 landing nine days ago and a steady drumbeat of point releases before that. The primary language switched to TypeScript somewhere in the last cycle, with a first-class Python SDK still maintained. MCP is in the topic list. The license is MIT. The repo is alive in a way most “agent infrastructure” repos on GitHub are not.
The product question is not whether Composio works. It does. The question is the one every team adopting a tool registry has to answer honestly, and most don’t until the second integration breaks: what exactly are you trading away in exchange for never writing an OAuth handler again?
Here is what the registry does well. The catalog covers the integrations every B2B agent actually needs: Gmail, Outlook, Slack, Notion, Linear, Jira, GitHub, Salesforce, HubSpot, Stripe, the long tail of HR and finance tooling. Each toolkit ships with the auth flow already implemented, the API client wrapped, the action signatures discoverable by the model, and a hosted callback endpoint that handles token exchange. You add a connection through the SDK, point your agent at the toolkit, and the calls work. The execution layer can run inside Composio’s sandbox or inside your own runtime, which matters more than the marketing emphasizes. The MCP support means the same toolkits register as MCP servers if you’re already invested in that protocol. Tool search exists because the catalog is now too large for a model to consider every action in a single context window, which is itself a real architectural problem solved correctly.
That is the case for. The case against is structural, and it is the same case against every hosted registry that has ever existed in software.
The integration you don’t own is the integration you can’t fix. When the Gmail toolkit returns a 429 in a way the SDK doesn’t surface cleanly, your agent gets a generic tool error and the model retries until your rate limit is gone. When a Salesforce field gets renamed in the customer’s org and Composio’s wrapper hasn’t been updated, the action fails with a serialization error that doesn’t tell you which field. When a vendor deprecates an API version, the fix lives in a PR queue you don’t control. None of these failures are hypothetical. They are the operational reality of every integration platform from Zapier on forward, and the registry model concentrates the failure mode into a single dependency whose roadmap doesn’t match yours.
The skills-as-packages pattern this newsletter has been working through all month inverts that dependency. When the Gmail-send capability lives in an npm package you publish from your own repo, the implementation is in your codebase. The 429 retry logic is yours to write. The Salesforce field name lives in a config file in your repo and changes through a PR with tests. The fix is npm version patch && git push, not a support ticket. The cost is that you wrote the integration. The benefit is that nobody can break it on a Tuesday morning without your knowledge.
Composio knows this is the tension. The sandboxed workbench, the ability to extend toolkits with custom actions, the self-hostable execution mode, all of it is the company’s answer to “what if I want to own more of the surface area.” It is a genuine answer and worth taking seriously. The honest read is that it lowers the floor of the tradeoff rather than removing it. Even with a custom action, the discovery layer, the auth layer, and the catalog metadata are still owned by Composio. That is fine for capabilities where the API is stable and the vendor is healthy. It is the wrong place to be when the integration is the load-bearing part of your product.
The right way to think about Composio in 2026 is the way you would think about any platform dependency: as a function of which capabilities sit on your critical path and which don’t. The internal sales-ops agent that summarizes Salesforce activity for the weekly meeting is a Composio fit. The customer-facing agent that takes refund actions against Stripe and writes back to the billing record is not. The line is not “internal versus external.” It is “can this fail silently for a week before we notice.” If the answer is yes, the registry is fine. If the answer is no, the integration belongs in a package you own, tested in CI, versioned with the rest of your code, and rolled back with git revert instead of a vendor escalation.
The cost story is where the registry economics get interesting. The open-source toolkit code is MIT and free to self-host. The hosted execution, the managed auth callbacks, and the connection storage have a paid plan that scales with active connections and action invocations. That is a fair model. The hidden cost, the one nobody puts in the architecture diagram, is the platform tax on every action the agent takes. Each call routes through Composio’s infrastructure, which adds latency, which adds a failure mode, which adds a vendor relationship to your runbook. The right comparison is not Composio versus writing the integration from scratch. It is Composio versus a package in your monorepo that imports a vendor’s official SDK directly and handles auth through your existing identity provider. The package wins on latency, on debuggability, and on the day the vendor announces an unrelated outage.
The release cadence is the strongest argument for taking Composio seriously as infrastructure rather than as a hosted tool. A project shipping daily beta CLI releases, pushing changes within the last 48 hours, and maintaining a TypeScript and Python SDK in parallel is a project run by people who have customers in production calling them when things break. That is the right kind of vendor to depend on, if you are going to depend on a vendor at all. Compare it to the field’s usual graveyard of repos that hit 20,000 stars during the 2024 funding wave and have not tagged a release in nine months. Composio is in the rarer category of agent infrastructure that is still being maintained like a product the maintainers expect to be using themselves next year.
The verdict for the month is the same verdict that has shown up against every category we have covered. The registry model is real, it solves a real problem, and it is the right answer for the right tier of integration. The wrong tier is the one where the integration is the product. Use Composio for the connections that would otherwise sit in the backlog for a quarter. Keep the load-bearing toolkits in code you own. The registry earns its place by handling the long tail of integrations no engineering team was going to get to. It loses its place the moment a team treats it as a substitute for owning the parts of the agent that matter most.
If this was useful, forward it to one engineer who needs less noise in their feed.