Connect an agent
Let Claude, Cursor, VS Code or any MCP client deploy and look after your Dekka projects through the Dekka MCP server.
Dekka runs a remote Model Context Protocol server, so an AI agent can work with your account the way you would in the dashboard. It can create projects, deploy a repository, add a database and connect it, read build logs when a deploy fails, set variables and apply templates. The agent signs in with an API key you create, sees only what that key allows, and every change it makes is recorded in your organisation's activity log as coming from an agent.
The server lives at one address for every client.
https://mcp.dekka.cloud/mcpIt speaks Streamable HTTP and keeps no sessions, so each request carries its own key.
Quick start
The fastest way is the Agents tab in your organisation's settings. Choose what the agent may do and which projects it reaches, and Dekka creates the key and shows the setup for your client with the key already filled in. There's a Test connection button to check it before you leave the page.
To do it by hand, create an API key and add the server to your client. In Claude Code that's one command.
claude mcp add --transport http dekka https://mcp.dekka.cloud/mcp \
--header "Authorization: Bearer $DEKKA_API_KEY"Then ask for something real, such as "deploy acme/storefront to a new Dekka project and tell me its URL" or "why did the last deploy of the api service fail?" Setup for Claude Desktop, Cursor, VS Code, Codex and Windsurf is in MCP clients.
What the agent can do
The tools cover the work people do most often, grouped like the dashboard.
| Area | What the agent can do |
|---|---|
| Account | Find out who it's acting for, the plan and what's been used |
| Projects | List, read and create projects and their environments |
| Services | Create a service from GitHub or an image, change settings, restart, stop and delete |
| Deploys | Deploy, list deployments, read build logs with errors marked, and roll back |
| Data | Add PostgreSQL, Redis, a bucket or a queue, connect services and read connection strings |
| Variables | List variables with secrets hidden, set them and delete them |
| Templates | Find a template, plan it with its inputs, plan a dekka.yaml or a Docker Compose file |
| Changes | See pending changes, apply them and discard them |
| Domains | Add a custom domain and verify its DNS records |
| Observe | Search logs, read runtime logs and metrics, and follow long operations |
| Docs | Search and read these docs to answer how-to questions |
Every tool and its arguments are listed in MCP tools. The server also offers each docs page as a resource at dekka://docs/<slug>, and three ready-made prompts for deploying a repository, adding a database and finding out why a deploy failed.
How changes happen
Most actions take effect straight away, just as they do in the dashboard. Creating a service starts its first deployment, and adding a database creates it.
Templates, blueprints and Docker Compose files are planned first. The plan comes back as a list of changes for the agent to show you, and nothing changes until it calls apply_changes with confirm: true. Deleting a service, deleting a variable and rolling back work the same way, returning a preview of what would happen until they're confirmed. Good clients ask you before confirming, and you can tell an agent to always ask.
Keep it safe
Start with a read-only key, and give a key write or full access only when you want the agent to make changes. A project token limits an agent to one project, and adding ?read_only=true to the server address hides every tool that changes something, whatever the key allows. MCP security explains scopes, confirmation and how to guard against prompt injection.
Limits
Each key can make 240 tool calls a minute, on top of the API's usual limits. Agents act through the same API as everything else, so plan limits, roles and validation all apply to them in the same way.