Skip to main content
Glama
Sign In

Linty

by xyz.linty
OverviewDiscussionsAdmin

Get a brand

get_brand
Read-only

Get the facts of one brand by its slug: its company, its categories, each relationship with its availability, and the sources. The result is the JSON twin at /brands/{slug}.json.

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

Input Schema

NameRequiredDescriptionDefault
slugYesA slug: lower-case letters, digits and hyphens, for example `acme-foods`.

Output Schema

NameRequiredDescriptionDefault
slugYes
ownerYes
socialYes
countryYes
sourcesYes
websiteYes
programsYes
categoriesYes
updated_atYes
descriptionYes
publish_stateYes
canonical_nameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / programs / items / properties / evidence
      Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "kind": {
+      "enum": [
+        "direct",
+        "marketplace",
+        "none"
+      ],
+      "type": "string"
+    },
+    "marketplace": {
+      "anyOf": [
+        {
+          "enum": [
+            "faire",
+            "epallet",
+            "rangeme",
+            "abound",
+            "other"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "page_kind": {
+      "anyOf": [
+        {
+          "enum": [
+            "application_form",
+            "inquiry_form",
+            "sign_in",
+            "marketplace_listing",
+            "document",
+            "info_only",
+            "not_wholesale",
+            "dead"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    }
+  },
+  "required": [
+    "kind",
+    "marketplace",
+    "page_kind"
+  ],
+  "type": "object"
+}
    • addedOutput schema / properties / programs / items / properties / last_checked_at
      Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
    • addedOutput schema / properties / programs / items / properties / open_account
      Added value: +{
+  "type": "boolean"
+}
    • changedOutput schema / properties / programs / items / required
      Previous value: -[
-  "relationship_slug",
-  "relationship_name",
-  "availability",
-  "confidence",
-  "last_verified_at",
-  "primary_route_type"
-]New value: +[
+  "relationship_slug",
+  "relationship_name",
+  "availability",
+  "confidence",
+  "last_verified_at",
+  "primary_route_type",
+  "evidence",
+  "open_account",
+  "last_checked_at"
+]
  2. Changed1 schema field changed
    • changedOutput schema / properties / programs / items / properties / primary_route_type / anyOf
      Previous value: -[
-  {
-    "enum": [
-      "web_form",
-      "portal",
-      "email",
-      "phone",
-      "pdf",
-      "rep_contact",
-      "broker",
-      "distributor",
-      "other"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "web_form",
+      "portal",
+      "email",
+      "phone",
+      "pdf",
+      "rep_contact",
+      "broker",
+      "distributor",
+      "other",
+      "marketplace"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
  3. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's main added value is the disclosure that the result mirrors the canonical `/brands/{slug}.json` representation. It says nothing about behavior on a missing slug, auth requirements, or rate limits, so with annotations present this lands at an adequate but unremarkable 3.

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?

One compact sentence carries the scope and the returned content, front-loaded on the verb and resource, followed by a short note on the canonical JSON form. Nothing is padded, though the JSON-twin sentence is of marginal value given the tool already returns JSON.

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?

With an output schema present, the description need not explain return structure, and the schema fully covers the one parameter. What remains thin is failure behavior for unknown slugs and differentiation from find_brands/get_company, but for a single-parameter read tool this is close to complete.

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% and the single slug parameter is fully documented in the schema, including pattern and an example. The description only restates 'by its slug' and adds no format or resolution detail, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description pairs a specific verb (get) with a specific resource (one brand, by slug) and enumerates what the response contains: company, categories, relationships with availability, and sources. It is unambiguous about scope (a single brand), though it never names the sibling find_brands as the multi-result alternative.

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

Usage Guidelines3/5

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

Usage is only implied: the agent must infer that this is the lookup to use when it already has a slug, as opposed to find_brands for searching. No explicit when-to-use or when-not-to-use condition is stated, and no prerequisites (e.g. what to do if the slug is unknown) are given.

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

All Linty 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