Skip to main content
Suga runs a hosted Model Context Protocol server that lets an AI agent drive your Suga account the way you would through the dashboard: list projects, edit environment configuration, set variables and secrets, watch deployments, and read logs. The server lives at a single endpoint:
It speaks streamable HTTP and authenticates with OAuth, so any MCP client that supports remote servers can connect with just the URL. No API keys to copy or rotate.

The safety model

The most important thing to understand before you connect an agent: the agent can prepare changes, but it can never deploy them. Every environment in Suga has a Draft (a working copy of its configuration) and an Apply step that pushes the Draft to running infrastructure. The MCP server has no apply or deploy tool, and no delete_project or delete_environment tool, by design. Anything the agent changes about a service, its variables, its volumes, or its scaling lands in the Draft and waits for you.
Four tools act immediately rather than going into the Draft: create_project, create_environment, add_custom_domain, and remove_custom_domain. Removing a custom domain takes it out of service straight away.
When an agent makes a change, the tool response includes a deeplink back to the affected environment in the Suga UI. You open it, review the rendered diff, and click Apply yourself. That visual review is the gate that keeps a misread instruction or a hallucinated container spec from reaching production.

What an agent can do

  • View your projects, environments, and deployments
  • Create projects and environments
  • Edit draft configuration: services, volumes, scaling, networking
  • Set and remove environment variables and secrets in the draft
  • Manage custom domains and connected GitHub repositories
  • Read logs, events, and metrics

What it can't do

  • Deploy or publish. Configuration changes stay as drafts until you review and apply them yourself
  • Read secret values. Secrets are write-only; only names and metadata are ever returned
  • Delete projects or environments
The agent acts as you: it can only see and touch the organizations you’re a member of, and every action is subject to your existing permissions.

Before you start

  • A Suga account. If you don’t have one, sign up first.
  • An MCP client that supports remote servers with OAuth (Claude Code, Cursor, Claude Desktop, and others).

Connect your agent

Add the server from your terminal:
Then start Claude Code and run /mcp. Select suga and choose Authenticate to open the Suga sign-in and approval flow in your browser. Once you approve, the tools are available in your session.

Authorize access

The first connection sends you through a browser flow:
1

Sign in

You’re taken to the Suga login page. Sign in with the same account you use for the dashboard.
2

Review and approve

A consent screen shows exactly what the connected app can and can’t do. Confirm it’s the app you’re connecting, then approve.
3

Return to your agent

You’re redirected back and the connection completes. Your agent can now call Suga tools. You won’t need to repeat this unless you disconnect or the session expires.

A typical workflow

Once connected, you can ask your agent to work on Suga in plain language. A first deployment usually flows like this:
  1. The agent creates a project and an environment.
  2. It adds a container, either from an image or by connecting a GitHub repository to build from source.
  3. It sets any environment variables and secrets the container needs.
  4. It hands you a deeplink. You open it, review the pending changes, and click Apply.
  5. The agent watches the deployment and reports back when it’s live.
Steps 2 and 3 happen in the Draft. Nothing changes in your running infrastructure until you apply.

Good to know

  • Secrets are write-only. An agent can set or rotate a secret, but no tool ever returns a secret’s value, only its name and metadata. New values take effect the next time you apply.
  • Building from source needs the GitHub App. Install the Suga GitHub App from the dashboard first; the agent can’t start that install flow itself.
  • Custom domains wait on DNS. A newly added domain stays pending until you add the DNS records the agent surfaces for it.

Deployments

How drafts, deployments, and rollbacks work

Environments

Projects, environments, and configuration

Logs

Reading logs from your services

Configuration

Environment variables, secrets, and references

Need help?