Korea Sets — Korean-version K-beauty sets

Check what to ask the user before a quote

clarify_request

Read-onlyIdempotent

Use when: the user's request is vague (no set named, no delivery country, only a city, a budget without a currency, or a budget that does not say whether shipping and duties are included), before estimate_total or request_quote. Do NOT use: to guess the answers yourself, or to send the order (use request_quote once status is ready). Returns: what is still missing, up to 2 questions to ask the user (in the request language: en, ko or ja) and the defaults to show without asking. status is ready or needs_info. If the user named only a city, send it as city: a known city fills the country (see filled); an unknown one is asked. If a budget amount has no currency, leave currency out and ask the returned currency question. Ask the questions as given; do not guess the delivery country or whether a budget includes shipping and duties. Approval before payment is never asked: show its shown_as text to the user. Sends no order; we keep one log line without personal data (field names and codes only). Returns trace_id: send it back in the next clarify_request and in request_quote. Send provenance (where each value came from); a value that is not just_confirmed comes back as a question with kind confirm: ask it as written. Example requests: "Send my friend in Toronto a nice Korean skincare set under 80." / "미국 사는 친구한테 10만 원 안쪽으로 한국 화장품 세트 보내 줘" / "友達に韓国のコスメセットを送りたい。予算は1万円くらい"

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

Input Schema

Name	Required	Description
`sku`	No	one set (sets[].sku from list_sets)
`city`	No	city the user named, when no country was said (e.g. Toronto)
`items`	No
`budget`	No
`trigger`	No
`category`	No	kind of product if no set was named; send "" when the user only said something vague like "something good"
`language`	No	language of the user, e.g. en, ko, ja
`quantity`	No
`trace_id`	No	optional: the trace_id an earlier clarify_request returned, so the steps of one request link up. Not personal data.
`arrive_by`	No	YYYY-MM-DD; send the words as said if they are not a date
`bundle_sku`	No
`provenance`	No	Optional provenance: an object that says where each value came from, keyed by request field (sku or items, quantity, ship_country or city, arrive_by, budget), each one of just_confirmed (the user said or confirmed it in this conversation), known_before (from memory or an earlier conversation), assumed (you inferred it) or unknown. Send it on POST /api/order/v1/checkout-sessions or the MCP tool clarify_request. We treat a value as confirmed only when it is just_confirmed: any other value, or a firm-quote field left out of provenance, comes back as status needs_info with a question (kind confirm) to ask the user as written. Without provenance nothing changes, and the answer carries provenance_note. The order request (POST /api/order/intake, MCP request_quote) also takes provenance, keyed by bundle_sku or items, quantity and ship_country only: the request is still received, and any of those not just_confirmed comes back in unconfirmed with questions (kind confirm) to ask the user before our email arrives.
`ship_country`	No	only if the user said it
`substitution`	No
`reference_order`	No	earlier order id, or {} when the user means "the one from last time" without an id

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, but the description adds real detail beyond them: it sends no order, it writes exactly one log line without personal data, approval before payment is never asked, and unconfirmed values come back as questions of kind 'confirm'. The only gap is that the logging side effect sits slightly uneasily with readOnlyHint without being reconciled explicitly, and return structure is largely left to the output schema.

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?

Well front-loaded with 'Use when / Do NOT use / Returns / Example requests' labels so the agent gets routing information first. It is dense and somewhat overlong: the provenance rule is restated from the schema, and three full example requests (en, ko, ja) plus the 'approval before payment' aside add bulk beyond what most calls need.

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 decision/handoff tool with 15 optional nested parameters and an output schema, the description covers the failure modes that matter (guessing country, guessing shipping-inclusive budget, confirm-kind questions, trace_id propagation) and supplies multilingual example inputs. Minor residual gaps are the unexplained trigger/substitution/reference_order inputs, but the output schema carries the return contract.

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?

With 15 parameters and 60% schema description coverage, the description usefully compensates on the ambiguous ones: city-only input (known city fills the country via 'filled', unknown one is asked), budget amount without currency (omit currency and ask the returned currency question), and provenance semantics (only just_confirmed counts, others return a 'confirm' question), plus trace_id round-tripping. It adds nothing about trigger, substitution, reference_order or items, which keeps it short of a 5.

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 opens with a concrete condition (vague request with concrete gaps: no set named, no delivery country, only a city, budget without currency or shipping basis) and states what the tool produces ('what is still missing, up to 2 questions to ask the user'). It explicitly separates itself from estimate_total and request_quote, so an agent can route correctly without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It has explicit 'Use when' conditions, an explicit 'Do NOT use' list (don't guess answers; don't use it to send the order — use request_quote once status is ready), and it names the downstream alternatives. Nothing is left to inference about ordering or exclusions.

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

All Korea Sets — Korean-version K-beauty sets tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?