What you can ask it

Once connected, your AI assistant can call any of the tools below. You don't need to know their names — just describe what you want, and the assistant picks the right ones.

Projects and environments

See your projects and their services — "What Kuberns projects do I have, and what services are running in each?"
Get a full status overview of one environment — resources, topology, and current state in one call. "Give me an overview of my staging environment."

Deploys and builds

Review recent deploy/build history — "What were my last 5 builds for this environment, and which ones failed?"
Pull a specific build's logs — "Show me the build log for that failed build."
Check the deploy-agent's session — the state of the temporary agent that analyzed your repo and prepared its configuration, including any prompts it's waiting on.
See the generated Dockerfile — the actual Dockerfile Kuberns built and deployed for a service.
Actually build that Dockerfile locally — "Test the Dockerfile against my local repo and tell me if it really builds." This runs a real docker build against your checked-out code (only works when the MCP server runs on your own machine, alongside Docker). It's the only way to confirm the generated Dockerfile matches your real code instead of guessing from stored metadata.

Environment variables and build arguments

Check which variable names are configured — "Is DATABASE_URL actually set on Kuberns for this environment?" Only checks names, never values.
Compare a value without exposing it — Kuberns returns a SHA-256 hash of each configured value. Hash your own known-good value the same way and compare; matching hashes mean matching values, without either value ever leaving your machine or Kuberns' side in the clear.
Catch missing Dockerfile build arguments — flags any ARG with no default that has no configured value.

Resources and runtime

List every resource in an environment — servers, background workers, databases, queues — with status and health.
Pull live runtime logs — stdout/stderr from the running container (not build logs). "What's this service printing right now?"
Review self-healing history — crash detection, classification, and auto-restart attempts, useful for spotting a silent crash-loop.

Domains

Check custom domain status — "Is my custom domain active, and if not, what stage is it stuck at?" (CNAME verification, A-record verification, SSL generation, or activation.)

Billing

Get a billing summary — due, paid, past-due, and available credits.
Check if you can afford to start a resource — "Do I have enough credits to restart this server?"

Support

See what a support ticket needs — the valid ticket types and section/sub-section options, so your assistant fills the form correctly on the first try.
File a support ticket — directly from your conversation with the assistant.

For anything that feels broken, you rarely need to reach for individual tools yourself — see Debugging your application with MCP for how diagnose_deploy_failure chains all of the above into one report.