The headline numbers in open-connector are 1,000 providers and 10,000 prebuilt actions, but the count is not the design. The design is a boundary: provider secrets stay inside the gateway, and the agent gets metadata, safe account labels, and results. An agent that can call your Gmail or your BigQuery never holds the credential that makes the call work.
OpenConnector, from oomol-lab, describes itself as an open-source connector gateway for AI agents and an alternative to Composio. A user connects an app account once, and after that the same catalog is reachable from application code through a TypeScript SDK, from a local agent relay through the oo CLI, from agent hosts over MCP at http://localhost:3000/mcp, and from anything else over HTTP with a generated /openapi.json. Same provider IDs, same action IDs, same contracts across all four surfaces.
What the boundary actually buys you
Credential handling covers API keys, OAuth2, custom credentials, and no-auth providers, which is the boring part that every integration layer has to get right. The part worth copying is the set of runtime controls around it: connection identity, scopes, runtime tokens, action allow and block policies, temporary file transit, and redacted run logs.
Read that list as an answer to the question "what happens when the agent asks for something it should not have?" An allow and block policy is enforcement at the gateway rather than a hope pinned on the prompt. Redacted run logs reduce the chance that the audit trail becomes a second copy of the secret. Runtime tokens give you a credential to issue that is not the provider credential itself. All of this is the project's documented architecture rather than an audited one: the README describes no independent security review, so read the executor source before you rely on any of it.
The action contracts are inspectable by design: request and response schemas, required scopes, and lazy-loaded executor source. An agent can read what an action expects and what permission it needs before calling it, and a human can read the executor that will run. Compare that with a closed tool surface where the only way to learn what a call does is to make it.
Deployment is the other half of the pitch
A gateway that holds every provider credential your users connect to it is exactly the component teams do not want to hand to someone else. OpenConnector ships four paths: local Docker or Node, Fly.io with SQLite on a persistent volume, a Cloudflare-compatible deploy on Workers with D1 for state and R2 for transit files, and OOMOL's hosted runtime. The stated reason for the hosted option is honest: teams blocked on OAuth approval or facing a launch deadline take the hosted auth now, with the same provider and action contracts available later if they move to a private runtime.
The Cloudflare path is documented down to the steps, including copying wrangler.example.jsonc to a local variant, applying D1 migrations, and setting secrets before npm run deploy:cloudflare. Getting started locally is docker compose up against the published image, with a console at localhost:3000 and generated API reference at /docs. The README lists Node 22 or newer for the Node runtime, which the container path covers for you. License is Apache-2.0.
Where it fits, and what to check yourself
The README is clear about the intended users: agent products that need durable access to the work apps people already use, teams adding agent workflows that need stable action contracts, and teams that want hosted auth without giving up the option to self-host.
Two things to verify against your own provider list before committing. First, the provider and action counts in the badges are read live from OOMOL's hosted catalog, so confirm the providers you actually need are present in the deployment you plan to run. Second, a shared catalog is a shared shape: an action written for the common case may not expose the one field your integration needs, and because the executor source ships with the runtime you can read exactly why, then extend it or contribute the change. Both are fair trades for keeping OAuth complexity and provider tokens out of the agent process, which is the part most teams should not be rebuilding.
GitHub: https://github.com/oomol-lab/open-connector
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
Top comments (0)