Skip to main content

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.

Roll back when a published component, content type, or content entry has a problem you want to undo. Metabind keeps every published version available, so restoring an earlier one is fast and lossless. Packages themselves are immutable — there is no “package rollback”; instead, rolling back individual resources and then publishing produces a new corrected package.

​
When to roll back vs. fix forward

Most fixes should be fix-forward: edit in MCP App Studio, publish a new version. History stays linear and the published state always reflects current intent. Roll back when:
  • A bug is causing user-facing failures and you can’t fix it within minutes.
  • The new version has a security issue that needs to be off production now.
  • A change had a subtle effect you didn’t catch in testing and you need to think before publishing again.
The decision is mostly about urgency. If the fix is 10 minutes away, fix forward. If you need to stop the bleeding first, roll back.

​
What rollback acts on

ResourceRollback supportedEndpoint
ComponentyesPOST .../components/:id/rollback/:version
Type (content type)yesPOST .../types/:id/rollback/:version
Content entryyesPOST .../content/:id/rollback/:version
Packageno — packages are immutablen/a
Rolling back a component restores its definition; rolling back a Type restores its schema; rolling back a content entry restores its values. To restore the platform-wide state, roll back the affected resources and publish a new package; the new package captures the corrected resources.

​
How rollback creates a new version

Resource versions in Metabind are monotonically incrementing integers — 1, 2, 3, … — not semantic versions. Each publish of a component, Type, or content entry mints the next integer. Rollback is forward-only. Rolling back resource X from version 3 to version 2 does not delete 3 — it mints a new 4 whose content matches 2:
Screenshot placeholder — see note below for the diagram this should illustrate.
Diagram needed: A horizontal version timeline showing 1 → 2 → 3 → 4, with 4 labelled “rollback to 2 (content of 2, new integer version)”. The diagram should make clear that 3 is preserved and 4 was minted from 2’s content. Place the rendered diagram at /images/publishing/rollback-version-timeline.svg and replace the placeholder above.
This means:
  • History stays monotonic. Every version that was ever published remains in the audit trail.
  • The “rolled back” tag is metadata. The new version’s content is byte-equivalent to the target version, but it carries its own integer version number and timestamp.
  • Re-rolling back is fine. Mistakes are recoverable — roll back the rollback, get a new version with the original content.
Note: per-resource versions (the integers) are distinct from the project package version, which uses semantic versioning (1.4.0, 2.0.0). See Package versioning for the package-level model.

​
How to roll back in MCP App Studio

  1. Open the resource’s edit page (a component, a Type, or a content entry).
  2. Click History to see all published versions for that resource.
  3. Pick the version you want to restore.
  4. Click Rollback to this version.
  5. Confirm.
A new published version is created with the target version’s content. Connected hosts pick it up on their next list-tools call (for Types and components) or their next read (for content entries).
Screenshot needed: A resource’s History view in MCP App Studio with several version rows visible and a “Rollback to this version” button highlighted on one row. Place the captured image at /images/publishing/rollback-history.png and replace this note.

​
Rolling back via API

Each resource has its own rollback endpoint. Authenticate with a JWT scoped to publish. 
# Roll back a component to version 5
curl -X POST \
  "https://api.metabind.ai/app/v1/organizations/{org}/projects/{project}/components/{componentId}/rollback/5" \
  -H "Authorization: Bearer ${MB_JWT}"

# Roll back a Type to version 3
curl -X POST \
  "https://api.metabind.ai/app/v1/organizations/{org}/projects/{project}/types/{typeId}/rollback/3" \
  -H "Authorization: Bearer ${MB_JWT}"

# Roll back a content entry to version 7
curl -X POST \
  "https://api.metabind.ai/app/v1/organizations/{org}/projects/{project}/content/{contentId}/rollback/7" \
  -H "Authorization: Bearer ${MB_JWT}"
The response is the new published version (with a freshly-incremented version number). For full reference, see the REST API rollback endpoints.

​
After rolling back

After rolling back the affected resource, publish a new package so production picks up the change:
  1. Roll back the resource that introduced the issue (per the steps above) — this mints the next integer version of that resource.
  2. Publish the project to mint a new package version (semver) that captures the corrected resource.
  3. Optionally bump the package’s MAJOR or MINOR if the rollback restores breaking-change-era behavior.
Connected MCP hosts re-list tools on their next call and observe the new package version.

​
What rollback doesn’t reset

Rolling back a resource does not roll back:
  • Secrets. If you rotated a key after the original version was published, the new key stays in place — the rolled-back handler will use it.
  • Allowed domains. Editable in real time; current settings apply.
  • Tool descriptions and annotations. Editable independently of resource versions.
  • Project Instructions. Editable independently.
If you need to restore those too, edit them by hand in MCP App Studio. The publish history records what they were at the time of each publish.

​
Cache implications

After a rollback + republish, hosts pick up the corrected schemas on their next list-tools call (typically within seconds). For details, see Publish the MCP server: cache behavior. If a host has cached the bad version’s schemas and is mid-conversation, it may continue using the bad version until it reconnects. To make the cutover faster, bump the package version when you republish the rollback — most hosts re-list tools when they see a newer version, picking up the corrected schemas on their next call.

​
Permissions

Rolling back requires the same role as publishing — Editor or higher. Viewers can see history but can’t trigger a rollback.

​
Audit trail

Every rollback is logged. The audit log records:
  • Who triggered the rollback
  • When
  • Which resource and which version was restored
  • The new version number that was minted

Publish the MCP server

The forward-direction equivalent of rolling back.

Package versioning

Why packages are immutable and how versions are minted.

Audit logs

Per-publish and per-rollback audit records.

Team management

Roles and who can roll back.