Skip to main content

The problem it solves​

Most teams operate OpenAPI tooling with three unresolved gaps.

Scattered API descriptions

API descriptions live in repos, registries, service-discovery endpoints, and MCP transports. Teams need one governed catalog instead of many local interpretations.

Implicit, unaudited credentials

Credentials and runtime access need to be resolved at request time, scoped to the caller, and recorded for review instead of being copied into ad hoc scripts.

No enforcement layer

Enterprise command surfaces need a policy gate, approval path, and audit trail before a CLI or automation job can reach sensitive operations.

open-cli-toolbox gives platform teams a hosted place to own discovery, auth resolution, policy enforcement, and audit before commands reach upstream services.

How it works​

Three stages from raw OpenAPI to a governed, auditable command surface.

  1. Point at your sources

    Local OpenAPI files, URLs, RFC 9727 catalogs, or RFC 8631 service-discovery endpoints. The hosted runtime finds and fetches them automatically.

  2. Runtime governs the catalog

    open-cli-toolbox deduplicates and normalizes tool IDs, applies overlays, evaluates policy rules, and resolves per-request credentials before any execution occurs.

  3. Execute with confidence

    Use open-cli commands against the hosted runtime. Every tool call, approval decision, and auth event passes through the same boundary and lands in the audit trail.

Flow: API sources feed into open-cli-toolbox, which discovers, normalizes, applies policy and auth, records audit events, and exposes the governed catalog to open-cli commands.
Sources → governed catalog → command surface

Command surface​

  • catalogList and inspect available tools from all discovered sources.
  • explainShow schema, description, and parameter detail for any tool.
  • workflowRun multi-step operations with declarative workflow definitions.
  • dynamic-toolExecute individual OpenAPI operations directly from the CLI.
  • MCP sourcesBring stdio, SSE, and streamable HTTP MCP transports into the governed catalog.

Hosted runtime topologies​

One supported model — a hosted runtime — with deployment shapes that scale from local evaluation to enterprise hosting.

Three hosted-runtime topologies: loopback-hosted open-cli-toolbox for evaluation, shared team hosting, and brokered enterprise hosting with auth and network controls.
Left to right: local host · shared runtime · brokered enterprise

Loopback-hosted runtime

Fastest way to evaluate

Run open-cli-toolbox on the same machine and point open-cli at http://127.0.0.1:8765. It is still the remote runtime contract, just hosted locally for development.

Trade-off: Single-user footprint; you manage process lifecycle and runtime URL wiring.

Deployment models →

Shared team runtime

One hosted control plane

Host open-cli-toolbox on shared infrastructure so teams, agents, and automation all consume the same governed catalog, policy, cache, and audit boundary.

Trade-off: Requires network reachability planning, shared config ownership, and runtime auth.

Deployment models →

Brokered enterprise runtime

Security boundary first

Put open-cli-toolbox behind IdP-issued bearer auth, reverse proxies, and network controls. This is the supported production model for enterprise access review.

Trade-off: You own external perimeter controls, token lifecycle policy, and runtime hosting.

Deployment models →

Your first run​

Start open-cli-toolbox, then drive it with open-cli. See the quickstart for installation and .cli.json setup.

# Start the hosted runtime once
open-cli-toolbox --config ./.cli.json --addr 127.0.0.1:8765

# In another shell, inspect the governed catalog
open-cli --runtime http://127.0.0.1:8765 --config ./.cli.json catalog list

# Inspect or execute a tool through the runtime boundary
open-cli --runtime http://127.0.0.1:8765 --config ./.cli.json explain petstore:findPetsByStatus