within

Compare items side by side

compare_pieces

Read-onlyIdempotent

Compare two to four independent luxury boutique items side by side to see price gaps, available sizes, condition, and shop details—useful for cheaper-or-size questions and X vs Y checks.

Instructions

Two to four items from independent luxury boutiques, side by side. For each: its name and designer, price and currency, condition, sizes in stock, the shop and its city, pickup and delivery, a line from its description, its shopwithin.co page, and any other boutique that has the same item, with its price. Then what differs: the price gap, which sizes each has, the condition and the shop. Use this when someone asks which of two items is cheaper or has their size, wants an 'X vs Y' on items they found (Samba vs Gazelle, Jordan 1 vs Dunk), or pastes two shopwithin.co links. Each item is named by its link, or by the boutique_domain and id from a search result. Prices are never converted.

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": {
      "pieces": "<pieces>"
    },
    "name": "compare_pieces"
  }
}

Input Schema

Name	Required	Description	Default
`pieces`	Yes	Two to four items, each as a url, or as boutique_domain and id.

Output Schema

Name	Required	Description	Default
`note`	Yes
`pieces`	Yes
`not_found`	Yes
`differences`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare this as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavior beyond that: it lists the compared fields, explains the differences output, and states that prices are never converted.

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?

The description is front-loaded with the core operation, then moves through output fields, differences, use cases, and input naming. It is somewhat long but the detail is mostly relevant to this comparison tool.

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?

For a complex comparison tool with an output schema, the description covers purpose, use cases, input naming, output fields, and the price-conversion rule. The main gap is the inconsistency between the stated two-to-four item limit and the schema's maxItems of 8, with no handling of invalid counts.

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%, so the schema already documents url, id, and boutique_domain. The description adds the intended two-to-four item range and naming patterns, but that conflicts with the schema's maxItems of 8 and there is no minItems, so it does not earn above baseline.

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?

The description states a specific comparison operation: two to four boutique items side by side, with detailed attributes and a differences section. It clearly distinguishes this from search or single-item lookup by describing the comparison output and X-vs-Y use cases.

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?

It gives explicit triggers such as asking which item is cheaper, whether an item has the user's size, wanting an 'X vs Y', or pasting two shopwithin.co links. It does not state when not to use it or explicitly route to alternatives like search_pieces or get_piece.

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