Wrapping the client rather than the API is what keeps this small and current — nothing to update when OpenStack adds a command. It also means the blast radius is exactly the blast radius of the credentials in your clouds file, which for an admin project is considerable. If you want a narrower grant, the place to make it is the OpenStack project and role behind the credentials, not the server.
A small server that drives the OpenStack command-line client. It does not reimplement the API — it runs the CLI in an environment where the CLI already works, which means whatever your credentials can do, this can do, and nothing more.
- Execution of OpenStack commands from the conversation, including the compound ones that would otherwise be several invocations chained by hand
- Whatever surface your installed client covers, rather than a curated subset — the tool is the CLI, so it does not fall behind the platform
- Targeting by cloud name, since credentials come from your existing configuration file and it can hold several clouds
- Two ways to launch: from a local clone, or straight from the git URL with uvx and no checkout
The OpenStack CLI must be executable in whatever environment the server runs in, and authentication credentials for the target cloud must already be in a `clouds.yaml` — auth URL, username, password, project id and name, user domain, region and interface. No separate key goes to the server; it uses what the CLI uses. Python with uv: `uv sync` then run the server module, or launch it with uvx directly from the repository URL. The project is `simple-openstack-mcp` (0.1.0 in pyproject) and is built on fastmcp.