ToolsConnector
Webflow
Read and write Webflow CMS items, publish them, read pages and form submissions and manage webhooks from Claude or ChatGPT, through Tulina's MCP server.
Official site: webflow.com
What it can do
2 read/3 write
- 01Read
List a site's CMS collections and their fields
- 02Write
Read, create, update and delete collection items, then publish them
- 03Write
Read a page's metadata and text, and update its title, slug and SEO fields
- 04Read
Read form schemas and form submissions
- 05Write
Manage webhooks, and publish the site
A Webflow site API token already knows which site it belongs to, so this asks for the token and nothing else. The site id is derived from it on first use rather than being a second field somebody has to go and find. Publishing is a separate step from writing: an item can be updated and left staged, which is usually what a workflow should do.
Does Webflow have an MCP server?
Yes. Webflow documents its own MCP server for the Data API. It can create collections and fields, bulk-update CMS items, publish and unpublish items, create pages and update page settings. Each authorization covers one workspace and the agent works within your Webflow permissions and roles. Tulina reaches a site through its own MCP server instead, on the same link that carries the rest of your stack, with a site API token in place of a workspace sign-in.
How do you connect Webflow to Claude and ChatGPT?
Through Tulina's own MCP server, in three steps:
- In Webflow, open Site Settings, then Apps & Integrations, then API access, and generate a token with the cms:read, cms:write and sites:read scopes.
- Paste it into Tulina's Webflow connector, for yourself or for the organisation. It is stored in the vault and never shown to the model.
- Add
https://mcp.tulina.ai/mcpto Claude or ChatGPT and sign in with your Tulina account. The MCP page has the same link.
A site token is bound to exactly one site. To work on several sites, connect one token per site as named accounts and name the one a request is for.
Tulina vs Webflow's official MCP server
Both can work on a site's CMS. They differ in how far each reaches and who holds the credential.
| Webflow's MCP server | Tulina | |
|---|---|---|
| Scope of a sign-in | One workspace per authorization | One site per token |
| CMS items | Bulk updates, publish and unpublish | Create, update and delete up to 50 items per call, then publish up to 50 |
| Collections and fields | Create collections, define fields | Read collections and their field schema |
| Pages | Create pages, bulk-update page settings, schema markup | Read page metadata and text, update title, slug and SEO fields |
| Forms | Not listed on the page | Read form schemas and submissions |
| In the same conversation | Webflow | Webflow plus your CRM, inbox and the other connected tools |
If Webflow is the only system the model needs, or the work is structural, such as new collections or new pages, Webflow's own server is the better choice. Tulina earns its place when a CMS item is one step in a longer piece of work.
What you can ask it
"Draft a blog post in the Posts collection from this call summary." The agent reads the collection's schema to get each field's slug and which are required, validates the content against it, and creates the item staged. Nothing is public yet.
"Show me the three most recently updated items and publish the second one." The agent lists items sorted by last update, then publishes the item you name. A dry run first shows whether it is still a draft and when it was last published.
"Which form submissions came in this week from the pricing page form?" The agent reads the site's forms to find the form, then reads its submissions, which is the lead data visitors typed in.
Webflow pairs with HubSpot when a submission should become a contact, and with Slack for the notification.
What the Webflow connector can't do
- It cannot create collections, define fields or create pages. Those take Webflow's Designer or its own MCP server.
- A page's body copy is read-only. On a single-language site Webflow's API offers no way to edit it, only the page's metadata.
- A change to a page's title, slug or SEO fields goes live immediately, with no draft step. Ask for a dry run first.
- CMS items are staged until they are published, and publishing the whole site is a separate action from publishing items.
- A site token sees one site. Another site needs its own token.
- Form definitions are read-only, and the forms themselves are built in Webflow.
Why through Tulina
The connection was never the hard part.
Most systems now publish their own way for a model to reach them, and that is good: it is what Tulina connects to. The hard part is deciding who may use it, what it is allowed to return, and what the model knows before it asks.
The keys stay in one place
YouTeamOrganisation
Connect Webflow once. The credential is encrypted in a vault, never held in clear, and never pasted into a chat or a workflow file. A person uses their own key where they have one, their team's where they do not, the organisation's after that, so nobody is blocked and nobody holds more access than they need. Revoke it once and everything running on it stops.
What leaves is filtered before it leaves
fields droppedmasked or hashedpseudonymised
Roles decide who can reach Webflow at all. Beyond that, a policy on the connector itself decides what comes back. The data is minimised at the source rather than after it has already reached a model.
Every call is on the record
whatwhowhen
Runs are logged for the organisation. That is what makes an automated action reviewable after the fact, and it is what a security review asks for first.
The run starts knowing your company
namingkey accountsdecisions
A direct connection gives a model access. It does not tell it how your company names things, which accounts matter, or what was decided last quarter. Tulina carries that across every tool, so the same request against Webflow returns something usable instead of something generic.
Processes that run on Webflow
None published yet.