Control DADA Cloud from an AI agent (MCP)

What it's for

Run the platform by talking to an AI. DADA Cloud ships a Model Context Protocol (MCP) server, so an assistant like Claude can create projects, deploy apps, set environment variables, spin up sandboxes, manage databases and domains, and read your logs — on your behalf, using your own login. You ask in plain language ("deploy this image and give it a Postgres"); the agent calls the right platform tools and reports back.

The server exposes 61 curated tools drawn from the same API the web console uses. It is not the whole API: the tool list is an allowlist, chosen so an agent carries a surface it can actually reason about. The agent only ever sees projects your account has a role on, and every action is authorized exactly as if you had clicked it yourself.

• Every tool and argument: MCP tool reference
• Worked end-to-end flows: MCP recipes

Endpoint and identity

Hitting the endpoint without a token returns 401 with a WWW-Authenticate header pointing at the metadata document. That is the handshake working, not an outage: a spec-compliant client reads it and starts the browser login by itself.

Connect from Claude Code

The fastest path — nothing to paste, no keys.

1. Add the marketplace: `` /plugin marketplace add DadaDevelopment/dada-cloud-console ``
2. Install the plugin: `` /plugin install dada-cloud@dada-cloud ``
3. On first use your browser opens to sign in with your DADA ID account. Approve, and the tools are ready.

The plugin runs a small local bridge that performs the standard browser login for you, so you never handle a URL, a client id or a token.

Connect from Claude Desktop

1. Settings → Connectors → Add custom connector.
2. URL: https://console.dada-tuda.ru/mcp
3. Open Advanced settings and set OAuth Client ID to dada-mcp. Leave Client Secret empty.
4. Save. On first use your browser opens to sign in with DADA ID.

Connect from Cursor, Windsurf, or any other MCP client

Point the client at https://console.dada-tuda.ru/mcp over Streamable HTTP.

A client that runs on your own machine and takes its OAuth callback on http://localhost:<port> or http://127.0.0.1:<port> can pin the static client id dada-mcp (public, no secret). Those loopback callbacks are whitelisted on any port, so the pin works from any laptop without anyone registering anything.

Do not pin dada-mcp from an agent that runs on a server. A hosted agent (a self-hosted gateway, a remote harness, anything whose callback is an https URL on your own host) sends a redirect URI nobody has whitelisted, and Dada ID rejects the login with invalid_redirect_uri before the sign-in page renders. Dynamic Client Registration is not open on Dada ID either, so the client cannot register its own callback yet. Until it is, a server-side agent authenticates with a bearer token:

Authorization: Bearer <your-token>

The same header is the answer for any client that cannot do a browser login at all.

To check the server is reachable before you blame your client, ask it for its discovery document. This needs no credentials:

curl -sS https://console.dada-tuda.ru/.well-known/oauth-protected-resource

{"resource":"https://console.dada-tuda.ru/mcp",
 "authorization_servers":["https://id.dada-tuda.ru/realms/master"],
 "scopes_supported":["openid","profile","email","offline_access",
                     "read","builds:read","builds:write","deploy:write"],
 "bearer_methods_supported":["header"]}

A 401 from the endpoint itself, carrying WWW-Authenticate: Bearer resource_metadata="…", is the same handshake seen from the other side. Both mean the server is up.

What the agent gets besides tools

The server also serves the two other halves of MCP, which good clients surface in their UI.

Prompts — guided runbooks with arguments, which walk an agent through a multi-step flow instead of leaving it to improvise:

Resources — read-only reference material an agent can pull for grounding:

Permissions and safety

• The agent acts as you. It can only touch projects your account has a role on, and write actions still require the matching role — exactly like the console. There is no service identity and no elevation.
• Two tools are marked destructive (deleteBox, deleteEnvVar) and 20 are marked read-only. Clients that honour those hints will ask before running a destructive one.
• There is no way to delete an app, a database or a project from the agent surface, on purpose.
• Secret env values are never readable back. listEnvVars masks them.
• The agent cannot run commands inside your sandbox. A box hands out its own local MCP endpoint that you add to your client as a second server, so your code and your model credentials never pass through our API.
• Credential reveals are audited. getDatabaseCredentials requires an explicit reveal=true and records every call.

Troubleshooting

Gotchas

• Sign in with the same DADA ID account you use for the console at console.dada-tuda.ru.
• Deploys and other changes are asynchronous. The agent gets an operation to watch, and should confirm the app is Healthy before declaring success.
• The one-time dadabox_ session token a box returns is shown exactly once and is never retrievable — only its hash is stored. Mint a new one with getBoxConnection if you lose it; minting does not revoke the old one.