Skip to main content
Glama

Get a brand

get_brand
Read-onlyIdempotent

Returns the full details of one brand this account owns or that is shared with its organization: name, industry, website, colors, tone of voice, target audience, product details, offer and writing rules. Read-only. list_brands finds the brand id. update_brand changes the name, industry, website, primary color, tone of voice and target audience; the other details are edited in the StealAds web app.

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": "get_brand"
  }
}

Input Schema

NameRequiredDescriptionDefault
brand_idYesBrand id from list_brands.
response_formatNoOutput format: text (default) or json. table is not available for this tool.

Output Schema

NameRequiredDescriptionDefault
brandNoAccessible brand details.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / brand_id / description
      Previous value: -"Brand reference from list_brands (e.g. the returned brand id)."New value: +"Brand id from list_brands."
    • changedInput schema / properties / response_format / description
      Previous value: -"Output format: text or json for capped research examples; table is available only for tracked rival rows."New value: +"Output format: text (default) or json. table is not available for this tool."
  2. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so "Read-only" is largely redundant. The description does add access-scope context that annotations cannot express — visibility of org-shared brands — and clarifies the write boundary by naming which fields update_brand covers versus the web app. It says nothing about behavior when the brand is missing or access is denied.

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?

Front-loaded with what the tool returns and its ownership scope, followed by the alternatives. The long field enumeration is purposeful but heavy, and "Read-only" duplicates the annotation rather than earning its place.

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?

An output schema exists, so return values need no explanation; what remains — access scope, read-only nature, and routing to list_brands/update_brand/web app — is all covered. Minor gap: no mention of failure modes for nonexistent or inaccessible brand ids.

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 both brand_id and response_format are already fully documented in the schema, including the note that table is unavailable. The description only echoes the list_brands sourcing hint that the schema already contains, adding no new parameter meaning; baseline 3 applies.

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?

States a specific verb and resource ("Returns the full details of one brand"), scopes it by ownership ("this account owns or that is shared with its organization"), and enumerates the returned fields. An agent can distinguish it from list_brands (id lookup) and update_brand (writes a subset) 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?

Explicitly routes the agent: list_brands to find the brand id, get_brand to read, update_brand for a named subset of fields, and the StealAds web app for the remaining edits. This is exactly the when-to-use / when-not-to-use / alternative framing.

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.