within

Delivery, pickup and returns at a boutique

delivery_and_returns

Read-onlyIdempotent

Check delivery costs, shipping times/countries, free-shipping thresholds, pickup and return policies for boutiques; omit the boutique for a per-boutique country summary.

Instructions

Delivery, pickup and returns at the independent boutiques that sell on within. For one boutique: what delivery to a country costs and how long it takes, the price an item ships free from, the countries it ships to, pickup in the shop, and its return policy (final sale, how many days, refund, exchange or store credit), read from the boutique's own pages. With no boutique: one line per boutique for the country. Use this when someone asks about a boutique's return policy or free returns, whether it ships to the USA, Canada or another country, what delivery costs, same day delivery, or pick up in store. Prices are in Canadian dollars, before duty and tax. It covers the boutiques on within only.

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

Input Schema

Name	Required	Description	Default
`country`	No	Where it is delivered: a country name or two letter code, e.g. 'Canada', 'US', 'Sweden'. Leave out for Canada and the United States.
`boutique`	No	The boutique's domain or name, e.g. 'utopia-kicks.myshopify.com' or 'Due West'. Leave out for every boutique.

Output Schema

Name	Required	Description	Default
`note`	Yes
`country`	Yes
`boutiques`	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?

Annotations already establish read-only, idempotent, closed-world behavior, so the description focuses on what annotations cannot convey: data is read from the boutique's own pages, prices are in CAD before duty and tax, and coverage is limited to boutiques on within. The duty/tax and currency caveats are genuinely useful for interpreting results, though nothing is said about freshness or caching.

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-loads the resource scope, then the two modes, then the trigger questions and pricing caveat. It is dense but mostly earns its length; the closing 'It covers the boutiques on within only' slightly repeats the opening scope clause.

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?

For a two-optional-parameter read tool with an output schema, the description supplies everything an agent needs to choose it and call it correctly: coverage boundary, both invocation modes, currency and tax basis, and example question phrasings.

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 the baseline is 3; the description goes beyond it by explaining the combinatorial semantics of the two optional parameters (boutique present = one boutique's full policy, absent = one line per boutique for the country). It does not restate the accepted country formats, which the schema already handles.

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 set (delivery cost, shipping countries, free-shipping threshold, pickup, return policy) scoped to boutiques selling on within. An agent can immediately tell this is a policy/logistics lookup rather than a product search, which separates it from siblings like search_pieces or get_piece.

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 questions (return policy, free returns, ships to the USA/Canada, delivery cost, same-day delivery, pick up in store) and explains the two modes: one boutique for full detail, no boutique for a per-boutique line. It stops short of naming alternatives or exclusions, so it does not reach the 5 tier.

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