Managing content in MCP App Studio

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.

Content management in MCP App Studio is the day-to-day editor surface — define content types, create entries, organize them in folders and tags, publish to production. This guide covers the workflow.

​

Content types: the schema

A content type defines the shape of an entry. Field types include: Content types are versioned. Editing a content type’s schema produces a draft; publishing the type makes the new schema available to all entries. To create a content type:

1. Open the Content Types tab in MCP App Studio.
2. Click + New content type.
3. Add fields, configure validation, set the inspector UI for editors.
4. Save.

​

Content entries: the data

Once a content type exists, editors create entries:

1. Open the Content tab.
2. Click + New entry.
3. Pick the content type.
4. Fill the fields in the editor; references and assets are picker-driven.
5. Save as draft, or publish.

Entries follow a draft → published lifecycle:

• Draft. Editable. Visible only in MCP App Studio (and to authenticated draft API consumers).
• Published. Read-only at the API surface. Editing creates a new draft on top.
• Unpublished. Removed from the published API but kept as draft.

​

Folders and tags

Both are searchable and filterable. Tags are lighter-weight; folders impose structure.

​

Search

The Content tab includes a search bar. Search is content-type-aware — narrow to a single type, filter by tag or folder, sort by created/updated date. For programmatic search, use the REST search API or GraphQL query.

​

Publishing

Two surfaces publish:

• Per-entry publish. Click Publish on an entry; just that one updates. Most common.
• Bulk publish. Select multiple entries, Actions → Publish.

Publishing an entry makes it visible at the production API. Publishing a content type makes its schema available; existing entries don’t migrate automatically — you’d republish them after the schema change.

​

Migration when content types change

When a content type’s schema changes (e.g., adding a required field), existing entries need to migrate:

• Add an optional field? Existing entries continue to work; the new field is null until edited.
• Add a required field? Existing entries are flagged; you provide a default or migrate per-entry.
• Rename a field? MCP App Studio offers a rename-and-migrate flow that updates entries in place.
• Drop a field? MCP App Studio asks if the data should be archived or deleted.

For bulk migrations, the REST API has /content/migrate and /content/bulk-migrate endpoints.

​

Content versions

Every entry tracks versions. Each save is a new version; publishing pins the published version.

• Version history. View every save with timestamp and author.
• Diff. Compare any two versions side-by-side.
• Roll back. Promote a previous version to current.

Versions are read-only after creation. The audit trail is immutable.

​

Locales

Content can be localized by configuring locales on the project (e.g., en-US, fr-FR, ja-JP). Each entry stores per-locale field values; editors switch locales in the entry editor. API consumers request a specific locale; the entry is returned with that locale’s values, falling back to a default if a locale is missing.

​

Permissions

Project roles control content management:

• Viewer. Can browse content, can’t edit or publish.
• Editor. Can create, edit, publish drafts.
• Owner. Editor permissions plus content type schema edits and bulk operations.

For finer permissions (per-folder access, per-content-type access), use Roles in the REST API.

​

Webhooks

Configure webhooks to receive notifications on content events:

• Entry created
• Entry published
• Entry deleted
• Content type published

Webhooks fire to your URL with a JSON payload of the change. Use them to invalidate caches, trigger downstream builds, or notify systems.

​

Related