DOCSEARCHbyAlgolia
Submit Docs

OOMOL Documentation

website·Indexed 34 days ago

https://oomol.com/docs

A platform for connecting AI agents and SaaS applications. Features include the oo CLI, OOMOL MCP for AI client integration, and a TypeScript SDK. The ecosystem offers multiple integration paths, including OOMOL Flow, ProjectConnector for end-user accounts, and the open-source OpenConnector for self-hosting and custom OAuth app setups for services like Google, Slack, GitHub, and HubSpot.

Tokens
33.6K
Snippets
81
Records
229
Agent score
70%

What's inside OOMOL

  1. Overview of OOMOL Flow deployment options

    OOMOL Flow is a workflow automation product where AI agents and humans collaborate on typed workflows. There are two deployment paths:

    1. OOMOL Flow (Hosted): The official managed version accessed via the OOMOL Console. OOMOL manages the deployment and provides managed OAuth apps for integrations.
    2. Open Flow (Self-hosted): An open-source beta version where the user operates the runtime on their own infrastructure. The user is responsible for persistent storage, tokens, networking, backups, upgrades, and Connector/OAuth setup.

  2. Overview of OpenConnector

    OpenConnector is an open-source, self-hostable connection runtime developed by OOMOL. It allows organizations to maintain full control over credential storage, provider connections, network access, action policies, logs, and upgrades within their own environment. The runtime exposes provider actions via MCP, HTTP, OpenAPI, and a web console, ensuring that raw provider credentials remain inside the deployment boundary while agents and clients interact with schemas, connection labels, and scopes.

  3. Overview of OOMOL OpenConnector

    OOMOL OpenConnector is an open-source connector service that allows agents or internal tools to interact with external services (e.g., GitHub, Gmail, Notion, Hacker News) while keeping provider credentials, permissions, and execution history within the user's own environment. It exposes typed action schemas via MCP or HTTP, ensuring agents see only safe account labels and scopes rather than raw provider tokens.

  4. Overview of OOMOL Connector

    OOMOL Connector is a hosted connection service that allows individuals and teams to connect third-party Apps (e.g., Gmail, GitHub, Notion, Slack) and execute approved actions from an Agent or trusted backend. OOMOL manages the OAuth flows, credential storage, and token refresh, ensuring that application code and Agents can perform actions without ever receiving raw OAuth tokens.

  5. Overview of Connector for SaaS integration model

    Connector for SaaS acts as an account-connection layer. The integration consists of two phases:

    1. Setup Phase (Administrator): Performed in the OOMOL Console to create the Project, provider configurations, and API keys.
    2. Runtime Phase (Backend): Your product backend manages authorization links, handles callbacks, and executes actions using the Project API key for authentication.

  6. Overview of OOMOL and its core value proposition

    OOMOL provides a shared interface for AI Agents and product backends to interact with connected third-party Apps. Its primary purpose is to allow Agents, Skills, or backends to call permitted tools without ever receiving the user's account password or raw provider OAuth tokens. This creates a secure credential boundary where the Connector runtime handles the actual provider call and returns only the result to the caller.

  7. Understand shared OOMOL Connector concepts

    Across all OOMOL Connector products, the following terminology is used:

    • App: The user-facing service being connected (e.g., Gmail, GitHub, Slack).
    • Provider (or Service): The technical Connector integration that defines authentication, actions, schemas, and API request logic.
    • Action: A specific callable operation exposed by a provider (e.g., gmail.search_threads). Each action has a defined input schema and return data format.
    • Tool: The interface through which an Agent, CLI, or MCP client discovers and invokes an action.
    • Agent: An entity that selects a tool, provides parameters, and processes the result to complete a task.
    • Skill: A reusable set of instructions that guides an Agent on which tools to use, the order of execution, and constraints to follow.

  8. Understand OOMOL Connector permission boundaries

    The ability to execute an action in OOMOL is determined by the intersection of four permission boundaries. An action can only be executed if it satisfies all of the following:

    1. Provider OAuth scopes (what the account owner authorized).
    2. Personal or Team connection access (who is allowed to use the connection).
    3. Allowed actions (the specific action allowlist configured for the connection).
    4. CLI, MCP, or SDK identity scope (the identity of the caller).

  9. Understand OOMOL Team collaboration boundaries

    A Team in OOMOL Connector serves as an internal collaboration boundary. It allows members to use authorized App connections without needing raw provider tokens. Teams are intended for coworkers, collaborators, and internal Agents. For isolating end-users in a SaaS product, use the Connector for SaaS instead.

  10. Use OpenConnector for self-hosted runtimes

    The OpenConnector client is used when running the open-source Connector server on your own infrastructure (localhost, Docker, etc.). It mirrors the Connector client's API surface, allowing you to switch from the managed service to a self-hosted runtime with minimal code changes.

  11. Configure Microsoft OAuth for OpenConnector services

    To connect Microsoft Graph providers such as Outlook, OneDrive, or Excel to OpenConnector, you must register a Microsoft Entra application. These services require a tenant value (e.g., common, organizations, consumers, or a specific tenant ID) to determine the identity platform segment used in authorization and token URLs.

    Supported Service IDs:

    • outlook (Outlook)
    • one_drive (OneDrive)
    • excel (Excel)

  12. Implement a lightweight connector runtime on Cloudflare

    OOMOL's OpenConnector allows for a serverless deployment on Cloudflare, avoiding the need for traditional VM or container management. The architecture utilizes the following Cloudflare services:

    • Cloudflare Workers: For the connector runtime.
    • D1: For maintaining runtime state.
    • R2: For temporary transit files.
    • Static Assets: To serve the Web Console.