within

Price check: what it costs right now

price_check

Read-onlyIdempotent

Check current prices and stock for designer items at independent luxury boutiques, compare lowest, highest, and pre-owned costs, and find where to buy within budget.

Instructions

What a designer's item costs right now at independent luxury boutiques: how many are in stock, the lowest, middle and highest price, the used, second hand or pre-owned ones against the rest, the cheapest few with the shop and the shopwithin.co page for each, and shopwithin.co's own price page for the designer. Prices stay in each boutique's own currency and are never converted. Use this when someone asks how much something is, wants a price check or to compare prices, names a budget, or sets two designers against each other: how much is a Goyard tote, Chrome Hearts hoodie price, Louis Vuitton shoes under 1000, Moncler vs Canada Goose. It only knows today's 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": {
      "query": "<query>"
    },
    "name": "price_check"
  }
}

Input Schema

Name	Required	Description
`size`	No	A size that must be in stock, as a shop labels it: 'M', '42', 'US 9'.
`query`	Yes	The designer and the item, in plain words: 'Chrome Hearts hoodie', 'Goyard tote', 'Jordan shoes under 500'. A price limit in the sentence is understood.
`category`	No	The kind of item, e.g. 'hoodies', 'sneakers', 'bags', 'jewellery'.
`designer`	No	The designer or brand, when the query names only the item.
`condition`	No	'pre-owned': only items the boutique marked used, second hand or pre-owned. 'new': only items it did not mark that way.
`price_max`	No	The most to pay, in the boutique's own currency.

Output Schema

Name	Required	Description	Default
`note`	Yes
`found`	Yes
`pages`	Yes
`query`	Yes
`pieces`	Yes
`prices`	Yes
`in_stock`	Yes
`view_url`	Yes
`boutiques`	Yes
`counted_on`	Yes
`understood`	Yes
`by_condition`	Yes
`compared_with`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 11, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnly, openWorld=false, idempotent), the description discloses the non-obvious behavior an agent most needs: prices stay in each boutique's own currency and are never converted, and results reflect only today's stock at shopwithin.co boutiques. That currency and freshness constraint is exactly the kind of context the annotations cannot express.

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?

It is front-loaded with the resource and the returned fields, and every clause carries information (return contents, currency rule, freshness, trigger examples). The first sentence is a long run-on list of outputs, which slows parsing slightly, and the usage sentence partly restates the purpose, but nothing is outright padding.

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 the description need not explain return shapes, yet it still summarises them usefully; annotations cover the safety profile and the description adds currency and stock-freshness constraints. What is missing is edge behavior (no-results handling) and a pointer to delivered_price when total landed cost rather than sticker price is wanted — minor against an otherwise complete definition.

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 all six parameters including the condition enum and price_max currency basis. The description reinforces a few semantics — a price limit stated in the query sentence is understood, and 'pre-owned' means boutique-marked used/second-hand vs the rest — but adds little beyond what the field descriptions already say. Baseline 3 applies.

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 names a specific verb and resource — a live price check on a designer item across independent luxury boutiques on shopwithin.co — and enumerates exactly what comes back (stock count, lowest/middle/highest price, pre-owned vs new split, cheapest few with shop links). An agent can distinguish it from search-oriented siblings like search_pieces or where_to_buy without opening the schema.

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 trigger conditions with worked examples: 'how much is something', 'compare prices', 'names a budget', 'two designers against each other' (Goyard tote, Louis Vuitton shoes under 1000, Moncler vs Canada Goose). It also states a hard scope boundary ('only knows today's stock at the boutiques on shopwithin.co'). It stops short of routing to alternatives such as delivered_price for landed cost or compare_pieces for piece-level comparison, so no exclusions are stated.

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