Skip to main content
Glama

Set the brand note

set_brand_note
DestructiveIdempotent

Replace the user's brand note (at most 2000 characters): who they are, what they sell, their tone, colours and words to avoid. Call it only when the user states facts about their brand or asks you to remember them, and send the whole note, since it replaces the old one. Settings shows the user that you changed it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "about": "<about>"
    },
    "name": "set_brand_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
aboutYes

Output Schema

NameRequiredDescriptionDefault
goalsYes
localeYes
materialYes
subjectsYes
first_nameYes
about_brandYes
about_subjectYes
ai_experienceYes
clip_priorityYes
usual_formatsYes
image_priorityYes
in_their_wordsYes
about_brand_updatedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / clip_priority
      Added value: +{
      +  "anyOf": [
      +    {
      +      "$ref": "#/properties/image_priority/anyOf/0"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / image_priority
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "best",
      +        "balanced",
      +        "cheapest"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "first_name",
      -  "locale",
      -  "goals",
      -  "in_their_words",
      -  "about_subject",
      -  "ai_experience",
      -  "material",
      -  "about_brand",
      -  "about_brand_updated",
      -  "subjects",
      -  "usual_formats"
      -]New value: +[
      +  "first_name",
      +  "locale",
      +  "image_priority",
      +  "clip_priority",
      +  "goals",
      +  "in_their_words",
      +  "about_subject",
      +  "ai_experience",
      +  "material",
      +  "about_brand",
      +  "about_brand_updated",
      +  "subjects",
      +  "usual_formats"
      +]
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false. The description adds real value beyond them: it discloses that the operation full-replaces rather than appends, requires the entire note each time, and that the change is surfaced to the user in Settings, making the side effect visible.

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

Conciseness5/5

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

Two sentences, front-loaded with the replace semantics and the size cap, then the invocation condition and the replacement caveat. No filler, and each clause carries a distinct constraint.

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?

An output schema exists so return values need no explanation; the description covers what is written, the size limit, the destructive replace behavior, the trigger condition, and the user-visible notification. Nothing material is missing for a one-parameter mutation.

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 0%, so the description carries the load: it defines what belongs in the note (who they are, what they sell, tone, colours, words to avoid) and that the whole note must be sent because it replaces the old one. This meaningfully supplements the bare 'about' string definition, though it does not specify formatting or how to merge with an existing note.

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

Purpose4/5

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

States a specific verb and resource ('Replace the user's brand note') and enumerates the content it holds (identity, products, tone, colours, forbidden words). It never distinguishes itself from the adjacent sibling set_preferences, so there is mild ambiguity about where brand facts belong.

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?

'Call it only when the user states facts about their brand or asks you to remember them' gives a clear triggering condition with an exclusivity constraint. It does not name an alternative tool for the adjacent cases (e.g. general preferences), so the routing is contextual rather than explicit.

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