Most orchestration integrations stop at listing runs. Here the recovery path is covered too — replay an execution, restart from the failed task, resume something that is waiting, or backfill a period that never ran — which is the work you do at the moment something breaks, and exactly when you do not want to be clicking through a UI. Two configuration notes save time: on OSS, disable the EE group or the model will offer tools your instance cannot serve, and the container needs a host address it can actually reach, which on macOS and Windows means host.docker.internal rather than localhost.
Kestra's own Python MCP server, published as a container image, exposing the orchestration platform's API to an MCP client.
- flow — the flow definitions in your namespaces, read and managed
- execution — runs started, inspected and followed
- logs — the output of a run, without opening the Kestra UI
- replay, restart and resume — a failed or paused execution driven from where it stopped
- backfill — historical runs filled in over a period
- namespace and files — namespace-scoped file management
- kv — the key-value store a flow reads its configuration from
- ee — the Enterprise Edition tool group, which OSS users switch off
- Tool groups individually disabled through KESTRA_MCP_DISABLED_TOOLS, so the surface matches your edition and your appetite
A reachable Kestra API in KESTRA_BASE_URL and a tenant in KESTRA_TENANT_ID. Authentication depends on edition: Enterprise uses KESTRA_API_TOKEN, while OSS installations can use KESTRA_USERNAME and KESTRA_PASSWORD. Runs from the published container image, so no Python environment to manage. OSS users should set KESTRA_MCP_DISABLED_TOOLS to ee, since those tools have nothing to talk to.
One command plus a key — docker run -i --rm --pull always -e KESTRA_BASE_URL -e KESTRA_TENANT_ID -e KESTRA_MCP_DISABLED_TOOLS -e KESTRA_MCP_LOG_LEVEL -e KESTRA_USERNAME -e KESTRA_PASSWORD ghcr.io/kestra-io/mcp-server-python:latest, then supply credentials