GYOTAK Fish Market

place_order

Place an order. Two modes: (A) VIP wholesale: provide lineUserId of a registered VIP customer. (B) Guest retail: provide customerName, phone, items array, and a delivery address — shippingAddress, shippingProvince and email are all required, and an order missing any of them is rejected. Guest orders are priced at tier-linked retail rates (server-calculated) and the total is final at this point; a confirmation email with a PromptPay QR follows. Without customerKey or a personal token URL connection, every order creates a new customer with a new customerKey, even when the email was used before (orders are never linked to an existing customer by email); the new key is returned in the response and the confirmation email — tell the user to save it. Inventory is NOT deducted — orders go to the pick queue for staff fulfillment. Delivery is available within Thailand only, so the province must be a Thai one. International addresses are not accepted.

Input Schema

TableJSON Schema

Name	Required	Description
`lang`	No	(Guest mode, optional) Language of the confirmation email. Defaults to en.
`memo`	No	(Optional) Order notes
`email`	No	(Guest mode) Email address for the order confirmation — required for guest orders
`items`	No	(Guest mode) Order items
`phone`	No	(Guest mode) Contact phone number
`fishName`	No	(VIP mode) Fish name (romaji)
`totalThb`	No	(VIP mode) Total amount in THB
`lineUserId`	No	LINE user ID of VIP customer (VIP mode). Omit for guest mode.
`referrerId`	No	(Optional) Referrer ID for tracking
`customerKey`	No	(Guest mode) Registered customer key (from register_customer). Resolves name/phone/shipping automatically. If you are connected through a personal token URL the customer is already resolved: send items[] alone and omit this, customerName, phone and lineUserId.
`requestedKg`	No	(VIP mode) Requested weight in kg
`customerName`	No	(Guest mode) Customer name
`shippingAddress`	No	(Guest mode) Street address and building name — required for guest orders
`shippingDistrict`	No	(Guest mode) Hua Hin / Pranburi 等の地元配達判定に必須。住所に含まれていれば自動判定するが、明示推奨 / District name. Required to detect local (free) delivery for Hua Hin / Pranburi. Auto-detected from shippingAddress when present, but explicit value recommended.
`shippingProvince`	No	(Guest mode) Thai province name, used for shipping cost — required for guest orders. Thailand only.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 11, 2026

addedInput schema / properties / items / items / properties / status

Added value: +{
+  "description": "Cut / preparation of the fish (e.g. \"sashimi fillet\"). Pass the status shown for this fish in get_catalog, verbatim. Optional: when omitted the server fills it in from stock, and asks which one if more than one cut is available.",
+  "type": "string"
+}

Changed1 schema field changedSep 9, 2026

changedInput schema / properties / shippingDistrict / description

Previous value: -"(Guest mode, optional) District name"New value: +"(Guest mode) Hua Hin / Pranburi 等の地元配達判定に必須。住所に含まれていれば自動判定するが、明示推奨 / District name. Required to detect local (free) delivery for Hua Hin / Pranburi. Auto-detected from shippingAddress when present, but explicit value recommended."

First observedSep 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses that guest orders are priced at retail rates, the total is final, a confirmation email with a PromptPay QR follows, a new customer is created when no customerKey or token URL connection exists, inventory is not deducted, and delivery is Thailand-only. These are exactly the behavioral traits an agent needs to know before invoking the tool.

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 description is long but every sentence contributes necessary operational detail. It is front-loaded with the two modes and required fields, then expands into behavioral caveats. A slightly more structured layout (e.g., separating modes) would improve scannability, but there is no wasted text.

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 complex 15-parameter tool with no annotations and no output schema, the description covers a remarkable amount: modes, required fields, pricing, customer creation, inventory handling, delivery constraints, and confirmation behavior. It falls just short of full completeness by not describing the response structure beyond the returned customerKey and not covering error cases beyond missing required fields.

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 adds meaningful context beyond the schema by explaining mode-specific requirements, the customerKey resolution behavior, and the personal token URL shortcut. This elevates it above the baseline without needing to restate every parameter.

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 'Place an order' and immediately distinguishes two concrete modes (VIP wholesale and guest retail), each with its own required inputs. This makes the tool's function unmistakable and separates it from sibling tools like create_payment or check_payment_status.

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?

The description provides clear context for when to use each mode, including required fields and the condition for omitting customerKey when connected via a personal token URL. It does not explicitly name alternative tools or state when not to use this tool, but the mode-based guidance is strong enough for an agent to decide correctly.

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

All GYOTAK Fish Market 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?