Deploy & Debug Kubernetes from Claude Code with MCP

Why connect Claude Code to your deployments

When a deployment fails, the fix usually lives in the code, but the reason lives in the platform: a build log, a crash on start, a missing variable. Moving between the terminal, the dashboard and the log viewer is where the time goes. Giving the assistant the platform’s view closes that loop. It reads the failure, finds the line in your repository, proposes the change, and after you push, checks the new deployment.

A kubectl-level MCP server can do part of this, but it needs cluster credentials and sees pods, not releases. A platform-level server works with the things you actually ship: applications, environments, preview deployments and the main deployment. That is the level this guide works at. For the difference in detail, see Kubernetes MCP servers compared.

What you need

• Claude Code installed and signed in.
• A SeaGit account on a paid plan, with an app deployed. API keys, which the MCP server needs, are not available on the Free plan.
• An API key from Settings → API keys. Give it a name like claude-code-laptop so you can recognize it in the audit log.

Step 1: make the key read-only first

Every tool runs with the key’s permissions, so the key is your safety setting. In the API keys list, open Scopes on the new key and allow only get and list. With that key the assistant can look at everything and change nothing: the redeploy and promote tools come back with “API key does not have permission for this action”.

When you want Claude to act, widen the scopes on that key or create a second key for it. Keeping one key per assistant means you can revoke one without breaking the others.

Step 2: connect SeaGit to Claude Code

Put the key in an environment variable, then add the server. The server uses the Streamable HTTP transport and expects the key as a bearer token:

export SEAGIT_API_KEY=sgt_live_…   # the key from Settings → API keys
claude mcp add --transport http seagit https://seagit.com/api/mcp \
  --header "Authorization: Bearer $SEAGIT_API_KEY"

Run /mcp inside Claude Code. The seagit server should show as connected with ten tools. To share the setup with your team, add --scope project and single-quote the header so .mcp.json stores the variable name, not your key.

Step 3: ask what is running

Start with a question you can check against the dashboard:

“Which of my apps are deployed in production, and are any failing?”

Claude calls list_environments to find the production environment, list_app_instances to get one row per app in it, and list_deployments for any instance whose status is not healthy. The answer comes back as a short table with each deployment’s status and URL. Lists return only the fields an assistant needs and stop at 100 rows, so a large account does not flood the conversation.

SeaGit’s model matters here. An application is defined once and has an instance in each environment. Each instance has one main deployment, which is production, and can have preview deployments, each on its own URL, usually one per pull request. See Deployments for the full picture.

Step 4: debug a failed deployment

This is where the setup pays off. Ask about a specific failure:

“The preview for pull request 42 failed. Read the log and tell me why.”

Claude finds the deployment with that pull request number, calls get_deployment_logs, which returns the latest 100 lines by default and up to 500, and reads the error. Because it also has your repository open, it can point at the cause: the Dockerfile that copies a file that is not there, the start command that listens on the wrong port, the variable the code reads but the app does not define.

Fix the code with Claude as usual and push. If your environment builds previews from pull requests, the push starts a new preview deployment, and you can ask Claude to watch its status the same way.

Step 5: redeploy and promote, with your approval

Two tools change live infrastructure. redeploy runs a deployment again with its current configuration, the dashboard’s “Try again”. promote_deployment copies a preview deployment onto the main deployment and deploys it. The main deployment keeps its name and URL, so production traffic moves to the new version without a DNS change.

Both are marked as write tools in the MCP tool list, and promote as destructive, so Claude Code stops and asks before running them. The platform’s own rules still apply on top: if the environment requires evaluations to pass before promotion, the tool returns the same refusal the dashboard shows, and Claude reports it instead of working around it.

“The preview for my branch looks good. Promote it to main.”

Claude names the deployment it will promote and waits for you to approve the call.

Cursor and VS Code

The same server works in any client that supports Streamable HTTP. In Cursor it is an entry in mcp.json with a url and an Authorization header; in VS Code it is a .vscode/mcp.json entry with type http that prompts for the key once. Claude Desktop connects through the mcp-remote bridge. The exact snippets are in the SeaGit MCP server docs.

Keeping it safe

• One key per assistant and per machine, named so you can recognize it.
• Read-only scopes until you want the assistant to act.
• Every call is checked against the key’s scopes and your team’s policies, like any API call, and recorded in the audit log under the key’s name.
• Revoke or rotate the key in Settings → API keys and the assistant is cut off on its next call.
• Never paste the key into a chat or commit it. Keep it in an environment variable or the client’s secret prompt.

Frequently asked questions