Authorize once, then keep using it across agents
Many users switch between Codex, Claude Code, Qode, OpenCrawl, and other agents. Once connection and authorization are set up in OOMOL, those capabilities stay available through oo-cli.
Connect agents through oo-cli to third-party services like Gmail and Notion, as well as your own systems. Use OOMOL Studio to build and extend your own tools.
Account access and tool capabilities should not be locked to a single agent platform. With oo-cli, they can be managed independently and called from different agents or terminal environments.
Many users switch between Codex, Claude Code, Qode, OpenCrawl, and other agents. Once connection and authorization are set up in OOMOL, those capabilities stay available through oo-cli.
When ready-made tools are not enough, you can combine third-party blocks, add cloud functions, and connect your own APIs and business logic, then keep reusing them through oo-cli across environments. Over time, that becomes your own portable toolbox.
Through oo-cli, users can connect to a mature SaaS ecosystem and call custom function tools.
OOMOL comes with support for 229 apps and 3,286 packaged tools. Start with connected services and published tools through oo-cli, then decide what is worth orchestrating further, extending, or turning into your own tool.
appsCovering common services across collaboration, development, marketing, and payments.
packaged toolsNot raw APIs, but ready-to-use actions.
If a published tool or connected service already solves the job, OOMOL's first layer of value is simple: connect it, run it, and skip building your own tool at the start.
Useful when you want to turn PR review into a team update without manual summarizing.
Summarize the key points in this PR and send them to a Slack channel.
Read the diff, extract key points, and post to the target channel.
Useful when you want to turn a spec page into trackable work without manual breakdown.
Read this Notion page, break it into tasks, and sync them to Linear.
Extract requirements, shape tasks, and write them back to Linear.
Useful when you want to pipe email inputs straight into your own service.
Read the Gmail attachment, call our PDF API, and return the result.
Download the attachment, call your API, and return the output.
In Studio, you can recombine connected services, add code, orchestrate workflows, and write new function tools. Once the tool works locally, hand it to Cloud for delivery.
Take GitHub, Slack, Notion, Gmail, and other connected services and reorganize them into your own execution chain instead of stopping at one-off use.
Turn branching, retries, coordination, and multi-step logic into repeatable workflows instead of rebuilding them ad hoc.
When existing wrappers are not enough, write new function tools and bring in your own APIs, business systems, and business logic.
Studio is not the endpoint. Once local validation is done, the next step is Cloud, then mainly back into oo-cli so agents can keep using the same path.
Use the agent to get started, then keep editing code, dependencies, parameters, and workflows yourself. Studio is for building tools, not day-to-day tool use.
Show the path from prompting to generating a tool and validating it locally.
Cloud takes over runtime, configuration, secrets, access, and delivery so you do not need to build another backend around the same implementation.
Keep the same implementation as you deliver the tool to yourself, your team, or customers.
Manage secrets, access, releases, runtime settings, and usage data in one place.

Bring runtime settings, secrets, and delivery into one backend.
Once the tool is built and delivered, agents in Codex, OpenClaw, and Claude Code keep using the same oo-cli path to search for it, inspect it, and call it.
Shows a delivered tool being searched, inspected, and called in Codex.
Once you have tools connected through oo-cli, OOMOL AI gives you the official GUI for using those same capabilities across web, desktop, and iOS.

Free users get 200 Cloud Task minutes refreshed every month. Use them to deliver the tool through Cloud first, then top up or upgrade when the quota is not enough.
Use the monthly refreshed quota to deliver the tool, confirm it keeps running, and make sure it is searchable and callable in oo-cli.
A good fit for first delivery, lightweight jobs, and everyday trial use.
You do not need to buy servers or reserve fixed capacity up front. Pay for actual call time only after the included quota runs out, and expand only when demand grows.
Start with the included quota, then scale only when you need to.
Use oo-cli to get connected services and published tools working first. When you need to produce, combine, and deliver your own tools, move into Studio and Cloud.