Skip to main content
Glama
Sign In
Brandfetch MCP Server

Brandfetch MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get brand data

get_brand
Read-onlyIdempotent

Retrieve current brand data from a domain, email, URL, ticker, ISIN, crypto symbol, or Brand ID to inspect logos, colors, fonts, and assets.

Instructions

Current Brand API V2 data through generic or explicit routes. One request; credentialed asset src URLs are redacted from output. Provider reads may spend quota or crawl on a miss.

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": {
      "identifier": "<identifier>"
    },
    "name": "get_brand"
  }
}

Input Schema

NameRequiredDescriptionDefault
accountNoExact private profile label. Never inherits another profile or global key/client ID.
allowNsfwNoOptional provider NSFW behavior; absence differs from false.
cachedOnlyNoTrue avoids crawling a cache miss; 204 is reported as cachedMiss. Indexed reads still consume quota.
identifierYesDomain, email, URL, Brand ID, ticker, ISIN or crypto symbol. Explicit types accept only their identifier format.
identifier_typeNoExplicit provider route avoids identifier collisions.auto

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. Beyond that, the description adds genuinely non-obvious behavior: credentialed asset src URLs are redacted from output, and provider reads may spend quota or crawl on a miss. It does not describe pagination or return shape, but the added context is substantial.

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?

Three dense clauses with no filler; the request-count and redaction facts are stated up front. It is efficiently sized, though the opening clause is the vaguest part and could be more concrete.

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?

With no output schema, the description carries the burden of conveying what comes back, and it only says 'Brand API V2 data' plus a redaction note. Quota and routing behavior are covered, but an agent still cannot anticipate the returned brand fields, which is a real gap for a data-fetch tool.

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 coverage is 100% and each parameter already carries a detailed description (identifier formats, cachedOnly/204 semantics, account inheritance, allowNsfw absence-vs-false). The description only alludes to 'generic or explicit routes,' adding minimal meaning beyond the schema, so the baseline 3 applies.

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 states it fetches 'Current Brand API V2 data' and mentions generic vs explicit routes, so the verb and resource are implied. However, 'data' is generic and it never distinguishes itself from siblings like get_brand_context, get_brand_colors, or get_brand_fonts, so an agent cannot tell which brand-facing tool returns what.

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?

There is no explicit when-to-use guidance and no routing to alternatives such as get_brand_context or search_brands. The only contextual hints ('One request', 'may spend quota or crawl on a miss') describe cost behavior rather than when this tool should be chosen over its many siblings.

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

Deploy Server

Other Tools