Sometimes an MCP prompt technically works, but the result is not quite what you had in mind.

The agent did something: created a collection, returned a report, updated a style, or built part of a section. But it filled in details you did not specify, missed context you assumed it had, or acted before you had a chance to check the plan.

That gap is what this framework helps close.

Same task, clearer prompt

Here is the same task written two ways.

Vague prompt

Audit my site's SEO.

Clearer prompt

I'm working on [site name, ID #]. Check every page on this site and return a list of pages missing a meta title, meta description, or Open Graph image. Do not make any changes. Return the results in a table so I can review them.

The second prompt works better because it gives the agent more structure:

• Context: which site it should work on
• Action: which SEO fields it should check
• Constraints: that it should not make changes
• Approval path: that it should return the results for review

You do not need every prompt to be long. But for MCP, you do need the prompt to make the work clear before the agent starts acting.

The four-part framework

A strong starting prompt includes at least four things: context, action, constraints, and approval. You do not need to label each part in the prompt. You just need to include them.

Context

Context tells the agent what it is working with.

For example, include:

• The site name and site ID
• The page, collection, component, or section involved
• Existing classes, variables, components, or CMS fields it should reference
• Any design system or content structure it should follow

For a site data task, context might include collection names, field names, or page types. For canvas work, it might include the section you want to update, the variables you want it to use, or the component structure it should preserve.

Action

Action tells the agent what to do now.

For example:

• Create a CMS collection with specific fields
• Check every page for missing metadata
• Update one section to use existing variables
• Inspect a component and summarize how it is structured

One clear action is easier to review than several changes made in a single pass. If the workflow has multiple steps, split it into smaller prompts and check the result before moving on.

Constraints

Constraints tell the agent what not to change.

For example:

• Do not publish any changes.
• Do not modify existing components.
• Use existing color and spacing variables only.
• Return a summary before making changes.

Constraints matter because MCP can act on real site structure. A broad prompt can touch more than you expected, especially when styles, components, variables, or CMS content are involved.

Approval

Approval tells the agent when to pause before acting.

For example:

• Share your plan before making changes.
• List the classes you plan to modify.
• Show the CMS fields you plan to create.
• Wait for approval before applying changes.

This is the checkpoint that catches misunderstandings early. If the agent shares its plan first, you can adjust the direction before the prompt turns into real changes on your site.

The four-part framework is one way to structure an MCP prompt, and a good place to start. Some people go further by giving the agent a specific persona, specifying the format they want results returned in, or getting more technical with class names, field types, and step-by-step sequencing. The Webflow MCP prompt library has examples of what that looks like in practice.

Where Agent Instructions come in

The context part of your prompt does important work. It tells the agent what site it's working on, what design system exists, and what rules to follow. But if you're repeating the same context in every MCP session, that context may belong at the site-level instead.

Agent Instructions are markdown-based rules and guidelines stored directly on your Webflow site. When an agent connects to the site through MCP, the Webflow MCP server provides those instructions automatically before the agent sees a prompt.

You can use Agent Instructions to define things like:

• Class naming conventions and variable structure
• Which components exist and how they should be used
• Brand rules, terminology, and things to avoid
• Session-level constraints, like never publishing changes or always asking for a plan first

Teams can also share Agent Instructions through Shared Libraries when they want the same skills and rules available across multiple sites in a workspace.

Either way, the goal is the same: give the agent consistent context, so you don’t have to repeat the same guidance every time you prompt.

To learn more about Agent Instructions and see examples, visit the Webflow MCP developer docs.

Ready to continue?

Click Complete & continue to see this framework applied to an on-canvas build.