within

One boutique: address, hours, designers

boutique_details

Read-onlyIdempotent

Find an independent shop by name, city, or directory URL to retrieve its type, address, neighborhood, opening hours, brands, website, Instagram, and online selling details.

Instructions

One boutique from within's directory of independent shops in more than 140 cities: what kind of shop it is, its address and neighbourhood, its opening hours with the day they were read, its website and Instagram, the designers its own site lists, and its page on shopwithin.co. For a boutique that sells on within it adds how many items are live and the boutique's domain. Use this when someone asks about a shop by name: where it is, when it is open, what brands it carries, its store locations, or whether it sells online. If two shops share the name it lists them and asks for the city. It holds hours for some shops only, and no phone numbers, ratings or reviews. A url is the shop's own page on shopwithin.co; the tool reads within's own directory, documented at https://shopwithin.co/agents.

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

Input Schema

Name	Required	Description
`url`	No	The shop's directory page on shopwithin.co, in place of the name, e.g. 'https://shopwithin.co/directory/miami/boutiques/miami-twice'.
`city`	No	The city the shop is in, when the name is not unique, e.g. 'Paris'.
`name`	No	The shop's name, e.g. 'Miami Twice', 'SW3 Boutique', 'Mohawk General Store'.

Output Schema

Name	Required	Description	Default
`note`	Yes
`found`	Yes
`matches`	Yes
`boutique`	Yes
`stockists`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds real context beyond the annotations: coverage caveat ('hours for some shops only'), explicit exclusions ('no phone numbers, ratings or reviews'), a conditional behaviour (live item count and domain only for boutiques selling on within), and disambiguation handling. Since readOnly/idempotent/non-destructive are already in annotations, this text is doing genuinely additive work, though it does not describe response shape or failure modes.

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 content is dense but each clause carries distinct information (fields returned, when to use, caveats, ambiguity handling, url semantics). The main weakness is structure: the return-field list comes before the 'Use this when' routing sentence, so the most agent-critical guidance is not fully front-loaded.

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?

An output schema exists so return values need no explanation, and the description nonetheless covers the schema of the data, coverage limits, exclusions, and conditional fields. For a read-only lookup tool with full schema coverage, nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a 3 is the baseline. The description earns above it by disambiguating the ambiguous 'url' parameter ('A url is the shop's own page on shopwithin.co') and by framing city as a disambiguator when a name is shared. It does not clarify whether name/url are mutually exclusive or what the fallback order is.

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: 'One boutique from within's directory' and then enumerates exactly what is returned (type of shop, address and neighbourhood, hours with read date, site, Instagram, designers, shopwithin.co page). The singular 'One boutique' plus the detailed field list separates it cleanly from directory-style siblings such as list_boutiques and boutique_directory.

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 explicit when-to-use guidance with concrete question types: shop by name, where it is, opening hours, brands carried, store locations, whether it sells online. It also handles the ambiguity case ('if two shops share the name it lists them and asks for the city'). It does not name an alternative tool for the opposite case (e.g. browsing or listing shops), which keeps it below 5.

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