oomol-lab/open-connector

OpenConnector – a unified connector gateway for AI agents

What it is – An open‑source runtime that lets AI agents (or any app) call thousands of third‑party services (GitHub, Gmail, Notion, Slack, BigQuery, …) without the agent having to manage OAuth flows or API keys itself. It exposes a catalog of 1 000+ providers and 10 000+ pre‑built Actions through a single HTTP/OpenAPI endpoint, a CLI, or the MCP protocol.

Why it matters – Modern LLM‑powered assistants need reliable, auditable access to the tools users already use. OpenConnector provides a durable “credential boundary”: the agent only receives metadata and results, while the actual secrets stay inside a controlled runtime.

---

Core capabilities

Feature	What you get
Provider catalog	Ready‑made definitions for popular SaaS products (GitHub, Gmail, Supabase, etc.) with request/response schemas and required scopes.
Credential handling	Built‑in support for API keys, OAuth2 (including token refresh), custom credentials, and completely unauthenticated services.
Inspectable Action contracts	Each Action ships with a JSON schema, required scopes, and a lazy‑loaded executor source, making debugging and policy enforcement easy.
Runtime controls	Per‑connection tokens, scope limiting, allow/block policies, temporary file transit, and redacted run logs.
Multiple deployment models	• Managed SaaS on OOMOL (no infra to run)
• Cloudflare Workers (D1, R2, static assets)
• Docker / Node.js (SQLite or PostgreSQL, optional S3‑compatible storage)
• Kubernetes Helm chart
• Fly.io Docker host
Developer tooling	• Connector SDK (thin TypeScript HTTP client)
• oo CLI (local relay for searching, inspecting, and running Actions)
• MCP endpoint for agents that speak the MCP protocol
• OpenAPI spec (/openapi.json) for any HTTP client
Web console	UI for browsing providers, configuring credentials, creating runtime tokens, viewing logs, and testing Actions.

---

Typical use cases

• AI‑assistant platforms that need a reusable, auditable way to call user‑authorized services (e.g., a chat‑bot that can read a user’s Gmail or write to Notion).
• Enterprise SaaS products that want to embed “agent‑powered” workflows without storing every third‑party credential in their own database.
• Developer teams building custom agents who prefer a self‑hosted runtime for compliance or data‑sovereignty reasons.
• Prototypers who want a quick “Pipedream‑like” catalog of actions without writing OAuth plumbing.

---

Getting started (quickest path)

1. Run the Docker image

   docker compose up   # pulls ghcr.io/oomol-lab/open-connector:latest
   

2. Open the local console: http://localhost:3000 (or dev console at http://localhost:5173).
3. Test a no‑auth action:

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

4. Connect a real provider (e.g., GitHub) via the console or with a simple PUT request as shown in the README.
5. Use the Connector SDK or oo CLI from your agent code to discover actions and invoke them.

---

Where it lives

• Source: https://github.com/oomol-lab/open-connector
• License: Apache‑2.0 (project code only; third‑party provider assets are not covered).
• Community: Contributions welcome via pull requests; see CONTRIBUTING.md for provider‑addition guidelines.

---

TL;DR

OpenConnector is a self‑hostable (or SaaS‑hosted) gateway that centralises OAuth and API‑key management for AI agents, exposing a massive catalog of ready‑to‑use actions through a clean HTTP/OpenAPI interface. It’s designed for anyone building LLM‑driven tools that need secure, auditable access to the myriad SaaS services users already rely on.