The mcp resource puts an agent's tools inside your stack. The flisk mcp command does the reverse: it lets an assistant control the stack. Run it over stdio, and a coding assistant can check the machine, start services, read their status, and read bounded logs.
Connect it
The Flisk docs give the same entry for the MCP clients they name, Claude Code, Cursor, and Codex:
{
"mcpServers": {
"flisk": {
"command": "flisk",
"args": ["mcp"]
}
}
}
The server runs from the project folder, so it finds the project's configuration. Set the working directory in your client, or the assistant will be looking in the wrong place.
What it can do
The docs list four jobs:
-
doctordiagnoses the container runtime and port conflicts. -
upanddownstart and stop services. -
statusreturns structured health, so the assistant can see whether APIs and databases are ready. -
logsreturns a bounded window of output for debugging.
The bounded logs matter. A full log dump fills an assistant's context and hides the one line that matters. A tail with a limit keeps the conversation focused.
A loop that works
Give the assistant a procedure, not a goal:
- Run
doctor. Stop and report if the runtime is missing. - Run
upfor the services the task needs. - Poll
statusuntil the services are ready, or until a failure appears. - On failure, read the logs for the failing service only.
- Report what you found, with the status output as evidence.
up returns before the stack is ready, so the poll is what gives the assistant a finish line. Without it, the assistant may report success after the start command returns, which is a common failure.
What to keep out of its reach
A control plane can start and stop everything, so decide the limits before you connect it. Stopping a local stack is low-risk. Deleting volumes, which holds your data, is not, and the docs treat the volume as something you remove explicitly. Keep those steps with a person.
Generated files are also off limits. The contributor guidance says not to edit generated output, and an assistant that changes it will be overwritten on the next generation. Put that rule in the project instructions the assistant reads.
Check it by hand first
Before you hand the stack to an assistant, run the same loop yourself: flisk doctor, flisk up, flisk status --json, and flisk down. If the loop fails for you, it will fail for the assistant, and the error will be harder to read inside its output.
Summary
flisk mcp gives an assistant a structured way to run the local stack: check, start, poll, read bounded logs, and stop. Give it a procedure with a finish line, keep destructive steps with a person, and test the loop yourself before you connect the assistant.
Top comments (0)