Skip to main content
Glama
Sign In

SnapHost

by ai.snaphost
OverviewDiscussionsAdmin

Set brand kit

set_brand_kit
Idempotent

Save the active workspace's brand kit, replacing the one it has: the palette by role, the heading and body fonts, the logo and mark, the language and locale, the tone and the phrases never to use, and the look (style: radius, density, emphasis, cover and surfaces, each from a small set, read off the site the way the colours are). Build it from what the person gives you (a brand guideline PDF, their website, or answers), show it to them as a table and get a yes BEFORE calling this. Colours are #rrggbb for every role: primary, primaryStrong, secondary, accent, ink, muted, line, surface, surfaceTint, onPrimary, onSecondary, positive, negative (positive and negative, the green and red for a change for the better or the worse, may be left out and get sensible defaults). Fonts are one family name each, a system family or a Google Fonts family name (font_source: "google"; publishing then allows Google Fonts on the site). logo_url and mark_url are https URLs of a PNG, SVG or WebP under 1 MB on a public site (the customer's own website is the usual source): SnapHost fetches and hosts them, so the kit's asset URLs are SnapHost's, never the source. A first save needs a logo; a later one keeps the assets it has unless given new ones. Relay every warnings entry (low contrast is the usual one) and offer to fix it. Owner or admin only, on Pro. The brand guidelines themselves (a page or PDF) are set apart, with set_brand_guidelines.

Input Schema

NameRequiredDescriptionDefault
nameYesThe brand name, e.g. "Garðabær"
toneNoUp to eight sentences describing how the brand writes
styleNoThe look, read off the site: radius from its buttons and cards, density from its white space, emphasis from its display type (calm or bold headlines), cover from its hero, surfaces from whether it boxes content in tinted panels or separates it with rules. Leave `style` out on a later save to keep the look the kit has; a first save without it takes the neutral look (soft, regular, calm, dark, tinted).
localeYesLocale for numbers and dates, e.g. "is-IS"
tokensYesA #rrggbb colour for every role: primary, primaryStrong, secondary, accent, ink, muted, line, surface, surfaceTint, onPrimary, onSecondary, positive, negative
languageYesLanguage code, e.g. "is"
logo_svgNoThe logo as SVG markup (the <svg>…</svg> drawn inline in the site’s HTML), when no file URL exists; at most 200 KB
logo_urlNohttps URL of the logo (PNG, SVG or WebP)
mark_svgNoThe mark as SVG markup, when no file URL exists
mark_urlNohttps URL of the small mark or emblem; the logo when omitted
body_fontYesThe body family
font_sourceYesWhere the fonts come from
heading_fontYesThe heading family
workspace_idNoOptional: the workspace to act in, from list_workspaces (the connection reaches the person's personal space and every workspace they are a member of). Required on a write when the connection reaches more than one workspace. Omit to act in the personal space (for an older single-workspace connection, the one workspace it was authorized for).
forbidden_phrasesNoUp to forty words or phrases the brand never uses

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / guidelines_url
      Removed value: -{
-  "description": "https URL of the brand guidelines, a public web page or PDF; \"\" clears it, omitted keeps it. Owner only.",
-  "type": "string"
-}
  2. Changed1 schema field changed
    • addedInput schema / properties / guidelines_url
      Added value: +{
+  "description": "https URL of the brand guidelines, a public web page or PDF; \"\" clears it, omitted keeps it. Owner only.",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / style
      Added value: +{
+  "description": "The look, read off the site: radius from its buttons and cards, density from its white space, emphasis from its display type (calm or bold headlines), cover from its hero, surfaces from whether it boxes content in tinted panels or separates it with rules. Leave `style` out on a later save to keep the look the kit has; a first save without it takes the neutral look (soft, regular, calm, dark, tinted).",
+  "properties": {
+    "cover": {
+      "enum": [
+        "dark",
+        "light",
+        "split"
+      ],
+      "type": "string"
+    },
+    "density": {
+      "enum": [
+        "airy",
+        "regular",
+        "dense"
+      ],
+      "type": "string"
+    },
+    "emphasis": {
+      "enum": [
+        "calm",
+        "bold"
+      ],
+      "type": "string"
+    },
+    "radius": {
+      "enum": [
+        "sharp",
+        "soft",
+        "round"
+      ],
+      "type": "string"
+    },
+    "surfaces": {
+      "enum": [
+        "tinted",
+        "ruled"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safety profile (write, idempotent, non-destructive). The description adds genuinely new behavior: SnapHost fetches and re-hosts logo/mark assets so returned asset URLs are never the source, a first save requires a logo while later saves retain existing assets, warnings (low contrast) must be relayed, and the operation is owner/admin gated on Pro. This is substantive disclosure beyond structured fields.

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 core action and its constraints are front-loaded, and the long run-on list of roles/style keys mirrors the schema rather than adding to it. For a 15-parameter tool the length is defensible, but a few clauses (the full colour enumeration, the style read-off) restate structured data and could be trimmed.

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?

There is no output schema, and the description compensates by telling the agent what comes back (warnings to relay) and what to do with them. Combined with permission requirements, asset-hosting behavior, first-save vs later-save semantics, and defaults, an agent has everything needed to invoke this correctly.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: a 1 MB size ceiling on logo/mark URLs, that positive/negative may be omitted and receive sensible defaults, that font names are system or Google Fonts families, and the neutral default for a missing `style`. It does repeat the colour-role and style-enum semantics already present in the schema, which caps it at 4.

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 opens with a specific verb+resource+scope: 'Save the active workspace's brand kit, replacing the one it has', then enumerates exactly what the kit contains. It explicitly distinguishes itself from the sibling set_brand_guidelines ('the brand guidelines themselves... are set apart'). An agent can separate it from get_brand_kit and set_brand_guidelines without opening any schema.

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?

It gives explicit when-to-use ('Build it from what the person gives you... show it to them as a table and get a yes BEFORE calling this'), names the alternative for the related resource, and states prerequisites ('Owner or admin only, on Pro'). Nothing about selection or preconditions is left to inference.

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

All SnapHost 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