within

Pick up in a shop

pickup_today

Read-onlyIdempotent

Find clothing, shoes, bags and jewellery in stock at independent boutiques for same-day pickup, with sizes, prices, addresses, opening hours and filters by city, designer, category, size and price.

Instructions

Clothes, shoes, bags and jewellery a shopper can buy on shopwithin.co and pick up in the shop: in stock now at independent boutiques that offer pickup, each with its price, the sizes in stock, the shop and its street, and the shop's hours where they are held. Where the hours are held it says whether the shop is open today. Use this when someone asks for pick up in store, buy online and pick up in store, same day pickup, or what they can collect today in a city, with a search, designer, category, size or price cap. It covers only the boutiques on within that offer pickup.

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": "pickup_today"
  }
}

Input Schema

Name	Required	Description
`city`	No	The city the shops are in, e.g. 'Toronto': a place to shop, not the shopper's own location.
`limit`	No	Items per page, default 12.
`query`	No	What to look for, in plain words: 'black loafers', 'Rick Owens jacket'.
`sizes`	No	Sizes that must be in stock, as they appear in results: 'M', '42', 'US 10'.
`offset`	No	Items to skip; use next_offset from the page before.
`designers`	No	Designer or brand names, as they appear in results: 'Rick Owens', 'Chrome Hearts'.
`price_max`	No	Highest price to include, in the boutique's currency.
`categories`	No	Kinds of item, e.g. 'Sneakers', 'Jackets', 'Bags'; take values from a search result's facets.
`department`	No	Only women's or only men's.

Output Schema

Name	Required	Description	Default
`note`	Yes
`shops`	Yes
`pieces`	Yes
`view_url`	Yes
`next_offset`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 11, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavior: results are constrained to items physically in stock at pickup-capable boutiques, each row carries shop address and opening hours, and an open-today determination is included only where hours are held. Pagination mechanics are left to the schema rather than the prose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is front-loaded with what the tool returns, then the usage cases, which is the right order. However, both sentences are long run-ons with nested clauses, and phrases like 'pick up in the shop' and 'pick up in store' recur several times. Some trimming would improve scanability without losing information.

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 nine optional parameters, an output schema present, and full annotation coverage, the description supplies the missing conceptual framing: what a result contains and the pickup-only constraint. Nothing essential for correct invocation is absent, though a note on result ordering (e.g., default sort) would make it fully 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%, so the schema already explains city, query, sizes, designers, categories, price_max, limit and offset. The description echoes the same filter set ('a search, designer, category, size or price cap') without adding syntax, defaults, or units beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific resource and scope: in-stock items at independent boutiques that offer pickup, with price, sizes in stock, shop street and hours, plus an open-today flag. It also bounds the corpus ('only the boutiques on within that offer pickup'), which implicitly separates it from general browsing siblings. It stops short of naming a specific alternative tool, keeping it at a 4 rather than a 5.

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?

Explicit trigger phrasing is given: 'pick up in store, buy online and pick up in store, same day pickup, or what they can collect today in a city'. It also lists the filter dimensions the request may combine. No explicit when-NOT-to-use or named alternative for non-pickup shopping queries, so it misses the top band.

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