Strapi AI Content-Type Builder: Generate Schemas Fast

Strapi is an open-source, headless Content Management System (CMS). Strapi AI adds a chat assistant to the Content-Type Builder that turns a plain-language description into Collection Types, fields, and relations inside the Admin Panel. This guide covers what the assistant can do, the Growth plan and Strapi 5.30 prerequisites, how to prompt and refine, and where hand-editing schema.json still fits better.

Hand-building Content-Types in Strapi means clicking through the field picker a few dozen times, naming each attribute, toggling required and unique, and then circling back to wire relations once both sides exist; Strapi AI now puts a schema chat directly in the Content-Type Builder so most of that clicking goes away.

You describe a natural language CMS schema ("a blog with posts, authors, and categories") and the assistant builds the types in the builder UI, where you review them and click Save like any other change.

The builder was already the fastest way to define a model without opening a JSON file. What the chat adds is the ability to describe a whole data model at once, including cardinality between types, and to ask questions about schemas you didn't write. This guide walks through where the chat lives, what it's documented to do, the plan and version gates, prompting and iteration, and the cases where you should still reach for code.

In brief:

Strapi AI in the Content-Type Builder designs structures, explains existing schemas, and plans data models using your current Content-Types as context.
It requires a Growth plan on Strapi 5.30 or later, works on Strapi Cloud and self-hosted, and consumes AI credits from a shared monthly pool.
Generated types land in the standard builder UI as unsaved changes; you review, adjust, and Save, and Strapi writes the usual schema.json files and restarts.
Production deployments, lifecycle hooks, and plugin extensions still go through files in version control.

The rest of the guide shows how to generate, review, and ship these schema changes safely.

Built-in Strapi AI Chat vs. External Tools

Strapi AI's Content-Type Builder assistant runs inside the Admin Panel and edits your model through the builder itself. The Content-Type Builder docs describe it plainly: "When enabled, Strapi AI adds an assistant that helps you create or edit content types with natural language." It reads your existing Content-Types as context, so a request to "add a relation to authors" resolves against the author type you already have rather than a guess.

That separates it from the other AI workflow you've probably tried: pointing Cursor or Claude Code at a Strapi repo and asking for a schema.json. Strapi supports that path too.

The Docs MCP server gives IDEs "Strapi-aware code suggestions and answers," the official strapi/skills repository ships SKILL.md instruction files for coding agents, and the AGENTS.md files in the strapi/strapi and strapi/documentation repositories guide agents working on Strapi code. Those tools write files; they don't see your live schema unless you feed it to them, and they leave validation to you and the server restart.

A third surface adds to the confusion. Strapi 5.47.0 and later include a free, built-in Strapi MCP server that lets Claude Desktop, Claude Code, Cursor, or any MCP-compatible client create, read, update, delete, publish, and unpublish content entries through the Content Manager.

It operates on entries, using tools generated from your schema and gated by Admin token permissions. If you've seen Strapi's Claude Code guide that generates Content-Types and refactors schemas from prompts, note that it relies on the external community package @sensinum/strapi-plugin-mcp and is scoped to development and local use.

The rest of this article covers the in-panel chat.

What the Content-Type Builder AI Can Do

The feature list at docs.strapi.io/cms/ai/for-content-managers describes the assistant as an "AI chat assistant that helps design content-type structures, explain existing schemas, and plan data models. Uses your existing content types as context." Those three verbs (design, explain, plan) are the full documented scope.

Four ways to feed it input are documented in the Content-Type Builder docs:

Natural language chat: describe what you need.
Import code from an existing Strapi or front-end application.
Import a Figma project to infer a content model from the UI design.
Attach an image to extract content structure from a design.

The second option matters more than it looks. If you have a Next.js front end with TypeScript interfaces for your content, you can hand those over instead of translating them into field-by-field prose.

On output, the Strapi AI announcement lists Collection Types, Single Types, and Components as generatable. The docs' own example prompt (covered below) produces two Collection Types with a one-to-many relation between them, and the Content-Type Builder page mentions "recommendations for which components to use in a dynamic zone." One caveat from the docs applies to AI and manual creation alike. The builder documentation states: "Not all fields are always available depending on the content-type or component being created or edited."

The docs don't enumerate which specific field types (enumerations, booleans, JSON, dates) the chat can emit, so treat the builder's own supported list as the ceiling: Text, Rich Text (Blocks), Number, Date, Password, Media, Relation, Boolean, JSON, Email, Enumeration, UID, Rich Text (Markdown), Components, Dynamic Zones, and Custom fields. If you can add it in the builder by hand, you can reasonably ask for it.

Two sibling features share the same credit pool and are worth knowing about while you're here: Internationalization auto-translates content from the default locale to all configured locales on save, and the Media Library generates alternative text, captions, and descriptions for uploaded images. No AI drafting feature for entries in the Content Manager is documented.

Prerequisites: Plan and Version

You need a Growth plan and Strapi 5.30 or later. The Strapi AI documentation states that "Strapi AI is available for Growth plan users since Strapi 5.30" and that "AI features are not available on earlier versions." It works on both Strapi Cloud and self-hosted deployments.

Two plan details catch people. Community plan users don't get it, and the plan documentation says "Strapi AI is not available on Enterprise plans" either; the pricing page lists Enterprise as "COMING SOON" for AI. If your team assumes Enterprise is a superset of Growth, this is the exception.

Credits work like this, per the credits documentation and pricing page:

Growth includes a monthly credit allowance, and the Growth trial includes a smaller one; the pricing page has the current figures.
The AI documentation explains: "Lightweight actions use fewer credits, while more complex ones use more." No per-action breakdown is published, so you won't know in advance what a five-type schema costs.
The credit guidance states: "Credits are shared across all users within the same project instance." A content editor generating alt text draws from the same pool as your schema prompts.
Usage shows in the Settings Overview of the Admin Panel, with notifications at 80%, 90%, and 100% of the monthly allowance.
After that, the overage documentation says "you can keep using Strapi AI, with overages billed monthly"; the current overage rate is on the pricing page.

The trial allowance won't get you through a large model, so plan the trial around one or two representative prompts rather than your whole data model.

AI is on by default once a Growth license is active. To switch every AI feature off, set the flag in config/admin.js (or .ts):

// config/admin.js
module.exports = {
  ai: {
    enabled: false,
  },
};

One environmental constraint follows from the builder itself: the builder documentation says the Content-Type Builder is available in the Development environment only, so the chat is too. On data handling, the AI documentation says: "All AI requests are processed through Strapi-managed infrastructure.

Content is only used temporarily during each request and is not stored outside your instance. Strapi AI follows the same GDPR-aligned framework as Strapi Cloud." The documentation doesn't name the underlying model provider.

Opening the AI Assistant in the Content-Type Builder

Start your project in development mode so the builder is active:

npm run develop

The Content-Type Builder docs state that the builder is "accessible via the main navigation of the admin panel." Once you're in it, the docs give a one-line instruction for the assistant. The assistant instructions say to "click on the button in the bottom right corner of the admin panel, and describe what you need." You don't create a Content-Type first; the chat opens on the builder's landing view.

The non-text inputs sit at the bottom of the chat window. That button handles importing code from an existing Strapi or front-end application, importing a Figma project, or attaching an image.

Strapi's content modeling guide shows the image path: open the builder, click the Strapi AI icon, attach content model diagram images, and submit "Generate the content types for a company website using the attached images." If you already whiteboarded the model with a stakeholder, a photo of that board is a legitimate starting prompt.

Describing Your Schema in Natural Language

The single piece of prompting guidance in the docs is worth taking literally. The prompting guidance says: "The more precise your prompts, the more accurate your created schemas are likely to be." The example the docs pair with it shows what precise means:

"Could you please generate a collection of dogs then also generate an owner collection and add relationship to dogs? An owner can have multiple dogs, but a dog can only have one owner."

Notice what's in there. Both Collection Types are named. The relation is requested explicitly. Cardinality is stated from both directions, which removes the ambiguity that would otherwise leave you with a many-to-many you didn't ask for. What's absent is any field list, so the assistant decides what a dog record contains.

The general availability post offers looser prompts: "I need a blog with posts, authors, and categories." and "Create a content structure for an e-commerce store." These work as first drafts when you want the assistant to propose a shape you'll then trim. For a project where you already know the fields, spend the extra thirty seconds and spell them out, using the builder's field-type names so nothing gets lost in translation:

Create a collection type called Article with:
- title: Text, required
- slug: UID attached to title
- excerpt: Text (long)
- body: Rich Text (Blocks)
- coverImage: Media, single image
- status: Enumeration with values draft, review, published
- publishedOn: Date

Create a collection type called Author with name (Text, required),
bio (Rich Text), and avatar (Media, single image).

Relation: an Author has many Articles; an Article has one Author.

Think of this as writing the schema.json in English. It's still faster than clicking, and the assistant handles the relation plumbing on both sides.

Keep prompts to a handful of types each. At GA, Strapi listed "enhanced reliability for complex requests" as a coming-soon item, and the current docs don't confirm whether that landed. Smaller prompts also cost fewer credits per attempt when something comes back wrong.

Refining Fields and Relations

The builder documentation says the assistant helps you "create or edit content types with natural language," so refinement is in scope. What the docs don't provide is a step-by-step account of how follow-up prompts modify an already-generated type. Conversation history "to build on previous interactions" was another coming-soon item at GA, and the current documentation neither marks it as pending nor confirms it shipped.

The practical workaround is to write each refinement as a self-contained request that names the type and the field, rather than relying on "it" or "the one above":

On the Article collection type, change excerpt from Text to Rich Text (Markdown)
and make coverImage required.

Add a Category collection type with name (Text, required) and slug (UID).
An Article can have many Categories and a Category can have many Articles.

Because the assistant uses your existing Content-Types as context, referencing Article works even after you've closed and reopened the chat.

Mixing modes is fine. If the assistant gets a field type wrong, fixing it by hand in the builder is often quicker than another prompt, and both paths produce the same unsaved change set.

Using AI to Explain an Existing Schema

Inherited Strapi projects tend to arrive with 30 Content-Types, a shared components folder nobody remembers creating, and no diagram. The assistant's documented ability to "explain existing schemas, and plan data models" using your Content-Types as context is aimed at exactly that situation, according to the feature documentation.

There's no separate "explain" mode in the docs; you open the same chat and ask. Questions that fit the documented scope:

"Explain how page, section, and the layout dynamic zone relate to each other."
"Which content types reference author, and in which direction?"
"I want to add a newsletter single type that links to article. Does anything in the current model already cover this?"

The third example is the "plan data models" case. You're asking the assistant to check a proposed addition against what exists before it generates anything, which is cheaper in credits and in cleanup than generating first and discovering duplication after.

For a schema that lives in a different repository, the import-code input brings it into the conversation: import the Content-Type files from the existing Strapi app, then ask for a walkthrough.

Two things the docs leave open. They don't specify which sub-elements (components, relations, field-level attributes) are transmitted as context beyond "existing content types," and they don't describe the format of an explanation.

On privacy, the usage information page adds that temporary metadata and content snippets exist only for the duration of each request, and that Strapi never stores unpublished content or credentials outside your instance. Explanation requests still draw credits from the shared pool.

Reviewing Before You Apply

The assistant doesn't hand you a dedicated preview or approval screen. Generated types show up in the regular builder view carrying the same status indicators any unsaved edit gets: New (N) for types not yet saved, Modified (M) for changes since the last save, and Deleted (D) for deletions not yet confirmed. Nothing touches disk until you click Save.

That gap is where you do the actual review. Open each new type and check:

Field types, especially Text vs. Rich Text, and whether Rich Text came back as Blocks or Markdown when you had a preference.
Required and unique flags on the fields you specified.
Relation direction and cardinality. Confirm which side owns the relation and that "one owner per dog" didn't become many-to-many.
Dynamic Zones, if any were generated. The builder documentation enforces this constraint: "Different components in a dynamic zone cannot have the same field name with different types or enumeration values."
Naming. Rename now; renaming a saved type later means a migration for any data already in the table.

If a generation went sideways, the ... menu next to Save offers Undo/Redo last change and Discard all changes. The undo documentation notes these are "centralised, meaning that they apply to the last action(s) that was/were done on all content-types, components and fields since the last time you saved." Undo therefore walks back the assistant's edits and your manual ones in the same stack.

When the structure looks right, click Save and, as the quick-start guide says, "wait for Strapi to restart." The restart isn't optional: Strapi's FAQ explains that model configuration lives in files such as ./src/api/restaurant/content-types/restaurant/schema.json. The Strapi FAQ explains: "Due to how Node.js works, in order for changes to take effect, that would require Node to restart the server."

After the restart, each generated type exists at:

./src/api/[api-name]/content-types/[content-type-name]/schema.json

The models documentation describes these files as generated automatically whichever way you created the type, with four top-level areas: settings (kind, collectionName), info, attributes, and options. Relations appear as type: 'relation' with a relation key such as manyToOne and a target, using inversedBy on the owning side and mappedBy on the inverse. For the dogs example, the relation attribute on the dog type would look roughly like this:

// src/api/dog/content-types/dog/schema.json
{
  "attributes": {
    "owner": {
      "type": "relation",
      "relation": "manyToOne",
      "target": "api::owner.owner",
      "inversedBy": "dogs"
    }
  }
}

Run git diff on src/api after the restart. That diff is the most reliable second review you'll get, since it shows every attribute the assistant added, including defaults you didn't ask about. The Strapi FAQ recommends tracking these files in source control, and on a TypeScript project you can regenerate typings right away:

npm run strapi ts:generate-types --debug

Or set autogenerate: true in config/typescript.js so every restart, including the one Save triggers, refreshes the types folder.

When to Reach for Code Instead

The chat covers schema shape in development. Several things sit outside that boundary, and pretending otherwise leads to the "works on my machine" version of content modeling.

Shipping to production. The strapi start command runs without restarts and file writes and disables the Content-Type Builder outright; the CLI documentation is blunt that "strapi develop should never be used in production." Content-Type changes reach production through committed schema.json files and a deploy. Generate locally, commit the diff, and let CI carry it.

Lifecycle hooks. The assistant produces schema.json. The lifecycles.js file next to it "must be created manually," with events like beforeCreate, afterUpdate, and beforeFindMany. Any behavior attached to a type is still yours to write. Bulk lifecycles (createMany, updateMany, deleteMany) are never triggered by Document Service API methods, which trips up teams porting hooks from older projects.

Extending plugin Content-Types. Overriding a plugin's model means creating a file at ./src/extensions/plugin-name/content-types/content-type-name/schema.json. That's a path the builder chat doesn't reach.

Components without the Admin Panel. The models documentation says Components can't be created with CLI tools; they come from the builder or from manually written files under ./src/components in category subfolders. If the Admin Panel isn't available in your workflow, manual files are the only route.

Custom fields. Custom fields can't be relation, media, component, or Dynamic Zone types, a constraint you'll hit in code regardless of how the surrounding schema was drafted.

Plan, version, or environment mismatches. A Community plan project, a Strapi instance below 5.30, or a team that needs Enterprise all fall outside the chat. External coding assistants have no plan gate, no credit meter, and no Strapi version floor. The trade is that their handling of your content is governed by the model provider's policies rather than Strapi's, and they can't see your live types unless you wire up context yourself. Strapi's Docs MCP server and the .md variants of every docs page (append .md to the URL) narrow that gap for code correctness, though not for schema awareness.

If you go the external route and also use the built-in MCP server for content, read Strapi's token-scoping guidance first. As that post puts it, an MCP server "hands an AI agent real write access to your content: the ability to create, update, delete, and publish entries without a human clicking anything."

Natural Language In, Standard Schema Out

Strapi AI's Content-Type Builder chat takes a description like "an owner can have multiple dogs, but a dog can only have one owner" and produces the Collection Types and relation in the Admin Panel, with your existing types as context and nothing written to disk until you approve it. The gates are firm: Growth plan, Strapi 5.30 or later, development mode, and a shared credit pool. The output is the same schema.json you'd have written by hand, which means git, TypeScript generation, lifecycle hooks, and your deploy pipeline carry on unchanged.

The best first test is a model you were about to build anyway. Start a project on the current Strapi 5 release, open the builder, click the button in the bottom-right corner, and describe two or three related types with their fields and cardinality. Then read the diff before you commit it.

Strapi AI Content-Type Builder: Generate Schemas from Natural Language Prompts