Skip to main content
Glama

Update the brand's words

update_brand
Destructive

Rewrites one of the owner's own words about the business that every plan, post and page reads, as the owner's save on Brand does: what it is, who it's for or how it talks. The whole field is replaced, so read it first with get_brand. Returns the field and the words saved. A fact that is wrong goes in owner_fact_set instead; the look and design rules are business_context_change.

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": {
      "field": "<field>",
      "text": "<text>"
    },
    "name": "update_brand"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesThe field's new words, whole; never empty.
fieldYesdescription: what the business is; audience: who it's for; voice: how it talks.
projectNoThe project's id or exact name. Optional when the account has one project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, so the bar is lower, but the description earns credit by explaining why: 'The whole field is replaced' tells the agent this is a full overwrite rather than a patch. It also discloses the return payload ('the field and the words saved'), which matters since there is no output schema.

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

Conciseness3/5

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

Length is reasonable and the critical warning (whole-field replacement + read first) is front-loaded, but the first sentence is a run-on with an odd simile ('as the owner's save on Brand does') that must be re-read. The rest is tight.

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 a 3-parameter mutation with no output schema, the description covers the prerequisite read, the destructive semantics, where adjacent intents belong, and what is returned. What remains unstated is whether the write requires any particular project selection beyond the optional `project` param, but that is small.

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 100%, so the baseline is 3, and the description adds genuine meaning on top: 'the whole field is replaced' constrains how the agent must construct the `text` argument (full content, not a delta). The enum meanings are already in the schema and are only restated, so this is not a 5.

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?

Uses a specific verb ('rewrites') and a specific resource ('one of the owner's own words about the business'), and enumerates the three fields as 'what it is, who it's for or how it talks'. The opening clause 'as the owner's save on Brand does' is idiosyncratic and slows parsing, but the substance separates it cleanly from get_brand and owner_fact_set.

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?

Explicitly prescribes the prerequisite ('read it first with get_brand') and routes two sibling alternatives with their own conditions: wrong facts go to owner_fact_set, look/design rules go to business_context_change. An agent has no inference left to do about which tool to pick.

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.