Skip to main content
Glama

Update Brand Tool

update-brand-tool
DestructiveIdempotent

Overwrites the given fields; previous values are not kept. Update a brand's display name, aliases, domains, or ignored state. Every field is optional, so send only the fields to change; the aliases and domains lists replace the current ones in full. A brand's kind is derived from context rather than written: pass ignored: true to stop tracking a brand (it is detached from every segment as the mark is set), ignored: false to return an ignored brand to the discovered pool, attach it to a segment to make it a competitor, or designate it through the update-project tool's brand_id to make it the own brand. The own brand cannot be ignored.

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": {
      "brand_id": "<brand_id>"
    },
    "name": "update-brand-tool"
  }
}

Input Schema

NameRequiredDescriptionDefault
aliasesNoThe names Pineprompt matches against when it attributes a mention to the brand. Aliases are stored as sent and compared while ignoring casing and punctuation. On update the list replaces the current one; on create it defaults to the display name.
domainsNoThe domains Pineprompt matches against when it attributes a citation to the brand. Full URLs are accepted and reduced to bare lowercase hosts. On update the list replaces the current one.
ignoredNoPass true to ignore the brand, detaching it from every segment, or false to return an ignored brand to the discovered pool. The own brand cannot be ignored.
brand_idYesThe numeric id of the brand to update.
display_nameNoThe name the brand is shown under (2 to 255 characters). Display names are unique per project, case-insensitive, and may not collide with an alias of another brand.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the destructiveHint/idempotentHint annotations, the description specifies exactly what is destroyed (previous values are not kept, alias and domain lists are replaced in full rather than merged) and the cross-resource effect of `ignored: true` (detached from every segment). It stops short of describing the response or what happens on conflicting updates (e.g., display name collision), which the annotations cannot cover.

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?

Destructive behavior is front-loaded in the first clause, then the mutable fields, then the field-optionality rule, then the kind-derivation model — a logical order. It is dense but nearly every sentence carries decision-relevant information, with only mild redundancy between 'previous values are not kept' and the list-replacement sentence.

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 destructive, idempotent 5-parameter mutation with no output schema, the description covers overwrite semantics, optionality, replace-in-full list behavior, the ignore/detach side effect, and a hard constraint on the own brand. The remaining gap is return/error behavior, which is somewhat lessened by the annotations signaling a mutation rather than a read.

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

Parameters3/5

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

Schema description coverage is 100%, so each parameter is already documented, including replace-not-merge behavior for aliases and domains. The description adds little new parameter-level meaning, mostly restating the overwrite semantics and the `ignored` side effects already present in the schema; the genuinely additive part (kind derivation) is not a parameter at all.

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 first sentence states the operation and its overwrite semantics ('Overwrites the given fields; previous values are not kept'), and the second names the exact mutable surface: display name, aliases, domains, ignored state. It also explains what the tool is not: brand 'kind' is derived from context rather than written, which separates this update from segment/project operations in the sibling 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?

Gives concrete when-to-use rules per field state: `ignored: true` to stop tracking (with the segment-detachment side effect), `ignored: false` to return a brand to the discovered pool, attaching to a segment to make a competitor, and the update-project tool's `brand_id` to designate the own brand. It also states an explicit exclusion (the own brand cannot be ignored) and that all fields are optional so only changed fields need sending.

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