Build a Webflow CMS with MCP

A well-structured CMS doesn’t just organize content. It gives your team, and an AI agent, a reliable system for creating and managing content at scale.

We’ll use Webflow MCP and Claude to plan, build, test, and manage a CMS. MCP gives Claude access to Webflow tools, so it can read and change the site instead of just talking about it.

First, we’ll ask Claude to recommend a structure. Then we’ll review and approve the plan, check the result in Webflow, test everything with real content. And finally, we’ll look at how MCP can help us keep adding and managing content as the site grows.

By the end, we’ll have two collections connected, each with the fields they need to support our site structure and our users.

Let’s start with the plan. Okay, let’s close this tab first, and behind it, we have Claude and to save some time, our prompt is already here. Let’s look into it.

We’re building a new CMS from scratch for a fitness ring site with products like Lumen 1 and Lumen Premium, plus supporting resources like setup guides and troubleshooting documentation. We also told it that one Product may connect to several Resources.

Then, we’re asking it to recommend the Collections, fields, and relationships. We’re including any required fields we already know we need, and we are asking it to suggest anything else that could help with AEO to make the content easier to discover in AI search.

And this is important to us: before it builds anything, we want it to explain its choices, flag any open questions, share a plan, and wait for our approval.

It’s a lot easier to work through these kinds of decisions now than after we’ve added dozens or even hundreds of items to a CMS collection.

Alright. Let’s send it.

And it’s ready.

Moving on to the next step. Review the plan. Claude recommends a Products Collection and a Resources Collection. But the more interesting part is seeing which fields it recommends beyond the ones we already had in mind.

For Resources, we have the fields we’d expect to show on the page: a name, summary, body, and resource type. But Claude also suggested an author, an updated date, and a meta description to help us manage the content and make it more discoverable over time.

Now let’s look at Products. It’s recommending a name, description, and a related resources field, among others.

And because one Product might connect to several guides or articles, Related Resources needs to be a multi-reference field connected to the Resources Collection. That way, when someone edits a Product, they can choose all the Resources that support it.

And a quick note: for our project, we don’t need another field in Resources that tries to do the same thing in reverse. That would give the team two places to manage one connection, and sooner or later, they’d stop matching.

Okay, we have the proposed structure, but Claude still hasn’t changed or created anything. That’s the workflow we want: recommend first, review the plan, then build.

So let’s give it the go-ahead to build.

And we’re back.

It tells us it’s finished, so let’s go to our site and check the result ourselves.

We’ll just refresh, and here we have the Collections. In the Resources Collection we have the core content fields, along with the author, updated date, and meta description fields we approved.

And let’s go over to Products, where we have the core content fields and the Related Resources multi-reference field connected to the Resources Collection, so the relationship is set up the way we planned. Great!

Okay. But in our experience, these things still need a human pass. Are the field names clear? Are the right fields required? Did Claude add anything we don’t actually need? Did it accidentally order that new golf driver I was looking at?

The agent can build the structure, but we still need to understand what it created and why. And if anything looks off, we can ask Claude to update it before we keep going.

Let’s go back to our CMS collections. Our list of fields are quite long. So let’s move over to Claude, and ask it to group them for us. We’ll do Content, Publishing, and SEO. Send it.

Okay, it’s done. Over in Webflow. So much better. And the fields work exactly the same and now they are easier to find.

Okay. We’ve got things where we want them. Now let’s test things out with some made up sample content.

Before we do that, let’s make sure the site is published. Okay. We have an official approved outline for three Lumen Premium Resources: a getting-started guide, a configuration guide, and a troubleshooting article. We’ll give that outline to Claude, ask it to create the Resources as drafts, then create a Lumen Premium Product and connect it to all three. Let’s send it.

Okay, the new items are ready, so over in Webflow, let’s open the Lumen Premium Product item. The fields have the right information, and here we have our three connected Resources inside the multi-reference field.

So what just happened? Claude used the relationship the way we planned. That’s a great sign the structure is working.

Now let’s open one of the Resources. We have the main content, along with the author, updated date, and meta description fields we added for publishing and discovery.

We’ve successfully added a few items, but it’s so much bigger than that. The real opportunity is what this structure allows you to do next.

If we use this setup often, we could create a Collection structure skill so our agent follows the same steps each time.

And with a little more work, we could make a repeatable workflow for adding new content, a lot like the test we just did. We could even create Agent Instructions on the site and include things like approved terminology and which claims it should avoid.

So we don’t just have a CMS that can hold more content. We have a structure we can build on as the team automates more of the work.

That's building and structuring a CMS with MCP, in Webflow: recommend first, review always, build with confidence.

‍