Skip to main content
Glama

Update the brand kit

update_brand_kit

Records what the workspace sounds like. Pass only the fields you are changing; anything you leave out is kept. Example posts matter most: ask for two or three things they actually published, since those define the voice better than adjectives do. Use this whenever the user tells you something about their voice, audience or rules, rather than remembering it for one conversation.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_brand_kit"
  }
}

Input Schema

NameRequiredDescriptionDefault
ctasNoCalls to action they use.
nameNoThe brand or business name.
voiceNoAdjectives for the voice, e.g. "warm", "practical".
toneDoNoThings to do, e.g. "name the plant".
websiteNo
audienceNoWho the posts are for, e.g. "office managers".
keywordsNoWhat this project is about, in the words people would search for.
oneLinerNoWhat they do, in one sentence.
toneDontNoThings to avoid, e.g. "use stock phrases".
bannedWordsNoWords never to use.
descriptionNoA paragraph of background.
hashtagSetsNoNamed sets of hashtags, e.g. {"core": ["#plants", "#office"]}.
examplePostsNoPosts they wrote themselves. These define the voice; add rather than invent.
languagePrimaryNoTwo-letter code for the language posts are usually written in.
defaultImagePromptNoA template wrapped around every image prompt, where {{DESCRIPTION}} is replaced by what the picture should show. This is how a project keeps one look. Pass an empty string to clear it.
defaultVideoPromptNoThe same, for video, where {{DESCRIPTION}} is what the clip should show. Left empty, videos use the image template, since a project usually has one look. Pass an empty string to clear it.
contentInstructionsNoStanding rules for everything written for this project, e.g. "always end with a question". These are applied to every draft, so put a rule here rather than repeating it each time. Pass an empty string to clear them.
replaceExamplePostsNoReplace the stored examples instead of adding to them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already flag a non-readonly, non-destructive, non-idempotent write. The description adds real behavioral context beyond them: partial-update merge semantics (omitted fields are kept) and the fact that example posts accumulate rather than overwrite. It does not discuss permissions or what happens to downstream drafts when rules change.

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?

Four sentences, each carrying distinct guidance (merge semantics, example-post priority, trigger condition), with no filler. The first sentence is the weakest because it is figurative and front-loads mood over the actual operation.

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

Completeness4/5

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

For an 18-parameter, zero-required, nested-object mutation with no output schema, the description covers the two riskiest behaviors (partial merge and additive examples) and the trigger condition. The remaining parameter detail is adequately carried by the 94%-covered schema, though it never points to get_brand_kit for reading current values.

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 94%, so the baseline is 3; the description earns a bump by prioritizing examplePosts over adjectives in `voice` and by explaining that stored examples are additive unless explicitly replaced. Most other parameters (defaultImagePrompt, hashtagSets, contentInstructions) are left entirely to the schema.

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

Purpose3/5

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

The opening line, "Records what the workspace sounds like," is metaphorical rather than a specific verb+resource statement; it never says plainly that this updates the stored brand kit. The partial-update clause ("Pass only the fields you are changing; anything you leave out is kept") does clarify the operation, and the sibling get_brand_kit is not referenced to draw the read/write boundary.

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?

"Use this whenever the user tells you something about their voice, audience or rules, rather than remembering it for one conversation" is a clear trigger condition with an implied alternative (ephemeral memory). It also gives a collection tactic (ask for two or three published posts). No explicit exclusions or named sibling alternatives such as learn_voice_from_published.

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