Octri CLI MCP server

@octri/cli

octri is the command line for your Octri project. It does what the dashboard does: push a spec, build SDKs, publish docs, and work through the errors those SDKs report from production.

Octri takes an OpenAPI spec and gives you a documentation site, client libraries in ten languages, an MCP server, and monitoring for the API behind all of it. See octri.dev.

Node 20 or newer.

Install

npm install -g @octri/cli
octri --help

Start here

octri auth login
octri projects use
octri specs push ./openapi.yaml

auth login prompts for your email and password, and for your authenticator code if you have two-factor on. projects use with no argument opens a picker.

specs push waits for the pipeline, not the upload. Your spec parses in about a second, then the doc pages, search index and changelog get written behind it. The spinner names the stage it is on.

Build an SDK

octri sdk audit                            # what is costing you, scored
octri sdk build --lang go,typescript --download

In a terminal, sdk build draws a lane per language and repaints it through generating, verifying, packaging, installing, ready. Piped or under CI it prints append-only lines instead, and exits non-zero if any language fails, so it works as a build step with no extra flags.

sdk audit scores the spec and marks which findings the generator can fix on its own. octri sdk audit apply writes one in.

For a look at real generator output without spending a build:

octri sdk preview --lang go
octri sdk preview --lang go --show client.go

Publish docs

octri docs versions publish <specId>
octri docs versions label <specId> "Stable"
octri docs domain set docs.example.com

docs domain prints the CNAME and TXT records to create, then docs domain verify checks them.

Monitoring

Reads and triage run on your session, so they need nothing but a login:

octri monitoring summary
octri monitoring issues --status unresolved
octri monitoring issue <id>
octri monitoring resolve <id>

monitoring issue prints the stack and marks which frames resolved against uploaded source maps. When none of them did, the release those errors came from has no symbols, and the CLI says so.

The two upload commands work differently. They talk to the monitoring service directly with an ingest token, because a CI job has one secret and no way to log in:

# CI
octri monitoring sourcemaps upload ./dist \
  --url "$MONITORING_URL" --token "$MONITORING_TOKEN" \
  --environment "$MONITORING_ENVIRONMENT" --release "$GIT_SHA"

# your own machine, already signed in
octri monitoring sourcemaps upload ./dist

Run octri monitoring config for the three values to store as CI secrets. The release you upload under has to equal the release your SDK reports at runtime, or the service has nothing to pair a trace with.

Commands

Shortened. The full README is on GitHub.