Kapten MCP · Early access

An SRE team,
inside your agent.

You built it with Claude. Now ship it, run it and fix it from the same conversation. Kapten connects your coding agent to a crew of specialised agents that provision, deploy, secure and watch your app, in your own cloud account.

Request early access Browse the workflows
claude~/my-appkapten · connected
  2. kapten · analyze_repo(path: ".")Plan
    3 services · web, api, worker · needs postgres, redisrunning·
  3. kapten · plan_environment(env: "staging")Plan
    plan #142 · 14 resources · est. $138/morunning·
  4. kapten · review_security(plan: 142)Plan
    0 critical · 1 medium: /metrics is publicrunning·
  6. kapten · apply_plan(plan: 142, approval: you)Act
    14/14 created · api, web, worker healthyrunning·
Animated example · sample session · tool names illustrative

Connect in one line

terminal
claude mcp add --transport http kapten https://mcp.kapten.io/mcp
claude_desktop_config.json
{
  "mcpServers": {
    "kapten": {
      "type": "http",
      "url": "https://mcp.kapten.io/mcp"
    }
  }
}
.cursor/mcp.json
{
  "mcpServers": {
    "kapten": { "url": "https://mcp.kapten.io/mcp" }
  }
}
.vscode/mcp.json
{
  "servers": {
    "kapten": { "type": "http", "url": "https://mcp.kapten.io/mcp" }
  }
}

Then ask your agent anything about your infrastructure. The first call opens a browser to sign in and pick which environments it may see.

Protocol
MCP over HTTPS, OAuth
Clients
Claude Code, Claude Desktop, Cursor, VS Code
Permissions
Observe · Plan · Act
Runs in
Your cloud account and region

The deploy gap

Writing it got fast.
Shipping it didn’t.

An agent can write a whole application in an afternoon. Production still asks for the work of a platform team: builds, infrastructure, secrets, releases, alerts, incidents and a bill to keep an eye on. That is the part most AI-built software never gets past.

Read the whitepaper
What production addsWithout itWho handles it
A reproducible build“It works on my machine”, and nowhere else.ShipwrightBuild & containers
InfrastructureA cluster, a network and a database you have never configured.BosunInfrastructure
Secrets and configAPI keys in the repo, the same key in every environment.WardenSecurity review
ExposureA database reachable from the internet because a template said so.WardenSecurity review
ReleasesA deploy that half-succeeds and no way back.HelmsmanReleases
Health and alertsYou learn it is down from a customer.LookoutObservability & incidents
IncidentsThree hours of logs to find the change that broke it.LookoutObservability & incidents
CostA preview environment nobody deleted, billed for a month.PurserCost

How it works

One request.
A whole crew behind it.

Ask in plain words. Kapten breaks the request down, runs the specialists in parallel, and brings back a single plan with the diff, the cost and the risks. You approve. Only then does anything change in your account.

Your agent sends a request over MCP to Kapten, who delegates to seven specialist agents. One plan returns for your approval; only approved plans act in your cloud account.Your agentClaude CodeCursor · Desktop · VS Code“Ship this repoto production.”MCPplanOrchestrationKaptenPlans and delegatesMerges the findingsAsks before actingNavigatorArchitectureShipwrightBuild & containersBosunInfrastructureHelmsmanReleasesWardenSecurity reviewLookoutObservability & incidentsPurserCostapproved plansYour cloud accountScoped role · 900 s sessionsKubernetes clusterManaged PostgresObject storageSecretsDNS & TLS

The crew

Eight specialists. Each with a job, and a boundary.

One generalist agent with cloud credentials is a risk. A crew of narrow specialists, each with its own tools and limits, is an operating model you can reason about.

  • 01 / 08Orchestration

    Kapten

    Turns your request into a plan, hands each part to the right specialist and brings back one decision for you.

    1. Reads the request and the environment it applies to
    2. Splits the work between specialists and runs them in parallel
    3. Merges their findings into one plan with a diff, a cost and a risk note
    4. Asks for approval before anything changes

    BoundaryNever applies a change you have not approved.

  • 02 / 08Architecture

    Navigator

    Reads your repository and maps the application: services, ports, dependencies, data stores and the routes between them.

    1. Detects services, runtimes, build commands and listening ports
    2. Finds the databases, caches, queues and external APIs the code expects
    3. Proposes an environment topology and draws it on the canvas
    4. Flags what it could not infer and asks instead of guessing

    BoundaryRead-only on your code. Proposes; never commits.

  • 03 / 08Build & containers

    Shipwright

    Makes the application buildable and reproducible: a container image per service, built the same way every time.

    1. Writes or reviews a Dockerfile per service
    2. Pins base images and removes build-time secrets
    3. Builds and tags addressable images
    4. Explains a failed build in terms of your code, not the log

    BoundaryOpens a pull request for code changes. Never pushes to your default branch.

  • 04 / 08Infrastructure

    Bosun

    Prepares the ground in your cloud account: cluster, network, managed databases, storage and secrets.

    1. Plans the cluster, networking and managed services for the environment
    2. Creates databases, buckets and secrets with the right scope
    3. Tags every resource it creates so it can be found and removed
    4. Produces a plan you can read before anything is provisioned

    BoundaryActs only through the scoped role in your account, on resources it created.

  • 05 / 08Releases

    Helmsman

    Ships the change: health-gated rollouts, configuration, domains, and a rollback that re-points instead of rebuilding.

    1. Rolls out images behind health checks
    2. Applies environment variables and domains
    3. Watches the rollout and stops it on failing health
    4. Rolls back to the previous image in one step

    BoundaryProduction releases need a named owner’s approval.

  • 06 / 08Security review

    Warden

    Reviews what will be exposed and who can reach it before it ships, and keeps reviewing after.

    1. Checks public endpoints, open ports and TLS
    2. Finds secrets in code, images and environment variables
    3. Reviews IAM scope, network policy and database exposure
    4. Writes findings with a severity and a concrete fix

    BoundaryReports and proposes fixes. Remediation goes through the normal plan and approval.

  • 07 / 08Observability & incidents

    Lookout

    Watches the running system and, when something breaks, starts from what changed.

    1. Correlates errors with the latest deployment and config change
    2. Reads the logs and metrics of the affected service
    3. Proposes a likely cause with the evidence attached
    4. Drafts the incident timeline and the follow-ups

    BoundaryInvestigates freely in read-only mode. Mitigations are proposed, not taken.

  • 08 / 08Cost

    Purser

    Keeps the bill honest: estimates before you provision, and finds idle or oversized resources after.

    1. Estimates the monthly cost of a plan before it is applied
    2. Finds idle environments, oversized nodes and orphaned volumes
    3. Suggests rightsizing with the expected saving
    4. Enforces the budget caps you set per environment

    BoundaryNever deletes a resource. Cleanup is a plan like any other.

What the crew sees

Every agent watches
its own instruments.

The Lookout reads errors against releases. The Purser reads the bill against usage. The Warden reads exposure against policy. Each one turns what it sees into a finding you can act on, through a plan.

  • LookoutObservability & incidentswatching

    Error rate · api · production · last 30 min

    Sample error-rate line for the api service: about 0.3% until deploy 9b41e0, a spike to 6.8%, a rollback, then back under 1% within three minutes.0%2%4%6%8%SLO 1%deploy 9b41e06.8%rollbackrecovered−30 minnow

    Errors went from 0.3% to 6.8% right after deploy 9b41e0. The rollback brought them back under 1% in three minutes.

    Sample error rate, api service, production (percent per minute)
    MinuteError rateEvent
    -300.3%
    -290.4%
    -280.3%
    -270.35%
    -260.3%
    -250.4%
    -240.3%
    -230.35%
    -220.3%
    -210.4%Deploy 9b41e0
    -201.2%
    -193.6%
    -185.9%
    -176.8%
    -166.4%
    -156.6%
    -146.1%Rollback
    -133.2%
    -121.1%
    -110.5%
    -100.4%
    -90.3%
    -80.35%
    -70.3%
    -60.3%
    -50.4%
    -40.3%
    -30.3%
    -20.35%
    -10.3%
    00.3%
  • PurserCost$751/mo

    Monthly cost by environment

    Idle 21 days

    2 previews nobody has touched. Cleanup plan saves $160/mo.

    Previews are a quarter of the bill. Purser proposes the cleanup as a plan; nothing is deleted until you approve it.

    Sample monthly cost by environment, US dollars
    EnvironmentCostState
    production$412Active
    staging$138Active
    preview · pr-212$96Idle 21 days
    preview · pr-198$64Idle 21 days
    dev$41Active
  • WardenSecurity review1 blocking

    Findings by severity · staging

    Sample findings ring: 1 critical, 2 high, 4 medium, 7 low; 14 in total.14findings
    • Critical1
    • High2
    • Medium4
    • Low7
    • CriticalPostgres reachable from 0.0.0.0/0staging
    • HighPAYMENTS_API_KEY shared by 3 environmentsall
    • High/metrics exposed on the public domainapi

    One critical exposure blocks the release. Each finding ships with a concrete fix that goes through a plan.

Illustrative · sample data Panels show what each agent reads through observe-tier tools. The numbers are not from a real account.

In the conversation

It feels like asking a colleague who knows the whole stack.

No new dashboard to learn. Ask what is running, why a deploy failed or what last month cost, and follow the crew as it works, from the terminal or editor you already have open.

  • › What is running in staging, and which version?
  • › Why did the last deploy of the API fail?
  • › Roll back web in production to the previous image.
  • › Which environments has nobody touched in 14 days?
claude · ~/acme/payments
Welcome to Claude Codekapten mcp server · 14 tools loaded
3 tool calls · scoped to your role
Animated example · sample services · no live cloud connection

Workflows

Start from a recipe, not a blank prompt.

Multi-agent workflows for the jobs every team meets: the first deploy, a readiness review, an incident, a cost review. Each one says which specialists it brings in and where it stops to ask you.

All 9 workflows

Guardrails

Agents do the work. You stay in command.

Three permission tiers, granted per environment. Reading and planning are free; acting always goes through a plan you approved.

  1. 01Observe

    Read the state of projects, environments, deployments, logs, metrics and costs.

    • “What is running in staging?”
    • “Why did the last deploy fail?”
    • “What did we spend last week?”

    No approval. Every call is logged.

  2. 02Plan

    Produce a dry-run: the exact resources, configuration and releases a change would create, with cost and risk.

    • “Plan a production environment for this repo”
    • “Plan a rollback of the API”
    • “Estimate a preview per pull request”

    No approval. Nothing changes until the plan is applied.

  3. 03Act

    Apply an approved plan: provision, deploy, scale, roll back, rotate a secret.

    • “Apply plan #142”
    • “Deploy api@3f2c1a to staging”
    • “Roll back web in production”

    Explicit approval per plan. Production requires a named owner.

  • Plans before changes

    Every change starts as a dry-run you can read: resources, releases, cost and findings. Nothing is applied from a chat message alone.

  • Approval per plan

    Act-tier tools need an approval token tied to one plan. Approving one plan never approves the next.

  • Named owners for production

    Production environments name the people who can approve. An agent cannot approve its own work.

  • Scoped to environments

    When you connect a client you choose which projects and environments it can see. Everything else does not exist for it.

  • Budgets as hard limits

    Set a monthly cap per environment. Plans that exceed it are rejected before they reach your account.

  • An audit trail you own

    Every tool call is logged in Kapten, and every cloud action lands in your own provider audit log, under the scoped role.

Guide: guardrails for agents that touch production

Architecture

Your tools on the left. Your account on the right. Nothing of yours in between.

The MCP server checks who is asking and what they may do. The control plane plans and coordinates. Resources exist only in your account, created through a role you control, with sessions that expire after fifteen minutes.

MCP clients connect over HTTPS to the Kapten MCP server, which forwards scoped tool calls to the control plane. The control plane acts in your cloud account through a scoped role with short-lived sessions.Your toolsClaude CodeTerminalClaude DesktopDesktop appCursorEditorVS CodeEditorHTTPS · MCPInterfaceKapten MCP serverOAuth sign-inEnvironment scopesObserve · Plan · Act checksEvery call loggedCoordinationControl planeThe crew of agentsPlans and dry-runsApprovals and ownersRun historytoolsrole900 sYour accountAWS · your region · your billKubernetes clusterManaged databasesObject storageSecretsLoad balancer · TLS

Tool catalog

What your agent can call.

19 tools across three tiers. Names are illustrative during early access; the public reference will list exact parameters.

Guide: connect your client

ObserveNo approval. Every call is logged.

  • list_projectsProjects, environments and their owners.
  • get_environmentServices, data stores, domains and current versions.
  • describe_topologyThe architecture graph: who talks to whom.
  • get_deploymentA deployment, its build output and its health.
  • tail_logsLogs for a service, scoped to an environment and a time window.
  • get_metricsLatency, errors, saturation and restarts.
  • get_costsSpend by environment and service, from your cloud bill.

PlanNo approval. Nothing changes until the plan is applied.

  • analyze_repoDetect services, ports, dependencies and build methods.
  • plan_environmentDry-run the infrastructure for a new environment.
  • plan_releaseDry-run a deployment, a rollback or a config change.
  • estimate_costMonthly estimate for a plan, line by line.
  • review_securityExposure, secrets and IAM findings for an environment.
  • run_workflowStart a multi-agent workflow and stream its progress.

ActExplicit approval per plan. Production requires a named owner.

  • apply_planApply an approved plan. Requires an approval token.
  • deployRelease an image to an environment behind health checks.
  • rollbackRe-point a service to its previous healthy image.
  • scale_serviceChange replicas or limits within the environment’s caps.
  • set_secretCreate or rotate a secret without echoing its value.
  • create_previewSpin up an isolated environment for a branch.

Questions, answered plainly.

What is MCP?

The Model Context Protocol is an open standard that lets AI assistants call external tools. Kapten exposes your environments, deployments and the crew as MCP tools, so any compliant client can use them.

Do I need to know Kubernetes or Terraform?

No. The crew plans and operates the infrastructure, and explains each plan in plain terms. The resources are standard, so a specialist can take over later without migrating anything.

Can the agent break production?

Not on its own. Act-tier tools require an approval tied to a specific plan, production approvals require a named owner, and budget caps reject plans that exceed them. You can revoke access at any time by removing the role.

Which clouds are supported?

AWS is the focus of early access. Other providers are on the roadmap; we confirm support for your project during onboarding.

Does my code or data leave my account?

Your workloads and data stay in your cloud account. Navigator reads the repository you point it at to plan the build. Logs and metrics are read on demand for investigations you start.

Is this available today?

Kapten MCP is in early access. Tool names and the endpoint on this page are illustrative and may change before the public reference ships. Request access and tell us which client you use.

Go deeper

Read before you connect.

Build with Kapten

Start with one service.
Build from there.

Tell us what you want to deploy. We review each request and follow up about fit and onboarding on your preferred cloud.

Request early access Explore the demo

Free during early access. No card required. Cloud usage billed separately.