Skip to main content
Glama

wp_set_brand_kit

Destructive

Author/replace the Global Brand Kit and apply the FULL Elementor Theme Style (the active kit) — not just colors: it also writes h1–h6 + body + link + button + form-field + image + layout controls, so the WHOLE site renders on-brand (~130+ kit controls from a compact token set). CHANGES EVERY PAGE — pass confirm=true to apply, or dry_run=true to preview the computed Elementor settings without writing. Plugin transport + Xyle Connector v0.4.0+ required. brand_kit shape: {colors:{primary,secondary,accent,text,bg,border, ...extra named colors}, typography:{heading:{family,weight}, body:{family,weight}, scale:{h1:{size,sizeTablet,sizeMobile,weight,lineHeight,letterSpacing,wordSpacing,unit}, ... , body, small}, links:{color,hover}}, UNITS: size in px; lineHeight unitless-em (1.1); letterSpacing |v|<0.25 reads as em, larger as px (force with letterSpacingUnit:'px'|'em'); wordSpacing always px. buttons:{radius, padding:{y,x}, bg, text, hover, typography:{size,weight,letterSpacing}}, forms:{labelColor,fieldText,fieldBg,border,focus,radius}, images:{radius,opacity}, layout:{containerWidth,contentWidth,widgetSpacing}}. Most fields are OPTIONAL — headings/body/links/buttons/forms are DERIVED from the core palette when omitted, so even a colors+scale kit themes the whole site. COLORS: primary/secondary/accent/text map to Elementor's 4 SYSTEM colors; bg/border AND ANY OTHER named color you add (e.g. primary_hover, primary_active, success, warning, error, info, surface_sunken) each become an Elementor CUSTOM global color shown in Site Settings → Global Colors. Pass the user's FULL palette — extra brand tokens ARE applied, not dropped. On an ESTABLISHED site that already has a customized kit, the API returns error='existing_kit_conflict' with the current colors/fonts — that's the double-ask: show the user, and only then re-call with override_existing_kit=true. New/empty sites apply on confirm alone.

Input Schema

NameRequiredDescriptionDefault
scopeNo'full' (default: Global Colors/Fonts + derived Theme Style controls for h1–h6, body, links, buttons, forms) or 'tokens' (ONLY Global Colors/Fonts/type scale — the narrow blast radius for a palette fix on a live site)
confirmNoMust be true to apply — guards a site-wide change
dry_runNoReturn the computed Elementor kit settings without writing
site_idYesWordPress site id
brand_kitYesBrand kit token object. colors: the 6 named slots PLUS any extra named colors (they become custom global colors). typography + buttons.
override_existing_kitNoSecond confirmation to overwrite an EXISTING customized kit (established sites only). Only set after showing the user the current kit from the existing_kit_conflict response.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Far exceeds the annotations (destructiveHint/openWorldHint). It discloses that the change affects EVERY PAGE, that the plugin transport and Xyle Connector v0.4.0+ are required, the 'existing_kit_conflict' error and the double-ask recovery with override_existing_kit, and that derived controls are computed when core fields are omitted. This is exactly the extra context annotations can't carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the critical 'CHANGES EVERY PAGE' warning and confirm/dry_run flow, and most sentences earn their place for such a complex tool. However it collapses into one dense paragraph wall, making the unit rules and error handling harder to scan than a lightly structured version would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-param, nested, destructive, open-world tool with no output schema, the description is complete: it covers the write guard, preview mode, prerequisites, error/recovery path, token shape, and unit conventions. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Coverage is nominally 100%, but the brand_kit nested object exposes no properties in the schema, so the description carries the full burden — enumerating colors/typography/scale/links/buttons/forms/images/layout, naming units (px, unitless-em lineHeight, the |v|<0.25 letterSpacing heuristic, always-px wordSpacing), and clarifying that extra named colors become custom global colors. This adds substantial meaning beyond structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Author/replace the Global Brand Kit and apply the FULL Elementor Theme Style') and immediately scopes what makes it distinct — not just colors, but the whole Theme Style control set. An agent understands the site-wide blast radius without opening the schema. Although it doesn't name the sibling store_brand_kit, the tool's purpose and reach are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational routing: pass confirm=true to apply or dry_run=true to preview, and only set override_existing_kit=true after a double-ask. The scope param documents when to choose 'tokens' (narrow palette fix on a live site) vs 'full'. It stops short of explicitly contrasting with the sibling wp_apply_style / store_brand_kit, so no hard exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources