MCP server

Ownkube runs a hosted remote MCP server. Point any MCP-capable client at one URL, sign in once, and your agent can inspect clusters, ship deployments, tail activity, and manage environments on your behalf. It uses the same permissions and tenant isolation as your dashboard account, and Ownkube never receives your cloud keys.

MCP (the Model Context Protocol) is an open standard for connecting agents to tools. Because this is a remote server that speaks OAuth, any client with remote-MCP support connects the same way: Claude, other desktop and web assistants, agent frameworks, and your own code via an MCP SDK. The walkthrough below uses Claude as a concrete example; the URL and the flow are identical everywhere else.

The server URL

https://app.ownkube.io/api/mcp

That is the only value you need. Authentication happens in the browser: there is no token or API key to copy, and nothing secret to paste into a config file.

Connect a client

These steps use Claude. Other MCP clients follow the same shape: add a remote server, authorize in the browser, pick an organization.

Add the connector

In Claude, open Settings > Connectors, choose Add custom connector, and paste the server URL:
```
https://app.ownkube.io/api/mcp
```
Sign in to Ownkube

Claude opens your browser to authorize. Sign in to your Ownkube account the same way you sign in to the dashboard.
Pick an organization

If your account belongs to more than one organization, an approval screen asks which one this connection should act on. Choose it, then approve. The connection is bound to that organization until you remove it.
Start driving Ownkube

Back in Claude, ask for what you need, for example “list my Ownkube deployments” or “roll back the api deployment to the previous revision”. Claude picks the right tool and calls it.

What your agent can do

The MCP server mirrors the Ownkube API surface. Your agent can read and act across the resources you own.

Inspect (read):

Area	What the agent can see
Organizations	The organizations your account belongs to, and your user profile
Clusters	Clusters, their status, and lifecycle state
Deployments	Deployments, status, revision history, and live activity
Environments	Environments and their variables
Registries	Connected container registries
Cloud accounts	Connected AWS accounts and their onboarding state

Act (write):

Area	What the agent can do
Clusters	Create, cancel, and destroy clusters
Deployments	Create and delete deployments, update config, upgrade platform versions, roll back, and promote one deployment’s config onto another
Environments	Create and update environments and set their variables
Jobs	Trigger, cancel, and list job runs
Cloud accounts	Connect and reconnect AWS accounts

Write actions change real infrastructure. Tools that create, upgrade, roll back, or destroy are described so the agent confirms with you before running them, but you are in control: treat an agent with this connector the way you would treat a teammate with dashboard access.

Security model

OAuth, not keys. The connection is authorized with OAuth in your browser. There is no long-lived key to leak, and you can revoke the connector from Claude at any time.
Scoped to your account. The agent sees exactly what your account can see, in the one organization you approved. The same tenant isolation that guards the dashboard guards every tool call.
Your cloud stays yours. Ownkube never receives your AWS or GCP keys through this server, and the agent cannot read them out. Cloud access is the scoped, least-privilege role you granted during AWS onboarding.
Auditable. Every action runs through the same API as the dashboard and CLI, so writes are recorded the same way.

Multiple organizations

The connection is pinned to the organization you picked at approval time. To act on a different organization, add the connector a second time and choose the other organization when prompted, or remove and re-add it. Read-only questions about which organizations you belong to work regardless of the pinned one.