sokie
The command line for Sokie. Give it an OpenAPI or Swagger
spec and every endpoint becomes a typed tool on an MCP server: run it on your
machine, then deploy it to its own address at <slug>.sokie.cloud/mcp, where
claude.ai, ChatGPT, Cursor, Claude Code and VS Code can call it.
npm i -g @abyssinia-labs/sokie
You need Node 22 or later. This installs sokie, and sok as a short alias.
From a spec to a live server
sokie login
sokie init https://petstore3.swagger.io/api/v3/openapi.json petstore
cd petstore
sokie dev
sokie deploy --create
sokie loginopens your browser to sign this computer in. The same page makes your account. On a machine you reach over SSH, add--no-browser.sokie initreads an OpenAPI 3 or Swagger 2 spec, from a file or a URL, and writes the server:sokie.json, a copy of the spec, and one Markdown file per tool intools/. Those files are the whole server, with no generated code to maintain. When the API takes a key, it asks for yours, forsokie dev, and keeps it in.sokie/dev.env, which git ignores.sokie devruns it on the same runtime a deploy uses, with an inspector to call each tool, and reloads on every save.sokie deploy --createputs it live and prints its address. After the first time,sokie deployis enough.
The quickstart walks through it, including the key the Petstore API asks for and connecting claude.ai.
Commands
| Command | What it does |
|---|---|
init | Start a server from an OpenAPI or Swagger spec. |
check | Check the server the way a deploy would, without deploying. |
tools | List the tools, or show one with its effect and findings. |
skills | List the skills in skills/, write a new one, try it, or install a server's. |
call | Call one tool as an agent would, on sokie dev or a deploy. |
test | Run the cases in tests/ on sokie dev or a deploy. |
fmt | Write sokie.json the one way Sokie writes it. |
dev | Run the server locally on the real runtime, reloading on every edit. |
edit | Open a server's files in your editor, with sokie dev running. |
pull | Bring a folder from sokie edit up to date with production. |
login, logout, whoami | Sign this computer in or out, or show who it's signed in as. |
workspace | Show, list or choose the workspace commands work in. |
deploy | Deploy the server and wait until it's live. |
deploys | List a server's deploys, compare two, or restore an earlier one. |
link | Deploy the server from its GitHub repository. |
secrets | List, set or remove the server's secrets. |
keys | Make, list and revoke API keys for CI, scripts and agents. |
domains | Serve your servers at your own domain: one for the workspace, or one per server. |
requests | Ask an owner or admin for a change that's theirs, or answer what members asked. |
logs | Show the server's calls, as far back as your plan keeps them. |
audit | Show who changed what in your workspace. |
config | Show or shorten how long CLI sign-ins last. |
update | Install the newest sokie, the way this one was installed. |
Every command takes --help, and --json when a script reads its output.
Commands that talk to Sokie take --site <url> (or SOKIE_SITE) for a site
other than sokie.sh. The CLI reference lists every
option.
Workspaces
Servers, keys, domains and the audit trail belong to a workspace. Commands work in your default one, the workspace you last opened on sokie.sh, unless you choose another:
sokie workspace list # the workspaces you're in
sokie workspace use acme # work in sokie.sh/acme from now on
sokie deploy --create --workspace acme # or for one command
SOKIE_WORKSPACE=acme does the same as --workspace for every command run
with it set, which suits CI. sokie workspace shows the one in use and why,
and sokie workspace use --clear goes back to your default.
Deleting a server, making one public, and taking away an address callers use are for owners and admins. A member asks instead, and any one owner or admin answers:
sokie requests ask delete billing-v2 --reason "Replaced by billing-v3"
sokie requests # what waits for your answer, and what you asked
sokie requests approve kd7a3f9c # or decline, with --note
An owner or admin can also make a server's production deploys wait for one
of them. A deploy that must wait is held: sokie deploy stops there and
says why, and it serves only the team, signed in, at its own address for up
to 7 days. It's listed in sokie requests for an owner or admin to approve,
which puts it live:
sokie call getInvoice --held 12 # try held deploy 12 before anyone approves it
sokie deploys # held shows as waiting for an admin
Links
- Docs
- Changelog
- Questions and bugs: [email protected]
License
Apache-2.0: see the LICENSE and NOTICE files in this package. The CLI
bundles third-party packages, whose licenses are in
dist/THIRD-PARTY-NOTICES.txt.
Using the hosted service at sokie.sh is covered by its
terms.