Skip to main content
Glama

Korea Sets — Korean-version K-beauty sets

Send an order request (no payment)

request_quote

Use when: the user agreed to send their email address and the listed sets, and wants a confirmed delivered total (request="order") or an email when a set is available again (request="notify"). Do NOT use: if the user's request is vague (no set named, no country, or a budget without saying whether shipping and duties are included): call clarify_request first and ask its questions. Do NOT use it to pay, to reserve stock or to send names, street addresses, phone numbers or payment details. Returns: order_id and request_summary (or watch_id for notify). No payment and nothing reserved: a person on our team emails the confirmed delivered total; nothing is bought before the customer accepts. Send only these fields — never names, street addresses, phone numbers or payment details. Read request_summary back to the user. Retries: send idempotency_key (a UUID you keep for this one request); sending the same request again with the same key returns the same order_id instead of a second request (idempotency in the result says whether this call was retry-safe). Send provenance (where each value came from): a value that is not just_confirmed comes back in unconfirmed with a question (kind confirm) to ask the user. Example requests: "Order this Korean set for my sister in Seattle; email me the confirmed total first." / "이 세트 미국 시애틀로 주문 요청해 줘. 확정 금액은 메일로 먼저 받을게" / "このセットを大阪に送る注文を依頼して。確定金額を先にメールで"

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": {
      "ship_country": "<ship_country>",
      "contact_email": "<contact_email>"
    },
    "name": "request_quote"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemsNo
optionsNochoices for sets that have them, keyed by bundle_sku, e.g. {"<sku>": {"scent": "Cotton Haze"}} — values in list_sets sets[].options
requestNo
languageNoreply language tag, e.g. en, ja, es
quantityNo
trace_idNooptional: the trace_id an earlier clarify_request returned, so the steps of one request link up. Not personal data.
bundle_skuNoone set (use items for several sets)
client_refNoyour own task id, echoed in our log; not used for retries
provenanceNoOptional provenance: where each value came from, keyed by bundle_sku or items, quantity and ship_country, each one of just_confirmed (the user said or confirmed it in this conversation), known_before, assumed or unknown. The request is still received; any value not just_confirmed comes back in unconfirmed with questions (kind confirm): ask the user before our email arrives.
ship_regionNostate/province/prefecture name only — not an address
ship_countryYes
contact_emailYesone email address for the confirmed quote
idempotency_keyNooptional retry key (e.g. a UUID) for this one request: the same key with the same request returns the same order_id. Without it, trace_id is used as the key when sent.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations it discloses what actually happens: nothing is charged or reserved, a human emails the confirmed total, fields that are not just_confirmed come back in unconfirmed with kind=confirm questions, and retry semantics. One wrinkle is that idempotentHint=false while the description claims retry-safety via idempotency_key — this is explained as conditional, so it reads as added nuance rather than a contradiction, but the two are not fully reconciled.

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 Use when / Do NOT use / Returns / Retries structure is front-loaded and scannable, and the example requests in three languages help. It loses a mark for restating the no-names/no-addresses/no-payment rule twice in slightly different words.

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 13-parameter nested mutation tool with an output schema, the description covers triggers, exclusions, return values, retry behavior, and data-minimization constraints. An agent has everything needed to call it correctly without additional context.

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 69% schema coverage across 13 params, the description adds real meaning for the least obvious fields: provenance values and their downstream consequence, idempotency_key versus the trace_id fallback, and contact_email's purpose. It does not explain items vs the single bundle_sku, options, or language beyond what the schema already says.

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 specific trigger and names the two request modes explicitly (request="order" vs request="notify"), and the title reinforces the scope with "no payment". It is unmistakably distinguishable from siblings like clarify_request and estimate_total.

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 gives both a when-to-use condition (email plus listed sets are agreed, the user wants a confirmed total or a restock email) and explicit when-not guidance: vague requests with no set, no country, or ambiguous budget must go to clarify_request first. It also excludes payment, stock reservation and personal data.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources