> For the complete documentation index, see [llms.txt](https://docs.flowcp.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flowcp.ai/guides/publish-your-mcp-server.md).

# Publish your MCP server

Every MCP server has two environments: **development** (always available for testing) and **production** (where real users connect). Use the **Deploy** page to promote a server from development to production, and to recall it when needed.

## Development vs. production

|                 | Development                            | Production                                                              |
| --------------- | -------------------------------------- | ----------------------------------------------------------------------- |
| URL             | `/mcp/dev/<dev-slug>`                  | `/mcp/<server-id>` (or your [custom slug](#customizing-the-server-url)) |
| Who can connect | Workspace members only                 | Anyone with a valid token                                               |
| When available  | Always (unless the server is disabled) | Only after a successful deploy                                          |
| Status          | `Development`                          | `Production`                                                            |

The development URL is always shown on the Deploy page regardless of whether the server has been deployed. Use it to test tools, skills, widgets, and prompts before your users see anything.

## One server per branch

Each branch (the **Default** branch, or Live/Main/any branch you add) is a separate MCP server with its own endpoints, its own tool set, and its own deployment state. You deploy each branch independently — for example, you can keep **Main** in development while **Live** is in production. Use the **Deploy** button in the dashboard header (with the branch selected in the branch switcher), or open [Settings → Branches](/guides/manage-branches.md) and click **Deploy** on the branch you want to take live.

For Bubble apps, a version routes its calls through that version's URL (`/version-<id>/`), so a deployed **Main** server calls `https://<app-id>.bubbleapps.io/version-test/...` while **Live** calls the bare URL.

## Before you deploy

Deploying requires:

1. **At least one tool enabled** — a server with no enabled tools cannot serve useful MCP calls.
2. **OAuth configured** — the client ID and secret must be saved (see [Configure OAuth](/guides/configure-oauth.md)).
3. **No unguarded destructive tools** — every enabled tool with a `destructive` risk level must have **Require confirmation** turned on. If any do not, the deploy button is blocked and lists the offending tools by name.

The fastest way to check all of this at once is to run the [Tests page](/guides/test-your-mcp-server.md) — it reports each deploy-critical check in one place.

## Testing in development

1. Open your app and navigate to the server's **Deploy** page.
2. Copy the **Development URL** snippet for your AI client.
3. Add it to your client config (Claude Desktop, Cursor, ChatGPT).
4. Test your tools — the development URL is available immediately, with no deploy required.

The development URL uses a `-dev` suffix on the server key in the snippet to distinguish it from the production server in your client.

## Deploying to production

1. Open the server's **Deploy** page.
2. Review the status card. If there are blockers, fix them first (or run the [capability tests](/guides/test-your-mcp-server.md)).
3. Click **Deploy to Production**.

You can also deploy the selected branch straight from the **Deploy** button in the dashboard header. After you confirm, a progress checklist steps through **Validating → Testing → Building → Deploying → Live** and finishes with a confirmation toast. If a blocker is hit before the branch goes live, the checklist stops on the failing stage and shows the blocker message with a **Try again** button.

The status changes from `Development` to `Production`. The MCP runtime immediately begins accepting connections from any user at `/mcp/<server-id>`.

The page records the deploy timestamp so you can see when the last deploy happened.

Every deploy also saves an automatic, restorable snapshot of the configuration that went live. See [Version history](/guides/version-history.md) for committing named versions and rolling back to a previous state.

## The production MCP config snippet

Once deployed, the **Production URL** panel appears with tabs for each supported AI client.

### Claude Desktop

```json
{
  "mcpServers": {
    "my-app": {
      "url": "https://runtime.flowcp.io/mcp/<server-id>",
      "type": "http"
    }
  }
}
```

### Cursor

```json
{
  "mcpServers": {
    "my-app": {
      "url": "https://runtime.flowcp.io/mcp/<server-id>",
      "transport": "http"
    }
  }
}
```

### ChatGPT

```json
{
  "servers": [
    {
      "name": "my-app",
      "url": "https://runtime.flowcp.io/mcp/<server-id>",
      "transport": "streamable-http"
    }
  ]
}
```

> **Using a custom domain?** If you've added a verified, active [custom domain](/guides/custom-domain.md) for this app, the snippet automatically targets it instead of the default host.

## Customizing the server URL

By default the production endpoint ends in the server's internal id — `https://runtime.flowcp.io/mcp/<server-id>`. You can replace that last segment with a friendly, memorable slug.

In the **Production URL** panel, find the **Server URL** field and click **Edit**. Enter a slug and click **Save**. For example, `acme-crm` gives you:

```
https://runtime.flowcp.io/mcp/acme-crm
```

Slug rules:

* Lowercase letters, numbers, and single hyphens only (no leading, trailing, or double hyphens).
* 3–50 characters.
* A handful of reserved words (such as `dev`) aren't allowed.
* Slugs are unique across the platform — if one is already taken you'll see **"That URL is already taken"** and can pick another.

The **old URL keeps working** after you set a custom slug, so any AI client already pointed at the `/mcp/<server-id>` URL won't break. Pair a custom slug with a [custom domain](/guides/custom-domain.md) for a fully branded endpoint like `https://mcp.acme.com/mcp/acme-crm`.

## Listing in the public app directories

Deploying makes your server connectable by anyone with the URL. To have it discovered and installed from within an AI client, submit it to that client's public directory:

* [Publish to ChatGPT](/guides/publish-to-chatgpt.md) — submit to the ChatGPT Apps Directory.
* [Publish to Claude](/guides/publish-to-claude.md) — submit to the Claude Connectors Directory.

## Recalling from production

To pull the server back to development without deleting it:

1. Navigate to the server's **Deploy** page.
2. Click **Recall from Production** (visible when the server is in `Production` status).
3. Confirm in the dialog.

The status changes back to `Development`. The MCP runtime stops accepting public connections immediately. All tools, configuration, and OAuth settings are preserved. The development URL continues to work for workspace members.

To re-deploy, click **Deploy to Production** from the same page.

## Tool exposure

The **Tool Exposure** card controls how MCP sessions see this server's tools. Large APIs can generate hundreds of tools, which floods AI clients and wastes context tokens.

* **Auto** (default) — dynamic discovery activates only when the server has more than 40 enabled tools; smaller servers expose every tool up front.
* **All tools** — always expose every enabled tool up front.
* **Dynamic** — always start sessions with only `search_tools`.

Changes apply to new MCP sessions within about a minute and affect both the development and production endpoints.

## Agent Auth (auth.md)

The **Agent Auth** card lets you publish an [auth.md](https://github.com/workos/auth.md) discovery document so AI agents can authenticate on a user's behalf. It is **off by default** and only shown for production servers. See [Agent authentication discovery](/guides/agent-auth-discovery.md) for details.

## Add your server to the connectors library

The **Connectors library** card lets you submit your server to FlowCP's public connectors library, where other workspaces can discover and enable it.

The card is shown only for **production** servers that use **per-user OAuth** or **no auth** — servers that rely on a shared API key or bearer token are not eligible, so their credentials are never exposed in a public catalog.

To submit, fill in:

* **Category** — a short grouping label (e.g. *Productivity*).
* **Description** — what the server lets users do.
* **Docs URL** *(optional)* — a link to your documentation.

Every submission is **reviewed** before it goes live. After you submit, the card shows the current status:

* **Pending review** — submitted and waiting on a FlowCP admin. You can withdraw it at any time.
* **Listed** — approved and visible in the connectors library.
* **Not accepted** — declined; the reviewer's notes explain why, and you can remove the submission and try again after addressing them.

## How the server appears in your AI client

When a client connects, the runtime advertises the server's identity:

* **Name and title** — labelled with your app name and environment.
* **Logo** — your app's logo/favicon.
* **Description** — AI-generated or spec-derived, overridable at any time.
* **Website** — your app's public homepage, shown as the connector link.
* **Instructions** — a map of the server's enabled tools grouped by category.

## Viewing execution logs

Navigate to the server's **Logs** tab. Each entry shows the tool name, end-user connection ID, response status, latency, and any error code. Logs from the development endpoint are tagged `development` so you can filter them separately.

See [Execution logs](/reference/execution-logs.md) for the full field reference.

## Re-deploying after changes

You do not need to re-deploy after changing tools — tool changes are read dynamically at request time. Re-deploy only when you want to update the server's auth mode, description, or other server-level settings.

## Running it on your own infrastructure

On a paid plan you can export a published server and run it yourself with the FlowCP standalone runtime — no FlowCP connection, Postgres, or Redis required. See [Export & self-host your MCP server](/guides/self-host-export.md).