Skip to main content
Glama

Verify a retailer's authorization

verify_retailer_authorization
Read-onlyIdempotent

Check whether a shop is an authorized retailer of a brand, from the shop's domain or URL plus the brand or one of its products' GTIN (EAN). Read-only. Use this when you know the seller's domain, e.g. from a shopping or UCP catalog result. Pass exactly one of 'brand' or 'gtin'; a GTIN resolves the product's brand and the check stays brand-level. status: AUTHORIZED = authorization active: the brand has confirmed this shop on authorized.by; official_shop, partnership_date and certificate_url / certificate_url_de prove it, share the certificate link when a user needs proof. NO_RECORD_FOR_BRAND = the shop and the brand are on authorized.by, but this brand has not confirmed this shop there (also when a GTIN belongs to several brands and not exactly one confirmed it; brand is then null). RETAILER_NOT_REGISTERED = no public shop on authorized.by at this domain. BRAND_NOT_REGISTERED = no public brand or product matches 'brand' or 'gtin'. None of these statuses means that the shop is unauthorized. Domains match exactly, never a parent domain or another subdomain (www. and m. count as the same shop); marketplace hosts such as amazon.de or ebay.de only match the exact store URL. The answer is computed live, never cached. Data scope: results only cover relationships registered and confirmed on authorized.by. An empty result or a not-found error does NOT prove that no authorization exists outside authorized.by. Distinguish outcomes: an empty list means no matching record on authorized.by; an error result whose text starts with 'Brand not found' or 'Retailer not found' means the given id/alias is unknown; an error result whose text starts with 'Tool execution failed' is a technical error and says nothing about the data.

Input Schema

NameRequiredDescriptionDefault
gtinNoGTIN / EAN of a product of the brand, 8 to 14 or 18 digits. Omit when passing 'brand'.
brandNoBrand numeric ID, slug, alias or website domain, e.g. 'deuter' or 'deuter.com'. Use get_brands to find the slug from a name. Omit when passing 'gtin'.
retailer_domainYesShop domain or URL, e.g. 'best-shop.de' or 'https://www.best-shop.de/de/grills'.

Output Schema

NameRequiredDescriptionDefault
gtinYesThe checked GTIN, normalized to 14 digits (18 for GTIN-18); null when checked by brand.
brandYesThe checked brand; null when the shop or the brand is not registered, or when a GTIN matches several brands and not exactly one of them confirmed the shop.
statusYesOutcome of the check: AUTHORIZED (authorization active), NO_RECORD_FOR_BRAND, RETAILER_NOT_REGISTERED or BRAND_NOT_REGISTERED. None of them means that the shop is unauthorized.
retailerYesThe authorized.by shop registered at this domain; null when there is none.
checked_atYesTimestamp (ISO 8601) the check was made; answers are never cached.
official_shopYesWhether this shop is the brand's own official shop.
certificate_urlYesPublic authorized.by certificate page (English) that proves the authorization; null when there is no active authorization.
retailer_domainYesThe checked shop domain and path, as parsed from the request.
partnership_dateYesDate (YYYY-MM-DD) the authorization STARTED. Not a last-verified date: every listed partnership is active as of the response.
certificate_url_deYesSame certificate page in German; null when there is no active authorization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / description
      Previous value: -"Outcome of the authorization check, with certificate links when VERIFIED."New value: +"Outcome of the authorization check, with certificate links when AUTHORIZED."
    • changedOutput schema / properties / status / description
      Previous value: -"Outcome of the check: VERIFIED, NO_RECORD_FOR_BRAND, RETAILER_NOT_REGISTERED or BRAND_NOT_REGISTERED. None of them means that the shop is unauthorized."New value: +"Outcome of the check: AUTHORIZED (authorization active), NO_RECORD_FOR_BRAND, RETAILER_NOT_REGISTERED or BRAND_NOT_REGISTERED. None of them means that the shop is unauthorized."
    • changedOutput schema / properties / status / enum
      Previous value: -[
      -  "VERIFIED",
      -  "NO_RECORD_FOR_BRAND",
      -  "RETAILER_NOT_REGISTERED",
      -  "BRAND_NOT_REGISTERED",
      -  null
      -]New value: +[
      +  "AUTHORIZED",
      +  "NO_RECORD_FOR_BRAND",
      +  "RETAILER_NOT_REGISTERED",
      +  "BRAND_NOT_REGISTERED",
      +  null
      +]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only and idempotent, yet the description adds substantive context: the answer is computed live and never cached, domains match exactly (no parent/subdomain, www./m. equivalent), and marketplace hosts only match exact store URLs. It also defines each status code and warns that a not-found does not prove non-authorization, which is exactly the kind of interpretation burden annotations cannot carry.

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 the purpose and the parameter rule, then status semantics, then data-scope caveats. It is long and dense with acronyms, but nearly every sentence carries decision-relevant information; the status glossary is verbose yet necessary for correct interpretation.

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

Completeness5/5

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

Given an output schema exists, return-value explanation is optional, yet the description supplies status meanings, error-text distinction ('Brand not found' vs 'Tool execution failed'), and the scope limitation of authorized.by. An agent has everything needed to call it and interpret edge cases.

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 baseline is 3, but the description adds real semantics: the mutual exclusivity of brand and gtin, and that a GTIN resolves the product's brand while the check stays brand-level. That clarifies behavior the schema fields alone only hint at.

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 ('Check whether a shop is an authorized retailer of a brand') plus the exact inputs (domain/URL + brand or GTIN). It is clearly distinguishable from the sibling read tools like get_brand_retailers or get_retailer, which list entities rather than perform a brand-level authorization check.

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

Usage Guidelines4/5

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

'Use this when you know the seller's domain, e.g. from a shopping or UCP catalog result' gives a concrete selection condition, and 'Pass exactly one of brand or gtin' disambiguates the two modes. It does not explicitly name a sibling alternative or state when not to use it, so it stops short of full when/when-not guidance.

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