Skip to main content
Glama
Sign In

Linty

by xyz.linty
OverviewDiscussionsAdmin

Find brands

find_brands
Read-only

Find food, beverage and pet brands, and see where to apply to each for a wholesale account. Filter by text, category path, country, availability or submittable. The text in q can match the name, other names or description of a brand. Search allows small spelling errors and returns at most the best 1,000 matches. submittable is true when the brand has an active web form at its address, and LintyBot read that page. It is false when a robots.txt file asks Linty not to use the page, or a part of the page where the form can be. Each page has up to 50 brands. To get the next page, send next_cursor as cursor.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_brands"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoText to find in the brand's name, other names or description. Search allows small spelling errors and returns at most the best 1,000 matches.
cursorNoThe `next_cursor` of the earlier page.
countryNoA two-letter country code in capitals, for example `US`.
categoryNoA category path, for example `snacks/protein-bars`.
submittableNoTrue: only brands with an active web form at their address, whose page LintyBot read, and no `robots.txt` refusal of the page or of a part of it where the form can be.
availabilityNo

Output Schema

NameRequiredDescriptionDefault
brandsYes
next_cursorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / q / description
      Previous value: -"Text to find in the brand name or description."New value: +"Text to find in the brand's name, other names or description. Search allows small spelling errors and returns at most the best 1,000 matches."
  2. Changed1 schema field changed
    • changedInput schema / properties / submittable / description
      Previous value: -"True: only brands with an active web form at their address, and no `robots.txt` refusal of the page or of a part of it where the form can be."New value: +"True: only brands with an active web form at their address, whose page LintyBot read, and no `robots.txt` refusal of the page or of a part of it where the form can be."
  3. Changed1 schema field changed
    • changedInput schema / properties / submittable / description
      Previous value: -"True: only brands with an active web form at their address, and no `robots.txt` refusal of the page or a part of it."New value: +"True: only brands with an active web form at their address, and no `robots.txt` refusal of the page or of a part of it where the form can be."
  4. Changed1 schema field changed
    • changedInput schema / properties / submittable / description
      Previous value: -"True: only brands with an active web form at their address."New value: +"True: only brands with an active web form at their address, and no `robots.txt` refusal of the page or a part of it."
  5. Changed1 schema field changed
    • changedOutput schema / properties / brands / items / properties / route_flags / items / enum
      Previous value: -[
-  "bot_wall_observed",
-  "login_required",
-  "no_form_at_url",
-  "captcha_on_submit",
-  "blocked_for_lintybot",
-  "frame_refused"
-]New value: +[
+  "bot_wall_observed",
+  "login_required",
+  "no_form_at_url",
+  "captcha_on_submit",
+  "blocked_for_lintybot",
+  "frame_refused",
+  "robots_refused"
+]
  6. Changed1 schema field changed
    • changedInput schema / properties / submittable / description
      Previous value: -"True: only brands with a web form at their address."New value: +"True: only brands with an active web form at their address."
  7. Changed1 schema field changed
    • changedOutput schema / properties / brands / items / properties / route_flags / items / enum
      Previous value: -[
-  "bot_wall_observed",
-  "login_required",
-  "no_form_at_url",
-  "captcha_on_submit",
-  "blocked_for_lintybot"
-]New value: +[
+  "bot_wall_observed",
+  "login_required",
+  "no_form_at_url",
+  "captcha_on_submit",
+  "blocked_for_lintybot",
+  "frame_refused"
+]
  8. Changed2 schema fields changed
    • changedOutput schema / properties / brands / 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"
+  }
+]
    • changedOutput schema / properties / brands / items / properties / route_flags / items / enum
      Previous value: -[
-  "bot_wall_observed",
-  "login_required",
-  "no_form_at_url"
-]New value: +[
+  "bot_wall_observed",
+  "login_required",
+  "no_form_at_url",
+  "captcha_on_submit",
+  "blocked_for_lintybot"
+]
  9. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With annotations already declaring readOnlyHint=true and destructiveHint=false, the bar is lower, yet the description still adds real behavioral context: fuzzy spelling tolerance, a hard cap of 1,000 matches, a page size of 50, and the exact conditions under which `submittable` is true or false (including robots.txt refusals). It does not discuss cursor stability or ordering, but the disclosed limits are 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?

Front-loaded with purpose, then filters, then matching/pagination behavior — a sensible order. It loses a little to duplication ('Search allows small spelling errors and returns at most the best 1,000 matches' repeats the q schema text) and one tangled sentence about robots.txt and 'a part of the page where the form can be'.

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?

An output schema exists, so return-value documentation is not required, and the description supplies the pagination protocol, result caps and the derived-flag semantics an agent needs to call this correctly. The only real gap is the unexplained `availability` enum values (direct/indirect_only/unavailable/unknown), which matter for filtering.

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 83%, so the schema already documents q, cursor, country, category and submittable. The description largely restates that material (q matching name/other names/description, cursor usage, submittable semantics) with only marginal added meaning, which fits the baseline-3 case when the schema carries the load. The `availability` enum is left entirely unexplained in both places.

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 concrete verb ('Find') plus a specific resource ('food, beverage and pet brands') and adds the outcome ('see where to apply to each for a wholesale account'), which is unusually informative about what the tool is for. The plural, filter-oriented framing clearly separates it from the singular sibling get_brand without needing to name it.

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?

The description tells the agent which filters exist and how text matching behaves, so the intended usage (bulk search/discovery) is implied, but it never states when to prefer this over get_brand or list_categories, nor any when-not condition beyond the implicit 'many brands'. Adequate but no explicit routing guidance.

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