Agents & MCP

MCP (Model Context Protocol) is a standard way for an AI client to call tools on a remote server. ClikDeploy runs an MCP server that exposes platform operations as tools, so an assistant can deploy an app, read its logs, or check a server without you writing any glue code.

The tools are the same operations the dashboard and the CLI use — they go through the same API, with the same permission checks. Connecting an assistant does not give it more access than the credential you hand it.

The server speaks streamable HTTP at https://clikdeploy.com/mcp. Create an API key first (Settings → API Keys), then point your client at that URL and send the key as an X-API-Key header.

Claude Code

claude mcp add --transport http clikdeploy https://clikdeploy.com/mcp --header "X-API-Key: YOUR_API_KEY"

Cursor

{
  "mcpServers": {
    "clikdeploy": {
      "url": "https://clikdeploy.com/mcp",
      "headers": { "X-API-Key": "YOUR_API_KEY" }
    }
  }
}

Claude Desktop

Claude Desktop only launches local servers from its config file, so a remote HTTP server goes through mcp-remote.

{
  "mcpServers": {
    "clikdeploy": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://clikdeploy.com/mcp", "--header", "X-API-Key:YOUR_API_KEY"]
    }
  }
}

Settings → Integrations has an MCP card that fills your real key into these snippets, plus a one-click install link for Cursor.

There are two kinds of credential, and the difference matters.

• An API key (starts with cd_live_) acts as you, with full access to your account. Send it as X-API-Key, or as Authorization: Bearer …. Use this for your own machine. See REST API.
• A ClikOAuth access token is scoped. The MCP server intersects the tools it serves with the scopes the token actually holds, so an assistant holding a read-only token never even sees the tools that would change something. Send it as Authorization: Bearer …. See ClikOAuth.

Scopes are named after toolsets: deploy:read, apps:write, and so on. :write implies :read for the same toolset. A token with observe:read gets the read-only monitoring tools and nothing else.

The endpoint publishes RFC 9728 protected-resource metadata at https://clikdeploy.com/.well-known/oauth-protected-resource, and an unauthenticated request comes back as a 401 with a WWW-Authenticate header pointing at it. A client that supports OAuth discovery can therefore start a sign-in flow on its own, with no key pasted anywhere.

A toolset is a named group of tools. With no selection, the server serves every non-admin toolset — over 200 tools. That works, but most models behave better with a smaller list: fewer tools means less to choose between and fewer wrong turns.

Narrow the list with the toolsets query parameter, comma-separated:

claude mcp add --transport http clikdeploy "https://clikdeploy.com/mcp?toolsets=deploy,observe" --header "X-API-Key: YOUR_API_KEY"

An unknown name is rejected with a 400 listing the valid ones. These are the toolsets available to a normal account:

If you would rather keep the full surface but a short tool list, add ?toolmode=search. The client then sees a handful of pinned tools plus search_tools and call_tool, and the assistant looks up what it needs instead of being handed everything at once.

Two rules limit what an assistant can do on its own.

• Tools that change something ask first. Every mutating tool gets an extra confirm field. Called without confirm: true, it returns a confirmation request instead of acting — including a warning and any safer alternatives for destructive ones. Turning on auto-execute for your account (the set_assistant_mode tool, or Settings) skips that gate.
• Admin toolsets are never served by default. The admin- toolsets are only included when you name them in ?toolsets=, and every admin API route behind them independently checks the caller's admin role on the server. Naming an admin toolset on an account without admin rights gets you tools that refuse to run, not access.