Publish the MCP server

Documentation Index

Fetch the complete documentation index at: https://docs.metabind.ai/llms.txt

Use this file to discover all available pages before exploring further.

Publishing is the action that promotes your draft work to the production endpoint. Until you publish, no one outside MCP App Studio sees your changes.

​

What publishing does

Clicking Publish in MCP App Studio runs four steps atomically:

1. Snapshot the package. Every component file in your project is bundled into a new package version (e.g., 1.4.0 → 1.5.0). The bundle is immutable — published code never changes after the fact.
2. Pin Types to the package version. Every Type in the project (Interactive Tools and Data Tools) is updated to reference the new package version.
3. Promote to the production endpoint. https://mcp.metabind.ai/<org>/<project> now serves the new package; previously connected hosts pick up the change on their next list-tools call.
4. Record a version entry. A row appears in the project’s publish history with timestamp, author, and the diff between this version and the previous one.

The whole operation is transactional. If any step fails, no production change happens.

​

Where the Publish button lives

Open the project header in MCP App Studio. To the right of the project name, you’ll see the Publish button. It’s only enabled when there are changes to publish.

​

The publish dialog

Before the change actually promotes, MCP App Studio shows a dialog with:

• What’s new. A list of Types added, modified, or removed since the last publish.
• Component changes. Bumps to component files, with file-by-file diffs for review.
• Suggested version. Semantic version bump suggestion based on whether the changes appear additive (1.4.x → 1.5.0) or breaking (1.4.x → 2.0.0). You can override this.
• Notes (optional). A free-text changelog entry that ends up in the version history.

Clicking Confirm runs the publish. There’s a brief moment of “publishing…” and then the dialog confirms.

​

Who can publish

Publish requires a role with the relevant publish permission — Editor for content, Admin or Owner for components, packages, and content types. Viewers can see drafts and previews but can’t promote. See Team management for the full role matrix.

​

What publishing locks

Once a package version is published, the bundle is immutable:

• The component code at version 1.5.0 will always be the code that was in your draft when 1.5.0 was published. Even if you edit the same component the next day, that’s a different version.
• Types pinned to a specific version don’t drift. A host that connected and cached product_card@1.5.0 gets the same schema and behavior on every subsequent call until that Type is repinned.

Drafts continue to be editable. Publishing locks the version; the next set of edits becomes the next version.

​

What publishing doesn’t lock

A few things are not part of the published bundle and continue to be editable post-publish:

• Secrets. Data Tool secrets live outside the package. You can rotate STRIPE_API_KEY without republishing.
• Allowed domains. Editable in real time (this is enforced at request time, not bundle time).
• Tool descriptions and annotations. Editable in real time on the Type’s edit page.
• Project Instructions. The free-text instructions that are shipped to MCP hosts as part of the protocol — editable without republishing.

If you want to lock these too, treat editing them as a mini-publish: announce internally, audit the change, etc.

​

Republishing

If you find a problem after publishing, you have two options:

1. Fix forward. Make the fix in MCP App Studio, publish a new version. This is the typical case.
2. Roll back. Revert to a previous published package version. See Rolling back.

Both are fast. Production endpoint promotion takes a few seconds.

​

Cache behavior on connected hosts

MCP hosts list tools when they connect and cache the schemas. After a publish, hosts pick up the new schemas on:

• Their next list-tools call (typically every conversation start).
• A manual reconnect, if the host supports one.

Hosts don’t get a push notification — they discover the new version by listing. For most hosts this happens within seconds; for long-running connections, the user may see the previous version until the host reconnects. If you need clients to pick up a change without waiting for their next list-tools poll, bump the package version on publish — connected hosts treat a new version as a fresh listing and re-fetch schemas on the next call.

​

Publish history

Every publish appears in the project’s history. The history shows:

• Timestamp
• Author (the MCP App Studio user who clicked Publish)
• Version number
• Notes (the free-text entry from the publish dialog)
• Diff (a link to the file-by-file diff between this version and the previous)

Use the history both as a paper trail (compliance asks) and as a debugging surface (a regression appeared two publishes ago — what changed?).

​

Related