Discovery
Check whether ready-made tools already exist
You do not need to build a new path on day one. Search published tools first, then decide where the real gap is.
- Search before you judge
- Avoid rebuilding from guesswork
Start in oo-cli before you build anything else
Let Codex, Claude Code, and local terminal workflows search, inspect, and run ready-made tools first. When they stop short, continue naturally in Studio and Cloud.
Why CLI
CLI lowers the barrier to getting real usage started
The goal is not to design the full integration stack upfront. The goal is to let the agent finish a real task first. Search, inspect, and run in terminal before anything else.
Usage
Run it directly in terminal and agent workflows first
CLI gets input inspection, invocation, and results working first. After that, you can decide whether the same capability should also become an API, MCP, or web entry point.
- Finish a real task first
- Choose the next layer with evidence
01 / oo-cli
Search, inspect, and call tools directly in oo-cli first
This is not a replacement for docs. It is the first layer in the product path. Confirm that agents can actually use a tool before you decide what deserves further expansion.
Search ready-made tools first
Check whether someone has already published what you need instead of building from zero on day one.
Inspect the inputs and boundaries first
Understand what the tool expects and where it fits before you decide whether it is the right path.
Run one real task first
Let the agent actually call the tool and use the result to decide the next step instead of designing from guesswork.
oo-cli invocation demo
Show a published tool being searched, inspected, and called in Codex.
02 / Studio + Cloud
When ready-made tools stop short, continue into Studio and Cloud
CLI is not the endpoint. It is the start of the path. When you need custom behavior, move into Studio to generate and validate your own tool. When it must keep running and be delivered, Cloud takes over.
Generate and complete your own tool in Studio
Let the agent help with code, dependencies, and parameters, then validate the actual tool you need locally.
Validate locally before you decide to deliver
Prove the task and the edge cases before you invest in the delivery layer.
Deliver it back into CLI through Cloud
Once delivered, the tool returns to oo-cli where it can be searched, inspected, and called again through the same path.
Cloud console preview
When the tool needs runtime, configuration, and delivery relationships, let Cloud handle that layer.
StudioLocal validationCloudDelivered back to CLI
Start Using It
Get the usage path working before you decide to build
CLI does not require API, MCP, delivery backend, and ops decisions on day one. Validate the task with ready-made tools first, then choose what deserves more investment.
Use first
Ready-made tools
Search / Inspect / Run
The default CLI path
Start from published tools
Search packages, inspect inputs, and run them directly in terminal to see whether existing tools are already enough.
A better fit when you want real-task proof before a full integration design.
Build later
Extend when needed
Studio / Cloud
Where the path continues
Move into Studio and Cloud only when needed
When ready-made tools stop short, generate, validate, and deliver your own tool through the same path instead of starting over.
Get it working first, then decide whether custom development is worth it.
Start with oo-cli, then decide which next layer is worth building
Let the agent finish the task in oo-cli first. When custom behavior is needed, continue into Studio and Cloud for extension and delivery.