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)
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 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).

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.

4. Managed auth fully configured — a branch using Enterprise managed auth must have both an identity provider assigned (so callers can be verified) and a shared credential for the upstream call. Managed branches also cannot publish tools that require an OAuth scope; use access rules instead.

The fastest way to check all of this at once is to run the Tests page — 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).

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 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

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

Cursor

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

ChatGPT

{
  "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 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 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 — submit to the ChatGPT Apps Directory.

• Publish to Claude — 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 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 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 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.