Deployment tools — MCP for your own environments

Connect an AI host to the deployments you have access to. Atrium issues your credential, registers it, and hands your host a token — you never see a hosting password.

Atrium exposes a second MCP server beside its own: your deployment tools. Where the Atrium MCP reads and curates the directory, this one operates the environments your app dev groups give you — list projects, create an application, point it at a repository, set variables, add a hostname, deploy, read logs.

Endpoint: POST https://dokploy-mcp.delphi-dialogue.com/mcp/ — JSON-RPC 2.0 over streamable HTTP. Use the trailing slash: that is the form this server answers directly today. MCP clients do not follow a redirect on POST, so a form that redirects reads as "server not found". Auth: Authorization: Bearer <your token>, issued by Atrium.

Quick start — /admin/mcp

Same page as the Atrium MCP setup, section Connect your deployment tools:

1. Sign in to Atrium → avatar menu → MCP setup.
2. Connect this host — one click. Atrium issues your hosting credential in the background, registers it, and shows the token once.
3. Copy the config block underneath. It already carries the endpoint and your token.

There is no key to mint and store on the hosting side, and no password to handle. Atrium holds the platform's admin credential, creates your account if you do not have one, and issues a credential that belongs to you.

One token at a time

Connecting rotates your token and invalidates the previous one. If you set up two hosts, the second connect silently breaks the first until you paste the new token there too. This is a property of the credential service, not a policy choice — it holds exactly one live token per person.

What you can reach

Your token carries your access, not Atrium's. You see the projects your dev-group membership grants you and nothing else, which is the same scope the app dev groups already decide. Joining an app's dev group is what gets you a project; there is no way to widen it from the AI host.

If a project you expect is missing, you are not in that app's dev group yet — request access on the app's page rather than asking for a broader token.

The web console opens through SSO

The token above is not the only way in any more. The hosting platform now sits behind an SSO bridge: Atrium's launcher tile points at /sso?rd=/dashboard/projects, which runs the OIDC leg against the OMMAX login portal, replays the seat's stored credential and forwards you into the console. Your normal OMMAX login, no hosting password anywhere in the flow.

Two things follow, and both matter:

• The brokered credential was never yours to type. Atrium generates it so the seat can hold a session and mint your token — it is the machine's door. You were never told it because it is not a login, and that has not changed now that the console is open.
• The bridge only knows seats it was told about. A seat is provisioned to the bridge on the same call that mints it. If the bridge answers has no Dokploy access provisioned, the sign-in worked and the seat is missing — connect your deployment tools first, or ask for the app's dev group.

The tools remain the faster path for the console's read-only views — list_projects, get_application_status, read_application_logs, get_deployment_history. What the tool list still does not cover — databases, compose stacks, backups, and every delete — is console work, bounded by what your own seat may do there.

Tools

Fourteen, as of the 2026-08-01 verification against the live server. Read-only first:

Then the ones that change something. Every MCP host prompts you before each call:

Ask your host for the tool list rather than trusting this table if the two disagree — tools/list is the source of truth and this page is a copy.

Wire into Claude Desktop

Merge into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows), then quit and relaunch:

{
  "mcpServers": {
    "deployments": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://dokploy-mcp.delphi-dialogue.com/mcp/",
        "--header",
        "Authorization:Bearer YOUR_TOKEN_HERE"
      ]
    }
  }
}

You can run this alongside the atrium server — an MCP host loads as many as you configure, and the two do different jobs.

Calling it directly

The transport is streamable HTTP, so a raw client must initialize first and send the returned mcp-session-id header on every later call. A tools/list without it answers Bad Request: Missing session ID, which reads like an auth failure and is not one.

curl -sD - -X POST https://dokploy-mcp.delphi-dialogue.com/mcp/ \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'

The platform's own REST API

The MCP server is a scoped front for the hosting platform's REST API. Admins who need that API directly — different verbs, bulk operations, anything the tool list does not cover — find the vendor reference and the connector settings on the hosting connector page.

Troubleshooting