within

Similar brands: designers like this one

brands_like

Read-onlyIdempotent

Find brands similar to a given designer, ranked by shared independent luxury boutiques and product kinds, with live stock counts, shared shops, and page links for each.

Instructions

Designers like a given one, counted from live stock at independent luxury boutiques: the brands that the same boutiques stock and whose items are the same kinds (sneakers, jackets, bags, jewellery), most alike first. Each comes with how many items are in stock, the boutiques and kinds it shares with the one asked about, and its shopwithin.co page. The list says what the same boutiques stock today; it is not a judgement of taste, price or look, and not a list of copies. Use this when someone asks for brands like Chrome Hearts, brands like Rick Owens, similar brands, or what else to look at if they like a designer. It only knows designers in stock at the boutiques on shopwithin.co.

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": {
      "designer": "<designer>"
    },
    "name": "brands_like"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	How many to list, default 6.
`designer`	Yes	The designer or brand to start from: 'Rick Owens', 'Chrome Hearts', or its shopwithin.co slug.

Output Schema

Name	Required	Description	Default
`how`	Yes
`note`	Yes
`found`	Yes
`nearest`	Yes
`similar`	Yes
`designer`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent, but the description adds real behavioral context: the results derive from live stock counts, each entry carries item counts, the shared boutiques and kinds, and its page URL, and it explicitly disclaims being a taste, price, or look judgement or a list of copies. It also discloses the coverage limit (only designers stocked at shopwithin.co boutiques), which an agent needs before promising results.

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 definition and ranking logic, then usage triggers, then limits — a sensible order with no filler sentences. It runs long and the 'not a judgement of taste, price or look' clause is slightly redundant with the 'not copies' disclaimer, but each block still serves a purpose.

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?

Despite having an output schema, it briefly characterizes the return payload (counts, shared boutiques/kinds, page link), and it closes the main open question for this kind of tool — data provenance and coverage. An agent has enough to decide when to call it and what to promise about the results.

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%, with 'designer' documented as accepting a name or slug and 'limit' documented with its default and 1–12 maximum. The description only echoes example designer names and does not add format, matching, or fallback behavior (e.g. what happens on an unknown designer). Baseline 3 is appropriate when the schema already carries the load.

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: brands that the same boutiques stock and whose items are the same kinds, ordered most-alike first. It also names the ranking signal (co-stocking plus shared kinds) and the domain (independent luxury boutiques), which separates it cleanly from piece-level siblings like similar_pieces and wear_with.

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 concrete trigger phrasings — 'brands like Chrome Hearts', 'brands like Rick Owens', 'similar brands', or 'what else to look at if they like a designer' — so intent matching is straightforward. It also states a hard boundary: it only knows designers in stock at boutiques on shopwithin.co. It stops short of naming a sibling alternative for piece-level similarity, so not a 5.

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