Skip to main content
Glama

Change the saved brand

update_brand
Destructive

Create or update the saved brand kit, with ops or from a public site's url. Never applies branding to an existing site or publishes it. ops: business facts, the business and design overviews, colors, fonts, personas, logo marks, and which Drive files count as brand context; brand ops apply in order in one transaction, file ops run after it. url: Replo reads the site into the brand on its servers by mode: replace (default, whole brand) · swap (only parts, in full) · fill (keep what's set, fill gaps); a figma.com file link instead adds the file to the brand's Figma designs. Statuses: applied (saved at the returned version) · partial (brand saved, a file op refused; see files) · invalid (what was refused; nothing was written) · running (an import started and returns at once with importId: poll get_branding until it is completed or failed, under extraction for a site or figmaDesigns for a Figma file) · failed (the import could not start; see message) · action_required (the person must act first, such as connecting Figma; see connectUrl and message). A null value deletes that item, and a replace overwrites what was there. An import returns at once with an importId; follow it with get_branding instead of calling this again. A project gets 50 calls with a url a day, whether or not they start an import; ops don't count. Does not start an agent session.

Input Schema

NameRequiredDescriptionDefault
opsNoOps in order; fill only the fields your op uses. setColor value: { key, name, hex: "#rrggbb", category: "brand" | "neutral", roles: string[], usage: string | null, position: integer }. setFont value: { key, family, roles: string[], delivery: "google-fonts" | "cdn" | "uploaded" | "system" | "unknown", license: string | null, usage: string | null, position: integer, faces: [{ weight: 1-1000, style: "normal" | "italic", assetId: uuid | null, sourceUrl: string | null }] }. setBusiness patch: any of name, about, audience, pricePoint, businessModel, foundedYear, location, voice, sourceUrl. setOverview: kind "business" | "design" and markdown. setMarks: logoAssetId, faviconAssetId or logomarkAssetId; upload the image with upload_asset first and pass the asset id it returns. setPersona value: copy a persona from get_branding and change what you need; a persona nickname is a segment label, never a person's name. A refused op comes back with `expected`, the exact shape to resend. Pass ops or url, not both.
urlNoImport the brand from this public site instead of ops (add https:// if missing). Replo reads it on its servers into facts, palette, fonts, marks, brief, design notes and screenshots, and writes them by `mode`. Never restyles a site. A figma.com file link instead adds that file to the brand's designs (figmaDesigns: its frames, styles and photos); it takes no mode or parts, and needs Figma connected in Replo.
modeNoWith url: how the site lands on the brand. replace (default): the whole brand becomes the site's ("make my brand from this site"). swap: each part in `parts` becomes the site's in full, nothing else changes, the brand keeps its name ("use their fonts", "take their logo and colors"). fill: everything already set stays and the site fills only the gaps, blending field by field ("fill in the rest from this site"). Pick swap for another company's site, so its story never mixes into this brand.replace
partsNoWith url: the parts swap and fill take from the site, each written as the ops of its kind: facts → setBusiness and setOverview, colors → setColor, fonts → setFont, logo → setMarks; images adds the site's photos to brand imagery. Required for swap; on fill, omitted means all of them; refused with replace.
projectIdYesThe project whose saved brand to change.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

The description richly discloses behavior beyond annotations: transactional ordering of ops, what null values do, overwrite semantics, import statuses (applied/partial/invalid/running/failed/action_required), rate limits (50 url calls/day), and that imports return immediately with an importId to poll. These details are critical for a destructive, open-world, non-idempotent tool and are not redundant with the annotations.

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?

The description is front-loaded and every section serves a purpose, but it is quite dense and contains some repetition (e.g., the import/importId polling is mentioned both in the statuses and in a later sentence). For a tool with five complex parameters and multiple modes, the length is mostly justified, though it could be tightened.

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?

Given the tool's complexity (nested ops array, multiple modes, no output schema) and the fact that annotations already cover safety, the description provides a complete picture: it explains what the tool does, how to invoke it, what happens on success or failure, rate limits, and post-import behavior. No critical gaps remain for an agent to use 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?

Although schema coverage is 100%, the description adds substantial meaning: it explains the purpose of each op type, the order of operations, the semantic difference between replace/swap/fill modes, what each `parts` value maps to, and guidance like 'pick swap for another company's site.' This goes well beyond the schema's field-level descriptions.

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?

The description clearly states the tool creates or updates a saved brand kit using either `ops` or a public site's `url`, and explicitly distinguishes it from applying branding to a site or publishing. It also clarifies it does not start an agent session, giving a precise scope that differentiates it from siblings like apply_brand_kit_to_site and publish_site.

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?

The description provides strong when-to-use guidance: pass `ops` or `url` but not both, use `swap` for another company's site, and follow an import with get_branding instead of calling again. It also states exclusions (never applies branding to an existing site, doesn't start an agent session) and rate limits. However, it does not explicitly name sibling tools to use for the excluded actions, so it falls short of full alternative routing.

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