Connect an MCP client such as Claude to your workspace so it can create apps and publish releases for you, straight from wherever it produced that build. The connection is made once, in the client, with a URL and your normal sign-in. There is no key to paste and no config file.

Connect

Add https://app.behindgate.com/mcp as a remote MCP server in your client. The client sends you to BehindGate to sign in, then shows what it is asking for. Choose Act as me to let the agent work across the workspaces you can already reach.

Approved connections are listed in the dashboard under Agent access, with what each one may do and when it was last used. Revoke one there and the agent loses access immediately.

To scope an agent to a single app instead, generate a token under Settings → Deploy tokens and give the client that token. It carries the target app, so the agent can publish that one app and nothing else.

Allow the upload host

A build never travels through the model. The agent asks BehindGate for a short-lived upload address, then sends the zip straight to it, and the release publishes itself once the upload has been processed.

Those bytes go to upload.behindgate.com over HTTPS, and to no other host. If your agent runs somewhere with restricted outbound network access, such as a sandbox or a corporate proxy, add that one name to its allow-list before you deploy. How to do it depends on which agent you use, so ask it to tell you what it needs allowed.

When an upload is blocked or times out, this is almost always the cause: nothing is wrong with the build, the agent simply cannot reach the upload host. Allow the host and let the agent retry. A small site, up to a 1 MB zip, can be sent in the request itself and needs no upload host at all, so a blocked agent can still publish a small build while you sort the allow-list out.

What the agent can do

Once connected, an agent can:

• list the workspaces, sites, and apps you have access to;
• create an app at a path in an existing site, such as / or /docs;
• publish a build to an app, and check whether a deploy has gone live;
• roll a deploy back to the previous release.

It publishes the same way you would from the CLI: a zip of the built site with index.html at the root of the zip, and internal links and asset URLs kept relative so the site works wherever the app is mounted. Your agent knows these rules, so you can simply ask it to publish your build.

Every release is recorded as yours, whichever agent made it, and each connection is held to what you approved for it.

An agent can also tag a release as it publishes, so ask it to label the deploy with whatever should be traceable later, such as the commit it built from. A tag is a name and an optional value, shown as name: value in the deploy history, or as just the name when it has no value.

After a deploy

A release publishes automatically once the upload has been processed, which can take up to a few minutes. The agent reports the app by name and gives you its URL, so you can open the site as soon as it is live. If a deploy does not appear, ask the agent to check its status; if it is live and wrong, ask it to roll back.