# open-connector [Health: Active]

**Category:** 🔗 Aggregators  
**Repository:** https://github.com/oomol-lab/open-connector  
**GitHub Stars:** 6184  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/open-connector

## Description
Open-source auth gateway connecting 1500+ SaaS providers to AI agents through SDK, CLI, MCP, HTTP, and OpenAPI.

## Claude Desktop Quick Installation
No confirmed install details yet, so no config is published. Follow the setup steps in the repository above.

## Documentation

## What open-connector does

open-connector provides a connector gateway between AI agents or applications and services such as GitHub, Gmail, Notion, BigQuery, Google Analytics, Supabase, Airtable, and Slack. Its catalog contains more than 1,000 providers and 10,000 prebuilt Actions. Actions expose structured request and response schemas, required scopes, and executor information so applications can inspect an operation before running it.

The gateway is designed to keep provider credentials outside the agent process. Agents receive provider metadata, safe connection labels, and execution results, while credentials remain inside the runtime boundary. Supported credential patterns include API keys, OAuth 2, custom credentials, and providers that require no authentication.

## How it works

An agent or application connects through MCP, HTTP, OpenAPI, the Connector SDK, or the oo CLI. It can search the catalog, inspect an Action, choose a connection alias, and submit the operation to the gateway. The gateway applies connection identity, scopes, runtime-token rules, and Action allow or block policies before invoking the provider executor.

Remote MCP access is supported through the gateway's MCP endpoint, while direct HTTP calls use the `/v1/actions/*` routes. The generated OpenAPI document is available at `/openapi.json`. A built-in OAuth 2.1 authorization server supports dynamically registered clients, PKCE S256, and revocable access tokens with policy-scoped permissions.

A local Web Console covers connector browsing, credential setup, runtime-token creation, and usage inspection. Runtime data can include redacted execution logs, recent failures, tool-call trends, and recent calls. Temporary file transit is also supported through local or S3-compatible storage.

## Setup and configuration

Self-hosted deployments can run with Docker or Node.js 22+ and use SQLite or PostgreSQL for state. File transit can use local storage or an S3-compatible service. The project also supports deployment on Cloudflare and lists additional managed deployment platforms, alongside OOMOL's hosted runtime.

With a self-hosted runtime, the operator manages storage and OAuth applications. The hosted option provides managed OAuth and a hosted runtime without requiring deployment or OAuth app setup. The Connector SDK offers a TypeScript HTTP client, while the `oo connector` command provides a local relay for searching, inspecting, and running Actions.

## Tools and capabilities

- MCP access for MCP-capable agent hosts through the gateway endpoint.
- HTTP and OpenAPI access for custom clients.
- Connector SDK support through `OpenConnector`, `Connector`, and `ProjectConnector` client variants.
- Catalog search and Action inspection before execution.
- Credential support for API keys, OAuth 2, custom credentials, and no-auth providers.
- Runtime tokens, scopes, connection aliases, and Action allow/block policies.
- OAuth 2.1 authorization with dynamic client registration, PKCE S256, and revocation.
- Web Console administration, credential configuration, and runtime debugging.

## Limitations and notes

Self-hosting transfers responsibility for storage and OAuth application configuration to the operator. Provider names and trademarks belong to their respective owners. The available catalog, Actions, scopes, and provider authentication requirements can vary by connector.

_Full upstream README: https://allmcps.com/mcp/open-connector/readme_