OpenConnector

What does this agent do, and when should you use it?

OpenConnector is an open-source connector gateway that routes AI application requests to actions for users’ authorized SaaS accounts. It exposes a catalog described as covering more than 1,000 providers and 10,000 prebuilt Actions, with API-key, OAuth2, custom-credential, and no-auth support. Clients can discover and execute Actions through the Connector SDK, the oo CLI, MCP, HTTP endpoints, or generated OpenAPI. The runtime manages connection identity, scopes, runtime tokens, action allow/block policies, temporary file transit, and redacted run logs so provider secrets remain behind its boundary. It can run locally with Docker or Node.js, on Fly.io, on Cloudflare Workers with D1 and R2, or through OOMOL’s hosted runtime.

A client browses the provider catalog, inspects an Action’s request/response schemas and required scopes, selects a connection alias, and executes the Action through the gateway. A self-hosted instance can store a GitHub connection with PUT /api/connections/github and invoke POST /v1/actions/github.get_current_user; POST /v1/actions/hackernews.get_top_stories provides a no-auth verification call. MCP-capable hosts can use http://localhost:3000/mcp, while custom clients can call /v1/actions/* and inspect /openapi.json. The Web Console supports provider browsing, credential configuration, runtime-token creation, schema inspection, Action debugging, and recent-run review.

1. A team building an enterprise assistant that must use each user’s authorized GitHub, Gmail, Notion, Slack, or Airtable account without placing credentials in the agent process.
2. An engineer adding SaaS tool execution to an existing AI product through documented HTTP endpoints or a generated OpenAPI description.
3. A local developer using an MCP-capable host who wants connected application Actions exposed at http://localhost:3000/mcp.
4. A team that wants to operate the connector runtime in its own Cloudflare account using Workers, D1, R2, and static console assets.
5. An operator investigating authorization, scope, or Action-call problems through schema inspection, debugging, and redacted runtime logs.

What are this agent's strengths and limitations?

How do you install or deploy this agent?

For a local self-hosted runtime:

docker compose up

This pulls ghcr.io/oomol-lab/open-connector:latest. To build from source instead:

docker compose -f docker-compose.yml -f docker-compose.build.yml up --build

The console is then available at http://localhost:3000 and API documentation at http://localhost:3000/docs. Source development requires Node.js 22 or newer, followed by npm install and npm run dev. OAuth providers require client credentials that you register with the relevant providers; the GitHub example can use a personal access token.

How do you use this agent?

First verify the runtime with a no-auth Action:

curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Then configure and test GitHub:

curl -s -X PUT http://localhost:3000/api/connections/github \
  -H 'content-type: application/json' \
  -d '{"authType":"api_key","values":{"apiKey":"github_pat_..."}}'

curl -s -X POST http://localhost:3000/v1/actions/github.get_current_user \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Applications can alternatively use the Connector SDK, oo connector, MCP, or /v1/actions/*; inspect /openapi.json for the generated API contract.

How does this agent compare with similar options?

FAQ