Skip to main content
Glama

brands

by by.authorized
OverviewDiscussionsAdmin

List a retailer's authorized brands

get_retailer_brands
Read-onlyIdempotent

List all brands a retailer (shop) is currently authorized to sell, according to authorized.by. Read-only. Use this to answer 'which brands has shop X been authorized for?'. Sorted by brand name. Each entry includes official_shop, partnership_date, and certificate_url / certificate_url_de: links to the public authorized.by certificate page (English / German) proving this specific brand-retailer authorization. Share the certificate link when a user needs verifiable proof. Only active partnerships are returned: confirmed by both the brand and the retailer, with both profiles public and the brand approved by authorized.by. Revoked or pending partnerships are never listed. Responses are cached and refreshed when the underlying profile or partnership changes, so a revocation may take a short time to disappear. partnership_date is the date the authorization STARTED, not the date it was last verified; a partnership listed here is currently active as of the response time. 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
id_or_aliasYesRetailer numeric ID, slug or alias.

Output Schema

NameRequiredDescriptionDefault
totalYesNumber of entries in the list.
brandsYes
retailer_idYesNumeric ID of the retailer the list belongs to.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / id_or_alias / description
      Previous value: -"Retailer numeric ID or alias."New value: +"Retailer numeric ID, slug or alias."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "description": "All brands that currently authorize the retailer, with per-brand certificate links.",
+  "properties": {
+    "brands": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "certificate_url": {
+            "description": "Public authorized.by certificate page (English) that proves the authorization; null when there is no active authorization.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "certificate_url_de": {
+            "description": "Same certificate page in German; null when there is no active authorization.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "id": {
+            "description": "Numeric authorized.by ID. Accepted by the id_or_alias argument of the detail tools.",
+            "type": "integer"
+          },
+          "logo": {
+            "description": "Logo image URL, or null.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "description": "Display name.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "official_shop": {
+            "description": "Whether this shop is the brand's own official shop.",
+            "type": "boolean"
+          },
+          "partnership_date": {
+            "description": "Date (YYYY-MM-DD) the authorization STARTED. Not a last-verified date: every listed partnership is active as of the response.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "slug": {
+            "description": "URL-safe identifier. Accepted by the id_or_alias argument of the detail tools.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "website_url": {
+            "description": "Brand website URL, or null.",
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "slug",
+          "website_url",
+          "logo",
+          "official_shop",
+          "certificate_url",
+          "certificate_url_de",
+          "partnership_date"
+        ],
+        "type": "object"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "retailer_id": {
+      "description": "Numeric ID of the retailer the list belongs to.",
+      "type": "integer"
+    },
+    "total": {
+      "description": "Number of entries in the list.",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "retailer_id",
+    "total",
+    "brands"
+  ],
+  "type": "object"
+}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses that only active, mutually confirmed partnerships appear, that revocations may lag due to caching, the exact meaning of partnership_date, the per-entry certificate links, and a three-way mapping of empty list vs. 'not found' error vs. technical failure. That is precisely the behavioral context annotations cannot convey.

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 purpose, use case, and output shape before the caveats, and every paragraph carries real information. It is on the long side, with mild redundancy ('Read-only' restates readOnlyHint) and a somewhat padded caching explanation.

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?

For a complex, trust-sensitive lookup with an output schema present, the description supplies everything an agent needs: scope limitations, active-only filtering, field meanings, certificate sharing guidance, and failure-mode disambiguation. Nothing material is missing.

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% and the schema already documents that id_or_alias accepts a numeric ID, slug, or alias, so the description earns only marginal credit. It does add value by explaining what an unrecognized id/alias produces ('Retailer not found'), which tells the agent how invalid parameter values surface.

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 with scope: 'List all brands a retailer (shop) is currently authorized to sell, according to authorized.by.' The directionality (retailer → brands) implicitly distinguishes it from the inverse sibling get_brand_retailers, and the quoted example question makes the intended query unambiguous.

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?

Gives a clear use case ('answer which brands has shop X been authorized for') and an explicit exclusion: empty results or not-found errors do not prove absence of authorization. However, it never names the concrete alternatives available among siblings (e.g., get_brand_retailers, verify_retailer_authorization), so routing between tools is left to inference.

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

All brands toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources