Skip to main content
Glama

Read a brand from a site

extract_brand
Read-only

Extract a website's colors, fonts, logo, corner style, and name from a URL into a proposed design and voice for user confirmation; generate the logo asset if needed.

Instructions

Free. A site's colours, fonts, logo, corners and name as a proposed design and voice; the user confirms. logo_url: create_asset it for design.logo_asset_id.

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": {
      "url": "<url>"
    },
    "name": "extract_brand"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.45.0

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description does add genuinely new context — it costs nothing, output is a *proposal* pending user confirmation, and a logo_url can be promoted via create_asset into design.logo_asset_id — but the final clause is a telegraphic fragment that is closer to pseudocode than prose and could be misread.

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?

Extremely compact with no filler: cost first, then output, then confirmation, then the logo follow-up. However this is under-specification rather than elegant brevity — the last fragment compresses an entire tool-chaining instruction into seven words at the cost of readability.

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

Completeness3/5

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

For a one-parameter, read-only tool with no output schema, the description does cover roughly what comes back and that it is a proposal needing confirmation. What is missing is how confirmation happens and what the returned object looks like before the user acts, which matters because the whole point is a review step.

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 0%, so the single 'url' parameter is documented nowhere structurally. The description implies it is a site address via 'A site's colours...', but adds no format guidance (scheme required? trailing path allowed? the 2048 max length is unexplained), leaving real ambiguity for the only input.

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 description lists concrete extractable outputs (colours, fonts, logo, corners, name) so the resource is identifiable, but there is no explicit verb — the agent infers extraction from the noun phrase and the title rather than the description text. It also gives no signal distinguishing it from siblings like brand_kit or analyze_reference, which could plausibly do overlapping work.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Free.' and 'the user confirms' convey cost and a confirmation step, but there is no when-to-use guidance, no prerequisites (does the site need to be reachable/public?), and no comparison to any sibling tool. The agent is left to guess whether extract_brand or brand_kit is the right entry point.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.