---
title: Introduction to OOMOL
description: Understand how OOMOL connects Apps, Agents, Skills, and product
  backends without exposing account credentials to prompts or application code.
lang: en
canonical_url: https://oomol.com/en/docs/introduction/
markdown_url: https://oomol.com/en/docs/introduction.md
---

# Introduction to OOMOL

OOMOL gives AI Agents and product backends a shared way to work with connected Apps. A user authorizes an account once, then an Agent, Skill, or backend can call the permitted tools without receiving the account password or raw provider token.

Use OOMOL when you need to:

- Give an Agent access to tools from Apps such as Gmail, GitHub, Notion, or Slack.
- Reuse the same connected Apps across supported Agents.
- Package repeatable Agent instructions as Skills.
- Add user-authorized App integrations to a product backend.
- Run the open-source Connector runtime in your own environment.

## Start with your goal

| Goal | Start here |
| --- | --- |
| Use connected Apps from an Agent | [Use OOMOL with an AI Agent](/en/docs/agents/) |
| Call your own connected Apps from backend code | [Connector overview](/en/docs/connector/) |
| Let each user of your SaaS connect their own accounts | [SaaS integration overview](/en/docs/saas/) |
| Keep the runtime, credentials, and logs in your environment | [OpenConnector overview](/en/docs/openconnector/) |

If more than one row seems relevant, read [Choose an integration path](/en/docs/choose-a-path/) before creating credentials or deploying infrastructure.

## How a tool call works

1. A user connects an App and approves the provider permissions.
2. OOMOL stores the resulting credential inside the selected hosted or self-hosted runtime.
3. The Agent, Skill, or backend discovers an action and its input schema.
4. The caller selects a connected account and sends the action input.
5. The Connector runtime calls the provider and returns the result.

The caller works with action IDs, schemas, connection labels, and results. Provider passwords and raw OAuth tokens stay inside the credential boundary.

## The product surfaces

### Apps

An App represents a third-party service or a built-in service available through OOMOL. Connecting an App creates an authorized connection that tools can use.

Browse the [App catalog](/en/apps/) or open an App guide from **App Connections & Permissions** when you need permission and usage details for a specific service.

### Agents and oo CLI

`oo` is the command-line entry point used by Agents with terminal access. The install pages provide setup instructions for Codex, ChatGPT, Claude Code, other Agents, and MCP clients.

Start with [Use OOMOL with an AI Agent](/en/docs/agents/).

### Skills

A Skill is a reusable instruction package that teaches an Agent how to complete a task. A Skill can combine OOMOL App tools with local scripts and the Agent's own reasoning.

Browse [OOMOL Skills](/en/skills/) to package tool selection and task instructions into a repeatable workflow.

### Connector

Connector is the connection and execution layer. It authorizes accounts, stores credentials, exposes action schemas, and runs provider calls. Start with the [hosted Connector](/en/docs/connector/), a [SaaS integration](/en/docs/saas/), or [OpenConnector](/en/docs/openconnector/).

## Credentials stay behind a boundary

The boundary depends on the path you choose:

- OOMOL hosting stores and refreshes credentials for hosted Agent and SDK calls.
- A Connector SaaS project separates project credentials and end-user connections.
- A self-hosted OpenConnector deployment stores credentials and execution records in infrastructure you operate.

Review scopes before connecting an account, expose only the actions required for the task, and keep API keys out of browser code, prompts, and repositories.

## Next step

Follow the [Quickstart](/en/docs/agents/) for the shortest path to a completed tool call. If you are building a product integration, continue with [Choose an integration path](/en/docs/choose-a-path/).