MCP server
Let an AI assistant operate klickops directly, with your permissions and your audit trail.
On this page
What it is
The MCP server is a small program that runs on your machine and exposes klickops to an AI assistant as a set of tools. The assistant can then list your apps, read logs, check why a deployment is unhealthy, and make changes, by calling the same API the web interface calls.
It is a client, not a second backend. It holds no state, talks to klickops and to nothing else, and authenticates as you. Everything an assistant does through it is subject to your role and lands in the audit log under your name.
When you'd use it
- You want to ask "why is the checkout app unhealthy" and get an answer that read the actual logs.
- You are already working in an assistant and would rather not switch to a browser.
- You want a change proposed from real state rather than from a guess.
An assistant with your permissions can do what you can do, including deleting things. Give it a token scoped to what it needs rather than your own admin session, and prefer a viewer token for anything exploratory. See API tokens.
Setting it up
The Settings area of klickops has an Integrations page with the install command and the exact configuration block for the common assistants. It also lists every tool the server exposes, generated from the same catalog the server itself reads, so what you see there is what the assistant gets.
Authentication uses the config file klops auth login already wrote, or KLICKOPS_SERVER and KLICKOPS_TOKEN if you would rather be explicit.
What the assistant can do
Tools are named for what they do: klickops_list_apps, klickops_get_app_logs, klickops_restart_app, klickops_query_database. Reading is the bulk of it, and the useful part: an assistant that can see your real state stops guessing.
Changes are possible too, and they inherit the permission checks of the endpoints behind them. There is no separate confirmation layer in the MCP server, so a token that may delete an app allows an assistant to delete an app.
Limits and gotchas
- Secrets are never returned. Tools surface key names, never values, exactly as the API does. An assistant cannot read your credentials out of klickops.
- It is local. There is no hosted variant today, so the server runs where you run it and its network peer is your klickops and nothing else.
- It has no memory. Every call reads current state. That is the point, and it means an assistant cannot act on something it saw ten minutes ago.
- Scope the token. The single most useful habit: viewer for questions, editor only when you mean it.
Related
- API tokens for scoping what an assistant may do.
- klops CLI for the same surface driven by a script instead.