Skip to main content
Glama
Sign In

Clueso

by io.clueso
OverviewDiscussionsAdmin

Manage brand kit

manage_brand_kit
Destructive

Create and change the workspace's brand kits (editors and admins). The same operations as the brand kit page, so a kit made here looks the same there.

Actions:

  • "create": a kit from url (reads the site's logos, colors, fonts and icons; company details are researched in the background and land in about a minute), or blank with clearly marked placeholders. name is optional.

  • "preview_fill": what url would give kit kit_id, and which of its sections are still placeholders. Changes nothing.

  • "fill": apply it. replace lists sections that take the site's version (company, logos, colors (or palette), fonts, icons, reference_images, guidelines); empty means the placeholder sections, so the user's own uploads and edits stay. add (logos, reference_images) keeps the kit's items and adds the site's. The reply's applied names the sections that changed.

  • "update": changes, only what is given changes: name, palette {background,text,accent,accent2, notes {role: {name,usage}} (a color's name and how to use it)}, fonts {display,heading,subheading,paragraph,mono} (a family per type-scale role), icons {library,style}, company {one_liner,audience,problem,key_features}, overview, tone_of_voice, guidelines {recommendations,restrictions}, add_logo {url,kind,for_background}, remove_logo_id, primary_logo_id, captions (a caption style object, as a clip's subtitle_settings.subtitlesStyle or get_design_guide brand.captions gives it), voices {language: {code, engine} | null} (a default kit's voices are the workspace's default voices).

  • "set_default": make kit_id the workspace default.

  • "research": redo the company research from the kit's site.

  • "dark_logo": make a version of the kit's light-background logo logo_id for dark backgrounds and use it. mode "white" is the mark in white (instant); "recolor" is an AI redraw that keeps its colors (about 30 seconds, budgeted per workspace). A logo that can't be made white says why: try recolor, or ask the user for a file.

  • "delete": delete kit kit_id; projects that used it move to the workspace default kit. The last kit can be deleted too: the workspace then has no brand kit, and its projects and new ones are made without one. Ask the user first (saying so for the last kit), and pass confirmed: true only after they agree.

Kit ids come from find(type='brand_kits'). get_design_guide({brand_kit_id}) reads a kit in full.

Input Schema

NameRequiredDescriptionDefault
addNofill: logos and/or reference_images to add beside the kit's own.
urlNoWebsite, e.g. 'cursor.com' (create, preview_fill, fill).
modeNodark_logo: how to make it.
nameNoKit name (create).
actionYes
kit_idNoThe kit; every action but create.
changesNoupdate: the fields to change.
logo_idNodark_logo: the kit's light-background logo to make it from.
replaceNofill: sections that take the site's version; 'palette' is the same as 'colors'.
confirmedNodelete: true only after the user agreed to delete this kit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds non-obvious behavior the annotations cannot: background company research landing "in about a minute", recolor being an "AI redraw ... (about 30 seconds, budgeted per workspace)", the failure path for un-whitenable logos, and exactly what delete does to projects and to the last remaining kit.

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 purpose followed by a clean per-action bullet list; each bullet is scoped by action name, which is the right structure for an eight-action tool. The `update` bullet is a very dense run-on of nested field names that is hard to parse in one pass, but the information is load-bearing rather than filler.

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 10-parameter, nested-object, no-output-schema tool, the description covers the destructive path and its confirmation requirement, permissions, async timing for the two AI operations, the shape of the returned `applied` field, and where kit ids come from. Nothing an agent needs to invoke it safely is missing.

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

Parameters4/5

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

Schema coverage is 90%, so most parameters are already documented; the description's real contribution is disambiguating `replace` ("empty means the placeholder sections, so the user's own uploads and edits stay") and `add` ("keeps the kit's items and adds the site's"), which the schema does not. It also expands the opaque `changes` object's nested shape, which the schema leaves as additionalProperties: {}.

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 and resource ("Create and change the workspace's brand kits") and enumerates all eight actions so the agent knows the full surface. It also scopes the audience ("editors and admins") and explicitly defers reads to siblings (`find(type='brand_kits')`, `get_design_guide`), separating it from those tools.

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

Usage Guidelines5/5

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

Every action carries its own when-to-use context, including the preview-then-apply pairing ("preview_fill: what `url` would give ... Changes nothing" vs "fill: apply it"). It gives explicit preconditions for the risky path: "Ask the user first (saying so for the last kit), and pass `confirmed: true` only after they agree."

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

All Clueso toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources