A first-party admin CLI for agentic, multi-deployment administration?

[rndmcnlly]

The gap

Open WebUI has a rich admin API, but there is no first-party way to drive it non-interactively. Anyone administering an instance from scripts, CI, or (increasingly) an LLM agent ends up re-implementing the same HTTP calls per task, per deployment. There is no uniform control surface for "do an admin operation against this OWUI instance" outside the browser.

oikb already shows the project values agent-facing surfaces: it ships an OpenAPI tool server so an LLM can trigger syncs, check status, and query history. I want to surface the general case behind that specific one.

The use case

I administer two production OWUI deployments (a personal one and a UCSC-wide one) and increasingly do it agentically: I point a coding agent at an instance and have it manage users, models, tools, configs, knowledge bases, and so on. The thing that makes this reasonable is a single CLI with consistent verbs and --json everywhere, so the agent can read state, act, and verify without me hand-writing API calls each time.

This is the shape I think is missing from the project: a thin, scriptable, agent-and-CI-friendly admin control surface that covers the whole admin API, not just one workflow.

Evidence it's real (and a scope reference)

I built and maintain owui-cli (on PyPI) to scratch this itch. It's a single-file thin client over existing endpoints, currently covering roughly these resources and operations:

Resource	Operations
tools	list, show, deploy, pull, pull-all, delete, valves (get/spec/set/set-field/unset-field), user-valves (get/spec/set/set-field/unset-field)
functions	list, show, deploy, pull, pull-all, delete, toggle, toggle-global, valves + user-valves (same as tools)
skills	list, show, deploy, pull, pull-all, delete
models	list, show, create, update, delete, set-tools, set-filters, pull-all
knowledge	list, show, files, create, delete, add-file, remove-file
files	list, show, upload, delete
groups	list, show, create, delete, members, add-user, remove-user, update
users	list, find, show, add, delete, update
chats	list, search, show, delete
configs	show, get, set, admin, admin-set
prompts	list, show, create, delete

Every command supports --json. There's also a baked-in schema command that documents the admin endpoints, since the API isn't fully consistent across resources (e.g. tools/functions use /id/{id}, models use ?id=, knowledge/users use /{id}, groups use /id/{id}).

I'm sharing this purely as a scope reference, not as a code donation. Your team's agents (or humans) should take, remix, or rewrite whatever is useful and own the design. The single-file structure suits my pedagogical preferences; it is not a recommendation for how the project should build this.

The ask

Would the maintainers consider an official admin CLI living in-org? I'm not asking you to adopt my repo or my maintenance burden. I'm asking whether the capability belongs here, and if so, offering my tool's surface as a starting point for scoping.

I think now is a sensible moment to consider it: oikb has just established the precedent that agent-facing admin surfaces are in scope for the project. A general admin CLI is the natural generalization of the direction the tool server already points toward.

Things I'd genuinely want your read on

• CLI vs. MCP/tool server. A first-party MCP server over the admin API might be the more natural agent surface than a CLI. I don't think these compete: a clean CLI is trivially wrappable and is the better fit for shell scripts and CI, while MCP is the better fit for in-chat agents. But if your mental model is MCP-first, I'd love to hear it, and a CLI could be framed as the complementary scriptable layer.
• Relationship to oikb. To be clear, this would not subsume oikb. oikb is a stateful ingestion daemon with 44 connectors, a scheduler, and a dedicated server-side diff endpoint. An admin CLI is a stateless thin client over existing endpoints. The only overlap is the KB/file primitives. They're complementary: provision a KB with the admin CLI, hand its ID to oikb for ongoing sync.

Happy to help with scoping, write up endpoint inventories, or contribute, in whatever form is most useful to you.