Elementor MCP

Most product-design work starts with a visible interface. Here, the interface was a conversation and the product was the decision architecture behind it. Before placing an element, the MCP needed to understand the request, identify what was missing, choose the right primitives, establish a visual system, build, and check its own work.

That made orchestration feel close to UX architecture. Both turn intent into a navigable path. Both decide what the system can infer, what it should reveal now, where it needs confirmation, and how it recovers when the result is wrong.

Some people arrive with a Figma file, screenshot, HTML page, or live reference and expect fidelity. Others arrive with a rough idea and need help finding a direction. I shaped the design journey around two entry modes rather than forcing both users through the same intake.

Reference mode extracts composition, visual DNA, assets, and interactions from the source. Intent mode asks no more than a few questions at a true fork, such as business type, brand constraints, or visual direction. After that point, both paths use the same system-first build and verification loop.

Engineering provided three surfaces for shaping agent behavior: server instructions, tool descriptions, and focused resources. I mapped the design knowledge across them. The journey belonged in the always-on layer, contextual guidance sat close to the relevant action, and deeper craft knowledge lived in resources for typography, layout, interaction, responsive behavior, icons, and Elementor patterns.

This mirrors progressive disclosure in a product interface: orient first, give contextual help while the user acts, and reveal depth when a specific decision requires it. Product guarantees could not live in an optional prompt that might never run.

Elementor Core engineering built the MCP tools, widget schemas, and infrastructure that let the agent inspect and change Elementor. My role was not to create that capability layer. I focused on the design knowledge that helped the agent use it well: what to inspect before building, which questions mattered, how to choose native patterns, and how to recognize a real control rather than text styled to look interactive.

I translated common website patterns into design guidance grounded in the capabilities engineering exposed. A split hero, pricing section, card grid, navigation bar, or image CTA could be planned with real Elementor blocks, layout primitives, content widgets, links, buttons, images, and forms instead of generic web assumptions.

My contribution centered on the style resources. style/design-taste.md defined a plan-first design process, visual-direction rules, anti-generic defaults, and a polish gate adapted to Elementor. style/best-practices.md covered typography, color, hierarchy, spatial rhythm, and static depth. style/widget-patterns.md mapped common compositions to native widget combinations.

style/responsive.md covered fluid type, wrapping layouts, auto-fitting grids, and mobile-safe spacing. style/icons.md defined an asset-first icon path with explicit fallbacks. style/interactive.md protected semantic navigation, linked cards, real buttons, image CTAs, and labelled forms.

Engineering created abilities/build-composition.md and the list-resources, read-resource, list-widget-schemas, get-widget-schema, and list-dynamic-tags abilities. Those files supplied the build contract, tool discovery, schemas, nesting rules, and infrastructure. My design resources used that foundation to guide the quality of the page the MCP produced.

I started with the decisions a designer refuses to repeat: no default gradient, automatic three-card grid, centered hero by habit, fake icon, or identical rhythm across every section. Positive guidance paired those refusals with distinctive type, purposeful contrast, asymmetric composition, and one strong visual move per page.

I checked every recommendation against the capabilities engineering exposed. Responsive guidance used fluid type and layouts Elementor could represent. The guidance preferred native controls and real assets, with explicit fallbacks when a capability was not available.

Build tests exposed a fragile assumption: telling the model to use a design system did not guarantee that it would. Under friction, it could create variables and classes, then fall back to local styling for the actual page. The screenshot looked complete while the underlying product became harder to maintain.

I documented and reproduced these failures, then brought them to engineering. The team moved critical compliance into the build layer so matching visual decisions could resolve to global variables, repeated styling could become shared classes, and verification could report whether the page used its system. My guidance taught design judgment; engineering made the non-negotiable parts enforceable.

This project changed the unit of design. I could encode design decisions, test the agent against real prompts, inspect the resulting structure, and bring specific failures to engineering. Their work on the tools and infrastructure made those corrections enforceable.

The work still depended on product-design judgment: user intent, progressive disclosure, semantics, hierarchy, constraints, and ownership. Building made that judgment testable. The artifact was no longer only the page. It was the agent's ability to reach a better page and hand it back in a form the user could continue shaping.