Sashimi-grade flash-frozen fish from Thailand. Catalog, ordering, and on-chain traceability.
Scored across 23 tools
Several near-duplicate pairs coexist: get_catalog vs search_fish (both return products/prices), get_catch_reports vs verify_catch, get_komon_records vs verify_komon, and three order-history tools (my_orders, get_order_history, verify_purchase) split by channel. The descriptions do carefully cross-reference and differentiate each pair, but with 23 tools the agent must read a lot of prose to pick correctly, and ask_gyotak vs get_contact_info vs contact_gyotak is easy to confuse.
Dominant pattern is verb_noun (get_catalog, verify_catch, register_customer, place_order, claim_purchase_proof) with coherent verb families get_*/verify_*/register_*. Deviations are minor: my_orders and my_referrals use a possessive style instead of get_my_* (inconsistent with get_order_history), and apply_referrer uses an odd verb-noun pairing.
23 tools is at the heavy end of the scale; the domain is genuinely broad (commerce, blockchain verification, referrals, support), so most tools earn their place. Still, the surface could be consolidated — the catalog/search and database/on-chain verification pairs could be merged into single tools with a mode argument.
Core lifecycle is covered: browse → register → order → history → verify provenance/referrals → support. But notable commerce operations are missing: no cancel or modify order, no shipping/delivery tracking, and no customer-profile update, all of which will cause dead ends for common user requests.
Look up your GYOTAK referral MCP URL. The URL is issued automatically when the payment for your first chat order is confirmed and is included in the payment confirmation email; call this to see it again. If you have a paid order but no URL yet, one is issued now. Referrers earn 5% of the product subtotal on paid orders placed through their URL. If you are connected through a personal token URL, omit customerKey.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Referrer display name — optional, defaults to your registered name | |
| contact | No | Contact (email, LINE ID, etc.) — optional | |
| customerKey | No | Your customerKey (gyotak_cus_...). Omit when connected through a personal token URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, but the description adds genuinely non-redundant behavior: the URL is auto-issued upon payment confirmation, a call can trigger issuance, and the 5% earning rate is explained. It also covers the auth variant (personal token URL → omit customerKey). It does not state whether repeated calls regenerate the URL or what the response contains, keeping it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, and the issuance condition follows logically. The 5% commission sentence is useful motivation rather than filler, though the description is denser than strictly necessary for a lookup with an issuance side effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of indicating the return — 'call this to see it again' implies the URL is returned, though the exact response shape is unspecified. With zero required parameters and full schema coverage, this is close to complete; only the response form is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three optional parameters, establishing a baseline of 3. The description largely restates the schema's customerKey guidance ('omit customerKey' for personal token URLs) and adds no detail on how name or contact affect the referral record. No semantic value beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Look up your GYOTAK referral MCP URL', and adds the important nuance that the same call may issue a URL if none exists yet. That distinguishes it functionally from the name 'apply_referrer', which alone would suggest only an application action. It does not explicitly differentiate itself from sibling tools like my_referrals or get_share_kit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is given for when to call: the URL arrives in the payment confirmation email, and this tool is how you 'see it again'. The condition 'If you have a paid order but no URL yet, one is issued now' further clarifies eligibility. No explicit exclusions against sibling tools such as my_referrals, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search GYOTAK FAQ for answers about shipping, payment, products, defrosting, traceability, B2B registration, etc. Returns top matching FAQ entries. If no match, suggest using contact_gyotak to escalate.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Question text (any language) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive behavior, so safety is covered. The description adds real value beyond that: it says the output is the top matching FAQ entries and defines the no-match fallback behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, nothing wasted: purpose and coverage first, then return behavior and fallback. Front-loaded with the searchable domain before the escalation note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter retrieval tool with full annotation coverage, the description supplies enough: what to search, what comes back (top matches), and what to do on failure. Only the granularity of the returned entries is left slightly implicit, which is minor with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents the single question parameter, including that any language is accepted. The description adds no additional syntax, formatting, or phrasing guidance. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (GYOTAK FAQ), then enumerates concrete topics covered: shipping, payment, products, defrosting, traceability, B2B registration. It also names the sibling tool to use when it fails, so an agent can separate it from contact_gyotak and the record-lookup siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the primary use case (answering customer questions from the FAQ) and gives an explicit escalation path to contact_gyotak when no match is found. It does not distinguish against catalog/report tools for product data questions, so it is clear context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if GYOTAK staff has replied to a previously submitted inquiry.
| Name | Required | Description | Default |
|---|---|---|---|
| inquiryId | Yes | Inquiry ID (e.g. "INQ-042") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the precondition of a prior inquiry; it says nothing about what the check returns (a boolean flag, a message, a status code) or how recently it polls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the core action and object come first. It is perhaps slightly terse given the undefined return value, but nothing in it is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with full annotation coverage, the description is nearly sufficient. The notable gap is the absence of an output schema combined with no description of what "check" yields, leaving the agent to guess whether it gets a boolean or reply content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single inquiryId parameter is documented with a concrete example ("INQ-042"). The description adds no format or validation detail beyond what the schema already supplies, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) and resource (staff reply on a previously submitted inquiry), which is unambiguous. It implicitly distinguishes itself from ask_gyotak/contact_gyotak by describing a status check rather than submission, but never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "previously submitted inquiry" implies a prerequisite (an inquiry must already exist) and that this is a follow-up check. However, there is no explicit when-to-use guidance, no statement about when not to use it, and no named alternative for submitting an inquiry in the first place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link your own purchases’ on-chain purchase proofs to your X (Twitter) account, so a post of yours can be checked against the chain. Buyer’s X account (self-declared): the buyer linked this purchase to their own X account; GYOTAK has not checked that the account belongs to the buyer. Each stamped purchase comes with the URL of its public verification page. Only works through a personal token URL connector — there is no customerKey argument. Called with no arguments it only lists the purchases that can be linked and links nothing, every time — pass handle to actually link. A link is stamped on chain and cannot be undone, so let the user pick the handle before you pass one. Automatic binding of future purchases is off by default: to turn it on, pass handle with auto_bind "on" — the first such call returns the consent text; show it to the user word for word (the text is in Japanese and English; show both), and only if they agree call again with consent true. Pass auto_bind "off" to stop it (no handle needed); only later purchases stop, anything already recorded stays.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | No | Your X handle without the leading @ (letters, digits and underscore, 1-15 characters). Required to link: a call without it only lists your purchases and links nothing, even if you linked before. Pass it on every link. | |
| consent | No | Set true only when the user has read the consent text returned by an earlier auto_bind "on" call and agreed to it. Never set it on your own. | |
| auto_bind | No | Turn automatic binding of future purchases to your X handle on or off. "on" needs handle and consent. "off" needs nothing else. Omit to leave the setting as it is. | |
| purchase_id | No | Link only this purchase (e.g. "PB-20260917-a97953d3"). Omit to link every purchase of yours that is not linked yet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive and non-idempotent, and the description adds the decisive detail: the link is stamped on chain and cannot be undone. It further discloses the token-URL-connector constraint (no customerKey argument), the opt-in default for auto binding, and the exact consent flow, all far beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical constraint (no-arg calls link nothing; irreversibility) is front-loaded and no sentence is pure filler, but the prose is dense and runs several clauses together, and some parameter behavior is restated from the schema. Slightly tighter phrasing would improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, irreversible write tool with no output schema, the description covers the safety gate (user must choose the handle), the consent round-trip, the returned verification page URL, and the token-connector precondition. An agent has enough to invoke it correctly and in the right sequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already carries the syntactic definitions, giving a baseline of 3. The description adds procedural meaning the schema cannot: that auto_bind "on" returns consent text that must be shown verbatim in both Japanese and English, and that "off" stops only future bindings while recorded links persist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: linking on-chain purchase proofs to the caller's X account, and clarifies the self-declared nature of the buyer's handle. An agent can distinguish this from verify_purchase or check_reply without opening any schema, especially since the description also spells out the no-argument list-only behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says a bare call only lists linkable purchases and links nothing, that handle must be passed on every link, and that the user must pick the handle before it is passed. It also lays out the auto_bind on/off/omit conditions and the consent two-call sequence, so when-to-use versus when-not is fully covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a question to GYOTAK staff when FAQ does not have the answer. Staff will reply via Discord. Use check_reply to retrieve the response later.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Your name (optional) | |
| question | Yes | Question to ask GYOTAK staff |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already say readOnly=false, destructive=false, openWorld=true; the description adds meaningful behavior beyond them: the reply arrives out-of-band via Discord and is asynchronous, requiring a later check_reply. It stops short of stating whether a ticket/reference id is returned or expected turnaround time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each carrying distinct information: the action, the gating condition, and the retrieval path. Nothing is repeated from the name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully explains that no direct answer is returned and where the reply lands. The remaining gap is what the call itself returns (e.g., a reference id needed for check_reply), which an agent would want to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with only two simple parameters, so the schema already documents both fields. The description adds no extra meaning about format, length, or how the optional name is used, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ("Submit a question to GYOTAK staff") and scopes it to the case where the FAQ lacks an answer. It implicitly separates itself from a FAQ-style sibling but never names ask_gyotak explicitly, so the agent must infer that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"when FAQ does not have the answer" is an explicit triggering condition, and "Use check_reply to retrieve the response later" names the correct follow-up tool. No explicit when-not case or rate/permission preconditions are given, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get GYOTAK's full fish catalog with real-time availability, retail prices (THB/kg), freshness tiers, and traceability records. Retail prices are always included. For registered chat customers, pass customerKey (gyotak_cus_...) to show wholesale pricing and enable one-tap checkout. For LINE VIP customers, pass lineUserId. Delivery is available within Thailand only. International addresses are not accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| lineUserId | No | LINE user ID for VIP pricing (optional) | |
| customerKey | No | GYOTAK customerKey (gyotak_cus_...) for registered chat customers — enables identification, wholesale pricing, and one-tap checkout (optional) |
| Name | Required | Description |
|---|---|---|
| vip | No | Customer line shown for a registered customer |
| items | Yes | Catalog lines in the order shown (empty when no stock) |
| catalog | No | Used by the catalog widget (on-chain provenance per item) |
| nextActions | No | Used by the catalog widget (buttons) |
| customerContext | No | Used by the catalog widget |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and closed-world, and the delivery restriction aligns with openWorldHint=false while making it concrete. The description adds real behavioral context beyond annotations: retail prices are always returned, wholesale pricing is conditional on identity, and international addresses are rejected. It does not describe pagination or catalog size, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with what is returned, then the two identity params, then the delivery constraint. No filler; the only mild redundancy is repeating the customerKey benefits already present in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return shape needs no explanation, and the description covers pricing tiers, identity options, and the geographic restriction. The remaining gap is minimal — no guidance on catalog size or caching, which is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions already explain both params, including the wholesale pricing and one-tap checkout effects. The description largely restates those effects, adding only the 'retail prices are always included' fallback behavior, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get GYOTAK's full fish catalog') and enumerates what the payload contains: availability, retail prices in THB/kg, freshness tiers, traceability. This clearly separates it from search_fish, which would be the filtered-lookup sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit conditional context: pass customerKey for registered chat customers to unlock wholesale pricing and one-tap checkout, pass lineUserId for LINE VIP customers, and delivery is Thailand-only. It does not explicitly compare against search_fish or say when not to use the catalog, but the selection conditions for the optional params are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get catch records by date or freshness tier. Returns the catch date, the region (district name), the blog post URL when published and, for records registered on the Midnight blockchain, a verify link per batch. Exact GPS coordinates are never returned: on v3 records the exact position is not on the chain (only a commitment to it); the district name is a label set by GYOTAK. GYOTAK checks the region range when recording, but the range used is not part of the record, so a third party cannot confirm it from the chain; GYOTAK can disclose the position of a record individually. In-stock products reference these records by date. To check a record on-chain without trusting GYOTAK, open its verify link, or call verify_catch with network "mainnet", the v3 contract address given in the response and the batch ID.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD format. Returns records for that specific date. | |
| tier | No | Freshness tier: fresh=last 30 days, tier1=31-60 days, tier2=61-90 days |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| limit | No | Present when only the most recent records are shown |
| reports | Yes | |
| verifyCatchContract | No | Arguments for verify_catch on v3 records |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent safety, and the description adds substantial context beyond them: GPS coordinates are never returned, v3 records hold only a commitment, the district is a GYOTAK-set label, and the recorded range cannot be independently confirmed from the chain. That is exactly the trust/limitation disclosure an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and return shape are front-loaded, and the verification guidance near the end is actionable. The blockchain/privacy passage is dense and semicolon-chained, but each clause carries real information about what is and isn't returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still summarizes returned fields (date, region, blog URL, verify link) and, crucially, states the privacy limitation on coordinates. Combined with the sibling routing to verify_catch, nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including the enum meanings and the YYYY-MM-DD format, so the schema carries the parameter burden. The description only restates the two filter axes and adds no syntax or precedence rules beyond what the schema documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource plus the two selection axes ('by date or freshness tier'), and enumerates what is returned. An agent can distinguish it from verify_catch and get_komon_records without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: use this tool for listed catch records, but 'to check a record on-chain without trusting GYOTAK' open the verify link or call verify_catch with the given network/contract/batch ID. It also notes that in-stock products reference records by date, giving a reason to use date filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the two ways to buy from GYOTAK, with the contact details for each: retail (order here through place_order, or browse the web shop) and B2B wholesale for restaurants and businesses (LINE @284ezjvm, tier pricing, application required). Call this when the user asks how to buy, how to open a wholesale account, or how to reach GYOTAK. Takes no arguments and returns static text — for product availability or prices use get_catalog, and for other questions use ask_gyotak.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it 'takes no arguments and returns static text,' telling the agent the call is cheap, deterministic, and content-fixed rather than dynamic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, followed by content details, trigger conditions, and fallbacks in a logical order with no filler. It runs somewhat long as a single dense paragraph for what is a simple static-text tool, but every clause carries routing or content information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument, no-output-schema tool, the description covers what it returns (static contact/buying info), what it does not cover (prices, availability), and where to go instead. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero-parameter tool, which sets the baseline at 4. The description confirms 'takes no arguments,' reinforcing the empty schema and preventing an agent from inventing filter parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('get the two ways to buy... with contact details for each') and enumerates the actual content: retail via place_order/web shop and B2B wholesale via LINE with tier pricing and an application requirement. It explicitly distinguishes itself from get_catalog and ask_gyotak, so an agent can route correctly without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger conditions ('when the user asks how to buy, how to open a wholesale account, or how to reach GYOTAK') and names the alternatives with their selecting conditions: get_catalog for availability/prices, ask_gyotak for other questions. Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get GYOTAK KOMON physical authentication records from the database. Each record represents a PUF (physically unclonable function) registration with minutiae extraction and on-chain commitment. Shielded records do not expose GPS.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status (default: all non-test) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds meaningful domain behavior beyond that: what a record represents and that shielded records withhold GPS, which affects how results should be interpreted. It stops short of describing result volume or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the resource definition front-loaded and the privacy caveat second; no filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately explains what each returned record represents and one key field-visibility caveat. It does not cover whether results are scoped to the caller, pagination, or ordering, which would matter for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter at 100% schema description coverage (including enum values and the 'default: all non-test' note), the schema does the heavy lifting. The description never mentions the status filter, so it adds nothing beyond the schema here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get GYOTAK KOMON physical authentication records') and explains what a record contains (PUF registration, minutiae extraction, on-chain commitment). It does not explicitly distinguish itself from the sibling 'verify_komon', so sibling differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to call this versus 'verify_komon' or when a status filter should be applied. The only scoping hint ('shielded records do not expose GPS') describes output behavior, not invocation conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get B2B order history (last 20 orders). Requires lineUserId of a registered VIP customer.
| Name | Required | Description | Default |
|---|---|---|---|
| lineUserId | Yes | LINE user ID of the VIP customer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds two things annotations cannot express: a result cap ('last 20 orders') and an authorization precondition (the ID must belong to a registered VIP), which materially affects how the agent interprets empty or error results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler; the scope cap and the precondition are front-loaded before any reader would need to open the schema. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full schema coverage and no output schema, the essential facts are present: what it returns, how many, and who it applies to. The main residual gap is that the return shape beyond count (order fields, pagination, or truncation behaviour) is not hinted at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already documented as 'LINE user ID of the VIP customer'. The description restates the same constraint ('requires lineUserId of a registered VIP customer'), adding only the nuance that the ID must be registered, so it neither harms nor meaningfully extends the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get B2B order history') plus a scope qualifier ('last 20 orders') and the audience ('registered VIP customer'). It is clear on its own, but it never names the obvious sibling 'my_orders', so the agent must infer the self-vs-VIP distinction rather than being told.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Requires lineUserId of a registered VIP customer' establishes a precondition for use, which is genuine guidance. However, it gives no explicit when-not condition and does not route the agent to the alternative (my_orders) for the non-VIP case, so the usage boundary is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order history of a LINE VIP customer connected through their personal token URL (gyk_…). No arguments needed — the customer is the owner of this connection. Lists each order (and each invoice not tied to an order) with its date, status (paid / unpaid / overdue / cancelled / awaiting picking / awaiting invoice), the invoice total and due date when an invoice exists, and the items with requested kg → actual kg from the invoice. Invoices and receipts are not linked in the text: the user opens them from the buttons in the catalog widget (Orders tab). Chat-registered customers cannot list orders here; the Receipt button in their widget calls this tool with document=receipt and ref= to get a 15-minute receipt link for a paid order. Not for guests.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Used only by the widget buttons (an order or invoice id from this tool's result). | |
| document | No | Used only by the widget buttons. Do not set it when the user asks for their orders. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context (per-connection token ownership, a 15-minute receipt link lifetime, invoices not linked in text) but says nothing about result size, pagination, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what the tool returns and the no-argument invocation before the widget-button caveat. Dense but almost every sentence carries information; the invoice/receipt linking note is slightly convoluted but still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by enumerating the return shape (date, status values, invoice total, due date, requested vs actual kg) plus the receipt-link special case. An agent has enough to call it and interpret results without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description goes beyond the schema by tying ref to 'an order or invoice id from this tool's result' and giving the exact document=receipt + ref=<order id> invocation that yields a 15-minute receipt link. That adds real invocation semantics the schema only hints at.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (order history of a LINE VIP customer) and enumerates what is returned (orders, standalone invoices, statuses, item kg). It clearly rules out chat-registered customers and guests, but never mentions the sibling get_order_history, so an agent has no explicit differentiation cue against the most similar tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete conditions: 'No arguments needed', 'Chat-registered customers cannot list orders here', 'Not for guests', and explains that widget buttons call it with document/ref. The only missing piece is when to choose this over get_order_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show your referral summary as a GYOTAK referrer: your referral URL, number of referred orders (paid / unpaid), this month's estimated commission, unpaid balance, payout destination status, and the last 5 paid referred orders (order number, date, subtotal, commission — no buyer details). Only works for the customer of this connection; if you are connected through a personal token URL, omit customerKey.
| Name | Required | Description | Default |
|---|---|---|---|
| customerKey | No | Your customerKey (gyotak_cus_...). Omit when connected through a personal token URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: the result is scoped to this connection's customer, contains no buyer details (a privacy constraint), and caps order history at the last 5 paid orders.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and the identity scope, and every listed return field earns its place since there is no output schema. The single long sentence is dense and slightly run-on, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by enumerating the return payload, and it covers the one optional parameter's conditional use. It stops short of saying what happens when the customer is not a referrer or has no payout destination configured, which an agent would need before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the customerKey property already documents 'Omit when connected through a personal token URL,' so the description is largely restating the schema. It adds no format examples or error behavior for a wrong/missing key beyond the omit condition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Show your referral summary as a GYOTAK referrer') and then enumerates exactly what the summary contains: referral URL, paid/unpaid order counts, estimated commission, unpaid balance, payout destination status, and last 5 paid orders. This clearly separates it from siblings like apply_referrer, report_share, get_share_kit, and register_payout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a useful scoping rule ('only works for the customer of this connection') and a concrete connection-mode condition for omitting customerKey. However, it never names an alternative tool or states what to do if the caller is not yet a referrer (apply_referrer) or needs payout setup (register_payout), so routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. (C) LINE VIP customer connected through a personal token URL (get_catalog says ordering is available in this chat): send vipItems only — one entry per item, with fishName, status and tier exactly as get_catalog shows them and the quantity in the form get_catalog gives for that item (bands, packs or kg). The server calculates prices, shipping and the total; the total is an estimate, billing is by invoice after picking, and no payment is taken now. Call with dryRun: true first, show the user the lines and the estimate, and place the order only after the user confirms.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | (Guest mode, optional) Language of the confirmation email. Defaults to en. | |
| memo | No | (Optional) Order notes | |
| 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 | |
| dryRun | No | (LINE VIP mode only) true = return the lines and the estimated total without placing the order | |
| fishName | No | (VIP mode) Fish name (romaji) | |
| totalThb | No | (VIP mode) Total amount in THB | |
| vipItems | No | (LINE VIP mode only) Order lines for a LINE VIP customer connected through a personal token URL. Ignored in other modes. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given readOnlyHint=false and idempotentHint=false, the description adds substantial non-obvious context: inventory is NOT deducted (orders go to the pick queue), guest totals are final while VIP totals are estimates billed by invoice, a PromptPay QR confirmation email follows guest orders, and every order without customerKey creates a new customer even for a reused email. It does not contradict any annotation. It stops short of 5 because failure handling beyond guest-address rejection is unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and mode routing, and most sentences carry real load (permissions, pricing finality, inventory, delivery scope). Minor friction: it announces "Two modes" then lists three (A/B/C), and the customerKey guidance is partially duplicated between the description and the parameter doc.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter, no-output-schema, openWorld mutation tool this is close to complete: it covers mode prerequisites, required guest fields, pricing semantics, delivery geography, dryRun, and one returned value (customerKey). What remains thin is the full response shape — the description notes the key is returned but does not say what else comes back for either mode, leaving the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description supplies the decisive fact the schema omits: the schema declares zero required parameters, yet the description states shippingAddress, shippingProvince and email are all mandatory for guest orders and that a guest order missing any is rejected. It also constrains shippingProvince to a Thai province and explains that vipItems entries must mirror get_catalog's fishName/status/tier and quantity form verbatim, which is meaning beyond field-level docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ("Place an order") and immediately enumerates three distinct order paths (VIP wholesale via lineUserId, guest retail, LINE VIP via personal token URL), each with its own identifying input. It also differentiates from siblings by naming get_catalog (for ordering availability and item shapes) and register_customer (for customerKey), so an agent can tell which tool starts which flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit selection rules per mode: use lineUserId for registered VIPs, customerName/phone/items/address/email for guests, vipItems alone when connected through a personal token URL. It goes further with a procedural rule — "Call with dryRun: true first, show the user the lines and the estimate, and place the order only after the user confirms" — which is exactly the when-and-how guidance an agent needs before a mutating call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains where a lost customerKey can be found: a key issued with an order is written in the order confirmation email sent to the registered address (each order placed without a key has its own key). For keys that cannot be found there, it points to contact_gyotak. This tool does not look up, verify or send anything.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number used at registration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world, and the description reinforces this by stating it performs no lookup, verification, or sending — useful context that removes any expectation of a side effect. It leaves one behavioral question open: why a phone number is required if nothing is looked up, which matters for a tool that takes a personal identifier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: what it explains first, the fallback routing second, the negative scope last. Zero filler and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema informational tool, the description covers what the agent gets back (an explanation plus a pointer to contact_gyotak) and what it will not get (no lookup or send). The one missing piece is the purpose of the required phone argument, which the description neither explains nor acknowledges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the phone parameter is already documented as 'Phone number used at registration'; baseline is 3. The description adds no meaning about how the phone is used — and its claim of 'does not look up anything' makes the required identifier's role genuinely unclear rather than merely redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb and resource are stated: the tool explains where a lost customerKey lives (order confirmation email to the registered address, per-order keys). It also pre-empts the misleading name 'recover' by declaring 'This tool does not look up, verify or send anything,' so an agent will not mistake it for a retrieval tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is clear: call when a customerKey is lost, and for keys not found in the confirmation email it routes the agent to the sibling contact_gyotak. No explicit exclusion against other plausible siblings such as get_order_history or my_orders, which might also surface order details, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register as a GYOTAK customer. Collect name, phone, address, email, and customer type (Retail or Wholesale) via conversation BEFORE calling this tool. Returns a customerKey for future orders. Save the key in your AI memory.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name (English) | |
| No | Email address (optional) | ||
| phone | Yes | Contact phone number | |
| address | Yes | Shipping address | |
| customerType | Yes | Customer type: Retail (consumer) or Wholesale (business) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare write, non-idempotent, non-destructive, closed-world; the description adds the return value ('customerKey for future orders') and an operational instruction to persist it in AI memory. It does not warn that repeated calls with the same details will create duplicates, which the non-idempotent hint implies but never explains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the precondition, then the return value, then the follow-up action. Nothing is redundant with the schema and every sentence changes agent behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter write tool with no output schema, the description covers precondition, return value and key persistence. The only gap is duplicate-registration behavior on repeat calls, which matters given idempotentHint=false.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions and an enum on customerType, so the schema does the heavy lifting. The description restates the collectable fields and the Retail/Wholesale choice but adds no new semantics such as phone format or what constitutes a valid shipping address.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb and resource ('Register as a GYOTAK customer') and immediately distinguishes itself from the recovery path by stating it returns a new customerKey. It also names the exact field set, so an agent knows precisely what this tool produces versus asking about existing accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the precondition: gather name, phone, address, email and customer type through conversation BEFORE calling. It does not name sibling alternatives (e.g. recover_customer_key for an existing customer), so the exclusion half of the guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Email the GYOTAK referrer a link to the form where they register where their commission should be sent: a Thai PromptPay QR (read inside the form, the image is never uploaded) or a stablecoin address (USDC on Base, or USDM on Cardano). Call this when the user wants to register, see, or change their payout destination. Returns the destination currently on file, masked, and the masked address the link was sent to. For security the form URL is never shown in the chat — the link goes only to the email address on file, so tell the user to open it from their email. Never ask the user to type the number or the wallet address into the chat.
| Name | Required | Description | Default |
|---|---|---|---|
| customerKey | No | Your customerKey (gyotak_cus_...). Omit when connected through a personal token URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial value beyond the annotations: it discloses that an email is actually sent, that the form URL is deliberately withheld from chat, that the destination is read inside the form (image never uploaded), and that returns are masked. It doesn't explain the destructiveHint=true surface (e.g., whether calling again overwrites or resends) or any rate limits, which keeps it below top marks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and destination options are front-loaded, and the rest is procedural safety guidance that earns its place. It is dense and runs long, but no sentence is filler; a light trim of the parenthetical detail would tighten it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by describing the return values (masked destination on file and masked address the link went to) and by explaining the security model and what the agent must tell the user. An agent can invoke and follow up correctly without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter customerKey is fully documented in the schema (100% coverage), including the personal-token-URL omission case. The description adds nothing about the parameter, so the schema carries all the weight, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource (email the referrer a link to the payout-registration form) and enumerates the two destinations it covers (Thai PromptPay QR, stablecoin USDC on Base / USDM on Cardano). This is clearly distinct from siblings like register_customer or my_referrals, which deal with identity and referral listing rather than payout destination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: 'Call this when the user wants to register, see, or change their payout destination,' covering read and write intents. It does not name any sibling alternative or exclusion, but no sibling appears to overlap this domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search fish by name (Japanese, Thai, or English). Provide lineUserId to include VIP tier pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Fish name to search for | |
| lineUserId | No | LINE user ID for VIP pricing (optional) |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| vipCompanyName | No | Shown as (VIP: …) when VIP pricing is applied |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts: matching works across Japanese, Thai and English names, and supplying lineUserId changes what pricing tier is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler, and the core capability is front-loaded before the optional-pricing hint. Nothing repeats gratuitously.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich annotation set, full schema coverage and an output schema, the definition covers what matters at this complexity. It stops short of saying whether matching is exact or partial, which would help an agent form queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented, and the description largely restates them. The one added nuance is that lineUserId affects VIP pricing in the response, which is roughly already implied by the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (search fish) and adds the searchable name languages. It does not distinguish itself from the closest sibling, get_catalog, so an agent must infer which to reach for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name-search framing, and the lineUserId tip hints at a VIP-pricing variant of the call. There is no explicit when-to-use statement, no exclusion of alternatives like get_catalog, and no prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a GYOTAK catch record DIRECTLY from the Midnight blockchain. Reads on-chain state and returns the raw hex plus decoded fields for independent verification. Unlike get_catch_reports (GYOTAK's own list of records: date, district and verify links, never GPS), this lets you verify without trusting GYOTAK. The exact position is not on the chain (only a commitment to it). The region name is a label set by GYOTAK. GYOTAK checks the region range when recording, but the range used is not part of the record, so a third party cannot confirm it from the chain. Supports both preprod and mainnet. batchId also accepts several IDs separated by commas: they are all checked against a single fetch of the contract state, and the response lists found/not-found per ID.
| Name | Required | Description | Default |
|---|---|---|---|
| batchId | No | Filter to a specific catch record by batchId (e.g. "CR-20261021-37b2b7be"). Omit to return all records in the contract. | |
| network | No | Midnight network (default: mainnet) | |
| contractAddress | Yes | Midnight contract address (64-char hex). Example: bc33d8c05852decd4ef183201a8a9f3c25eabaa46a81786f306b95397ed118ab |
| Name | Required | Description |
|---|---|---|
| error | No | Same text as content when the input or the lookup failed |
| found | No | |
| source | No | Where the on-chain state was read from |
| message | No | Same text as content when there is nothing to show |
| records | No | All catch records (no batchId given) |
| results | No | Several batch IDs |
| raw_state | No | |
| match_type | No | |
| occurrences | No | |
| verify_urls | No | |
| match_offsets | No | |
| batchId_queried | No | |
| gps_recoverable | No | |
| customer_summary | No | |
| raw_state_sha256 | No | |
| tentative_records | No | |
| verification_note | No | |
| presentation_guidance | No | |
| raw_state_length_bytes | No | |
| tentative_records_note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds substantial context beyond them: the position is only a commitment on-chain, the region name is a GYOTAK-set label, the range is not part of the record, and both preprod and mainnet are supported. These are exactly the trust caveats an agent needs before reporting results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and the sibling contrast, and every caveat sentence carries operational weight. It is dense, with the batchId comma behavior tucked at the end, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 not be explained, and the description covers the remaining gaps: trust model, network support, multi-ID batching, and the limits of what the chain can prove. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by explaining that batchId accepts several comma-separated IDs checked against a single contract-state fetch with per-ID found/not-found results. That behavior is not conveyed by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Verify a GYOTAK catch record DIRECTLY from the Midnight blockchain') and explicitly distinguishes itself from the sibling get_catch_reports by naming it and its limitations. An agent can tell verify_catch apart from verify_komon/verify_purchase without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the alternative (get_catch_reports) and the exact condition that selects this tool: verifying without trusting GYOTAK. It also spells out what cannot be verified from chain (exact position, region range), which tells the agent when this tool will not satisfy a request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a GYOTAK KOMON record directly from the Midnight blockchain. Reads on-chain state and returns the raw hex plus decoded fields for independent verification. Unlike get_komon_records (which returns GYOTAK's database), this reads directly from the chain. Shielded records do not put the GPS coordinates on the chain, only a hash of them (gpsHash); the region is a label set by GYOTAK. GYOTAK checks the region range when recording, but the range used is not stored in the record, so the region cannot be confirmed from the chain. Currently preprod only.
| Name | Required | Description | Default |
|---|---|---|---|
| komonId | No | Filter to a specific komon record by ID. Omit to return all records. | |
| network | No | Midnight network (default: preprod) | |
| contractAddress | No | Midnight komon contract address (64-char hex) |
| Name | Required | Description |
|---|---|---|
| error | No | Same text as content when the input or the lookup failed |
| source | No | Where the on-chain state was read from |
| message | No | Same text as content when there is nothing to show |
| records | No | |
| raw_state | No | |
| gps_recoverable | No | |
| availableKomonIds | No | Listed when no record matched komonId |
| verification_note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing what the chain actually contains: shielded records store only gpsHash, not coordinates, and the region is a GYOTAK-side label whose range is not persisted, so it cannot be confirmed on-chain. Also flags the preprod-only limitation and what is returned (raw hex plus decoded fields). This is exactly the kind of trust-boundary context an agent needs before reporting a 'verification' result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and the sibling differentiation before the caveats, and every sentence carries substantive information. Slightly dense in the middle (gpsHash/region explanation runs long), but no sentence is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still characterizes the return shape ('raw hex plus decoded fields'), and it covers the critical semantic caveats about shielded records and unverifiable regions. For a read-only verification tool with full schema coverage, nothing an agent needs to interpret results correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented, warranting the baseline 3. The description adds only an implicit note that the record is fetched from chain state and that mainnet is not yet available, without elaborating on komonId filtering, contractAddress format, or the mainnet enum value the schema still exposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Verify a GYOTAK KOMON record directly from the Midnight blockchain') and explicitly contrasts scope with the sibling get_komon_records ('which returns GYOTAK's database'). An agent can distinguish the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the alternative (get_komon_records) and the condition that selects this tool ('for independent verification', reads directly from chain). Adds the environmental constraint 'Currently preprod only', which further scopes usage. Lacks an explicit statement of when NOT to use it beyond the sibling contrast, so not quite a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a purchase proof and trace it: purchase → catch → storage temperature. Use this when the customer asks to see what they bought, where it was caught or how it was stored. Pass the customerKey from this conversation, or a purchase ID (PB-…). Read-only; returns only stamped (on-chain) proofs, with the arguments for verify_catch and verify_temp.
| Name | Required | Description | Default |
|---|---|---|---|
| purchaseId | No | Purchase ID (PB-YYYYMMDD-xxxxxxxx). Takes precedence over customerKey. | |
| customerKey | No | Your customerKey (gyotak_cus_...). Omit when connected through a personal token URL. |
| Name | Required | Description |
|---|---|---|
| error | No | Same text as content when the input or the lookup failed |
| message | No | Same text as content when there is nothing to show |
| pending_stamp | No | Proofs of this customer still waiting to be stamped |
| older_not_shown | No | Older proofs not shown |
| purchase_proofs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and non-destructive behavior, so the description's real contribution is that only stamped (on-chain) proofs are returned — an important data-completeness caveat an agent would otherwise not know. It also discloses the chaining output (arguments for verify_catch/verify_temp), which the output schema alone may not make obvious in intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the trace chain and the when-to-use condition front-loaded ahead of the parameter hint. Every clause carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Coverage is strong: an output schema exists so return values need no explanation, parameters are addressed, and the chaining contract is stated. The one unaddressed case is what happens when a customerKey maps to multiple purchases (which proof is shown) and what occurs when no stamped proof exists — both relevant for a zero-required-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are fully documented, so the baseline is 3. The description restates the mutual alternative (customerKey from this conversation, or a PB-… purchase ID) but does not add the precedence rule or format detail that the schema already supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Show a purchase proof and trace it') and spells out the trace chain (purchase → catch → storage temperature). It is clearly separable from siblings like verify_catch, verify_temp and claim_purchase_proof because it describes itself as returning the arguments for those deeper tools rather than doing the same job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger conditions tied to customer questions ('what they bought, where it was caught or how it was stored'), which is more than most definitions offer. It also implies the escalation path by naming verify_catch and verify_temp, though it never explicitly says when to prefer them over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify GYOTAK cold-chain storage temperatures DIRECTLY from the Midnight blockchain. Reads on-chain state and returns decoded hourly temperature records per freezer for independent verification. Unlike the dashboard (which reads from GYOTAK's D1 database), this lets you verify without trusting GYOTAK. Each value is the HOURLY AVERAGE committed on-chain; it does not prove the temperature stayed within any limit at every moment in that hour. Supports both preprod and mainnet.
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Midnight network (default: mainnet) | |
| freezerId | No | Filter to a specific freezer by ID. Omit to return all freezers. | |
| hourStartUtc | No | Filter to a specific hour (e.g. "2026-07-09 11:00:00"). Omit to return all hours. | |
| contractAddress | No | Midnight temp-log contract address (64-char hex). Default: mainnet production contract. |
| Name | Required | Description |
|---|---|---|
| error | No | Same text as content when the input or the lookup failed |
| source | No | Where the on-chain state was read from |
| message | No | Same text as content when there is nothing to show |
| freezers | No | |
| total_records | No | |
| verification_note | No | |
| availableFreezerIds | No | Listed when the filter matched nothing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, idempotent, non-destructive, open-world profile, so the description is free to add the context that matters: it returns decoded hourly temperature records per freezer, it discloses the important limitation that each value is an hourly average and does not prove limits were met at every instant, and it notes preprod/mainnet support. That limitation is material behavioral information an agent could not infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and trust-model differentiator are front-loaded in the first two sentences, followed by the output semantics and the averaging caveat. Every sentence carries non-redundant information; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 still supplies the trust model, the data granularity caveat, and network scope for a zero-required-parameter read tool. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains network, freezerId, hourStartUtc, and contractAddress. The description adds only a light gloss ('returns decoded hourly temperature records per freezer' and 'Supports both preprod and mainnet'), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb, resource, and data source: verify temperatures read 'DIRECTLY from the Midnight blockchain.' The contrast with 'the dashboard (which reads from GYOTAK's D1 database)' pins down exactly what this tool is and is not, which is the key distinction among the verify_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear when-to-use rationale — use this when you need verification without trusting GYOTAK — and names the alternative (the dashboard/D1 path) explicitly. It does not explain when to choose this over sibling verify_* tools such as verify_catch or verify_komon, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_payment_statusconfirm_paymentcreate_paymentverify_catch3 fields changedInput schema / properties / batchId / descriptionPrevious value: -"Filter to a specific catch record by batchId (e.g. \"CR-TESTV3-INSIDE-02\"). Omit to return all records in the contract."New value: +"Filter to a specific catch record by batchId (e.g. \"CR-20261021-37b2b7be\"). Omit to return all records in the contract."Input schema / properties / contractAddress / descriptionPrevious value: -"Midnight contract address (64-char hex). Example: 2e519c349331a6aaee82a7ed31aa5e39d6a3995f6cf85ec2256c97cda9a8c302"New value: +"Midnight contract address (64-char hex). Example: bc33d8c05852decd4ef183201a8a9f3c25eabaa46a81786f306b95397ed118ab"Input schema / properties / network / descriptionPrevious value: -"Midnight network (default: preprod)"New value: +"Midnight network (default: mainnet)"get_catalog1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "catalog": {
+ "description": "Used by the catalog widget (on-chain provenance per item)",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "customerContext": {
+ "description": "Used by the catalog widget",
+ "type": "object"
+ },
+ "items": {
+ "description": "Catalog lines in the order shown (empty when no stock)",
+ "items": {
+ "description": "One line of the catalog text",
+ "properties": {
+ "bands": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "description": "Packs per weight band, as listed under 📦",
+ "type": "object"
+ },
+ "catchRecordCount": {
+ "description": "Number of catch records in the traceability line",
+ "type": "integer"
+ },
+ "catchRecords": {
+ "description": "Up to 3 catch records as listed",
+ "items": {
+ "properties": {
+ "blogUrl": {
+ "type": "string"
+ },
+ "location": {
+ "type": "string"
+ },
+ "photoAt": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "photoAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "days": {
+ "description": "Days tier shown next to the tier (LINE VIP order-page catalog only)",
+ "type": "integer"
+ },
+ "fishName": {
+ "type": "string"
+ },
+ "label": {
+ "description": "Card label shown in parentheses (LINE VIP order-page catalog only)",
+ "type": "string"
+ },
+ "onchain": {
+ "description": "Midnight on-chain links as listed",
+ "items": {
+ "properties": {
+ "moreRecords": {
+ "type": "integer"
+ },
+ "network": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "network",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "orderAs": {
+ "description": "Status and tier to pass to place_order, as shown after →",
+ "properties": {
+ "status": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "tier"
+ ],
+ "type": "object"
+ },
+ "orderUpToKg": {
+ "description": "Shown as \"order up to …kg\"; 0 when shown as \"cannot be ordered by kg right now\"",
+ "type": "number"
+ },
+ "packs": {
+ "description": "Stock packs as shown",
+ "type": "integer"
+ },
+ "preferred": {
+ "description": "true when marked ★ (preferred fish)",
+ "type": "boolean"
+ },
+ "priceOnRequest": {
+ "description": "true when the line shows \"price on request\"",
+ "type": "boolean"
+ },
+ "priceThbPerKg": {
+ "description": "Price shown for this line (THB/kg). Retail for anonymous callers, the customer's own price when vip is present",
+ "type": "number"
+ },
+ "section": {
+ "description": "Section heading (LINE VIP order-page catalog only)",
+ "type": "string"
+ },
+ "status": {
+ "description": "Cut / preparation as shown",
+ "type": "string"
+ },
+ "thaiName": {
+ "type": "string"
+ },
+ "tier": {
+ "description": "Fresh / Tier1 / Tier2, or \"all\" for lines listed as [all tiers]",
+ "type": "string"
+ },
+ "weightKg": {
+ "description": "Stock weight as shown (kg, one decimal)",
+ "type": "number"
+ }
+ },
+ "required": [
+ "fishName",
+ "weightKg"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextActions": {
+ "description": "Used by the catalog widget (buttons)",
+ "type": "array"
+ },
+ "vip": {
+ "description": "Customer line shown for a registered customer",
+ "properties": {
+ "cashbackLimitThb": {
+ "type": "number"
+ },
+ "cashbackRemainingThb": {
+ "type": "number"
+ },
+ "companyName": {
+ "type": "string"
+ },
+ "orderMode": {
+ "description": "LINE VIP order-page catalog: catalog browsing only / order from the LINE VIP order page / order in this chat",
+ "enum": [
+ "view_only",
+ "line_order_page",
+ "chat"
+ ],
+ "type": "string"
+ },
+ "shippingZone": {
+ "description": "\"0\" = local (free), otherwise the zone number shown",
+ "type": "string"
+ },
+ "tierPricing": {
+ "description": "true when shown as \"tier pricing applied\"",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "companyName"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "items"
+ ],
+ "type": "object"
+}get_catch_reports1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Present when only the most recent records are shown",
+ "type": "integer"
+ },
+ "reports": {
+ "items": {
+ "properties": {
+ "blogUrl": {
+ "type": "string"
+ },
+ "createdAt": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "location": {
+ "description": "District name (or \"Unknown\")",
+ "type": "string"
+ },
+ "onchain": {
+ "items": {
+ "properties": {
+ "batchId": {
+ "type": "string"
+ },
+ "scheme": {
+ "enum": [
+ "v3",
+ "legacy",
+ "out_of_scope"
+ ],
+ "type": "string"
+ },
+ "verifyUrl": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "batchId",
+ "scheme"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "date",
+ "createdAt",
+ "location",
+ "onchain"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "verifyCatchContract": {
+ "description": "Arguments for verify_catch on v3 records",
+ "properties": {
+ "contractAddress": {
+ "type": "string"
+ },
+ "network": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "network",
+ "contractAddress"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "count",
+ "reports"
+ ],
+ "type": "object"
+}search_fish1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "query": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "properties": {
+ "fishName": {
+ "type": "string"
+ },
+ "packs": {
+ "type": "integer"
+ },
+ "priceThbPerKg": {
+ "description": "VIP price (only shown for VIP callers)",
+ "type": "number"
+ },
+ "status": {
+ "type": "string"
+ },
+ "thaiName": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "string"
+ },
+ "weightKg": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "fishName",
+ "tier",
+ "status",
+ "weightKg",
+ "packs"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "vipCompanyName": {
+ "description": "Shown as (VIP: …) when VIP pricing is applied",
+ "type": "string"
+ }
+ },
+ "required": [
+ "query",
+ "results"
+ ],
+ "type": "object"
+}verify_catch1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "batchId_queried": {
+ "type": "string"
+ },
+ "customer_summary": {
+ "type": "string"
+ },
+ "error": {
+ "description": "Same text as content when the input or the lookup failed",
+ "type": "string"
+ },
+ "found": {
+ "type": "boolean"
+ },
+ "gps_recoverable": {
+ "type": "boolean"
+ },
+ "match_offsets": {
+ "items": {
+ "properties": {
+ "offset": {
+ "type": "integer"
+ },
+ "window_hex": {
+ "type": "string"
+ },
+ "window_start": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "match_type": {
+ "type": "string"
+ },
+ "message": {
+ "description": "Same text as content when there is nothing to show",
+ "type": "string"
+ },
+ "occurrences": {
+ "type": "integer"
+ },
+ "presentation_guidance": {
+ "type": "string"
+ },
+ "raw_state": {
+ "type": "string"
+ },
+ "raw_state_length_bytes": {
+ "type": "integer"
+ },
+ "raw_state_sha256": {
+ "type": "string"
+ },
+ "records": {
+ "description": "All catch records (no batchId given)",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "results": {
+ "description": "Several batch IDs",
+ "items": {
+ "properties": {
+ "batch_id": {
+ "type": "string"
+ },
+ "decoded": {
+ "type": "object"
+ },
+ "found": {
+ "type": "boolean"
+ },
+ "offsets": {
+ "items": {
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ "window_hex": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "batch_id",
+ "found"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source": {
+ "description": "Where the on-chain state was read from",
+ "properties": {
+ "block_height": {
+ "type": "integer"
+ },
+ "contract_address": {
+ "type": "string"
+ },
+ "indexer_url": {
+ "type": "string"
+ },
+ "network": {
+ "type": "string"
+ },
+ "tx_hash": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "indexer_url",
+ "contract_address",
+ "network"
+ ],
+ "type": "object"
+ },
+ "tentative_records": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "tentative_records_note": {
+ "type": "string"
+ },
+ "verification_note": {
+ "type": "string"
+ },
+ "verify_urls": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+}verify_komon1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "availableKomonIds": {
+ "description": "Listed when no record matched komonId",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "error": {
+ "description": "Same text as content when the input or the lookup failed",
+ "type": "string"
+ },
+ "gps_recoverable": {
+ "type": "boolean"
+ },
+ "message": {
+ "description": "Same text as content when there is nothing to show",
+ "type": "string"
+ },
+ "raw_state": {
+ "type": "string"
+ },
+ "records": {
+ "items": {
+ "properties": {
+ "committedAt": {
+ "type": "number"
+ },
+ "gpsHash": {
+ "type": "string"
+ },
+ "komonCommit": {
+ "type": "string"
+ },
+ "komonId": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lng": {
+ "type": "number"
+ },
+ "photoHash": {
+ "type": "string"
+ },
+ "privacyMode": {
+ "type": "string"
+ },
+ "region": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "komonId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source": {
+ "description": "Where the on-chain state was read from",
+ "properties": {
+ "block_height": {
+ "type": "integer"
+ },
+ "contract_address": {
+ "type": "string"
+ },
+ "indexer_url": {
+ "type": "string"
+ },
+ "network": {
+ "type": "string"
+ },
+ "tx_hash": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "indexer_url",
+ "contract_address",
+ "network"
+ ],
+ "type": "object"
+ },
+ "verification_note": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}verify_purchase1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "error": {
+ "description": "Same text as content when the input or the lookup failed",
+ "type": "string"
+ },
+ "message": {
+ "description": "Same text as content when there is nothing to show",
+ "type": "string"
+ },
+ "older_not_shown": {
+ "description": "Older proofs not shown",
+ "type": "integer"
+ },
+ "pending_stamp": {
+ "description": "Proofs of this customer still waiting to be stamped",
+ "type": "integer"
+ },
+ "purchase_proofs": {
+ "items": {
+ "description": "Purchase proof traced to catch and storage",
+ "properties": {
+ "contract_address": {
+ "type": "string"
+ },
+ "corrected": {
+ "type": "boolean"
+ },
+ "items": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "lots": {
+ "items": {
+ "properties": {
+ "area": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "catch_batches": {
+ "items": {
+ "properties": {
+ "batch_id": {
+ "type": "string"
+ },
+ "verify_catch": {
+ "properties": {
+ "batchId": {
+ "type": "string"
+ },
+ "contractAddress": {
+ "type": "string"
+ },
+ "network": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "verify_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "batch_id",
+ "verify_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "catch_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "catch_report_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fish": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "fish_of_the_day": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "missing_reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "storage_average_c": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "network": {
+ "type": "string"
+ },
+ "notes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "order_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "purchase_id": {
+ "type": "string"
+ },
+ "storage": {
+ "properties": {
+ "average_c": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "missing_reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "note": {
+ "type": "string"
+ },
+ "stays": {
+ "items": {
+ "properties": {
+ "freezer_id": {
+ "type": "integer"
+ },
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "verify_temp": {
+ "items": {
+ "properties": {
+ "freezerId": {
+ "type": "integer"
+ },
+ "hourStartUtc": {
+ "type": "string"
+ },
+ "network": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "test_customer_order": {
+ "type": "boolean"
+ },
+ "verify_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "purchase_id",
+ "network",
+ "verify_url",
+ "items",
+ "lots",
+ "storage"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}verify_temp1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "availableFreezerIds": {
+ "description": "Listed when the filter matched nothing",
+ "items": {
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ "error": {
+ "description": "Same text as content when the input or the lookup failed",
+ "type": "string"
+ },
+ "freezers": {
+ "items": {
+ "properties": {
+ "freezerId": {
+ "type": "integer"
+ },
+ "records": {
+ "items": {
+ "properties": {
+ "avgTempC": {
+ "type": "number"
+ },
+ "hourStartUtc": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hourStartUtc",
+ "avgTempC"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "freezerId",
+ "records"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "message": {
+ "description": "Same text as content when there is nothing to show",
+ "type": "string"
+ },
+ "source": {
+ "description": "Where the on-chain state was read from",
+ "properties": {
+ "block_height": {
+ "type": "integer"
+ },
+ "contract_address": {
+ "type": "string"
+ },
+ "indexer_url": {
+ "type": "string"
+ },
+ "network": {
+ "type": "string"
+ },
+ "tx_hash": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "indexer_url",
+ "contract_address",
+ "network"
+ ],
+ "type": "object"
+ },
+ "total_records": {
+ "type": "integer"
+ },
+ "verification_note": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}my_ordersplace_order1 field changedInput schema / properties / vipItems / items / properties / kg / descriptionPrevious value: -"Kilograms in steps of 0.5 — only for items ordered by kg"New value: +"Kilograms in steps of 0.5, or exactly the stock shown — only for items ordered by kg"place_order2 fields changedInput schema / properties / dryRunAdded value: +{
+ "description": "(LINE VIP mode only) true = return the lines and the estimated total without placing the order",
+ "type": "boolean"
+}Input schema / properties / vipItemsAdded value: +{
+ "description": "(LINE VIP mode only) Order lines for a LINE VIP customer connected through a personal token URL. Ignored in other modes.",
+ "items": {
+ "properties": {
+ "bands": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "Packs per weight band, e.g. {\"140-180g\": 3} — only for items get_catalog marks as ordered by bands",
+ "type": "object"
+ },
+ "fishName": {
+ "type": "string"
+ },
+ "kg": {
+ "description": "Kilograms in steps of 0.5 — only for items ordered by kg",
+ "type": "number"
+ },
+ "packs": {
+ "description": "Total packs — only for items ordered by packs",
+ "type": "number"
+ },
+ "status": {
+ "description": "As shown in get_catalog for this item",
+ "type": "string"
+ },
+ "tier": {
+ "description": "As shown in get_catalog (All for cooking, prepared and whole cooking items)",
+ "enum": [
+ "Fresh",
+ "Tier1",
+ "Tier2",
+ "All"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "fishName",
+ "status",
+ "tier"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}verify_purchaseclaim_purchase_proof2 fields changedInput schema / properties / handle / descriptionPrevious value: -"Your X handle without the leading @ (letters, digits and underscore, 1-15 characters). Required to claim: a call without it only lists your purchases and claims nothing, even if you claimed before. Pass it on every claim."New value: +"Your X handle without the leading @ (letters, digits and underscore, 1-15 characters). Required to link: a call without it only lists your purchases and links nothing, even if you linked before. Pass it on every link."Input schema / properties / purchase_id / descriptionPrevious value: -"Claim only this purchase (e.g. \"PB-20260917-a97953d3\"). Omit to claim every purchase of yours that is not claimed yet."New value: +"Link only this purchase (e.g. \"PB-20260917-a97953d3\"). Omit to link every purchase of yours that is not linked yet."confirm_payment1 field changedInput schema / properties / customer_key / descriptionPrevious value: -"Your customer key (from register_customer)"New value: +"customerKey of the test customer that placed the order"claim_purchase_proof2 fields changedInput schema / properties / auto_bindAdded value: +{
+ "description": "Turn automatic binding of future purchases to your X handle on or off. \"on\" needs handle and consent. \"off\" needs nothing else. Omit to leave the setting as it is.",
+ "enum": [
+ "on",
+ "off"
+ ],
+ "type": "string"
+}Input schema / properties / consentAdded value: +{
+ "description": "Set true only when the user has read the consent text returned by an earlier auto_bind \"on\" call and agreed to it. Never set it on your own.",
+ "type": "boolean"
+}claim_purchase_proof2 fields changedInput schema / properties / auto_bindRemoved value: -{
- "description": "Turn automatic binding of future purchases to your X handle on or off. \"on\" needs handle and consent. \"off\" needs nothing else. Omit to leave the setting as it is.",
- "enum": [
- "on",
- "off"
- ],
- "type": "string"
-}Input schema / properties / consentRemoved value: -{
- "description": "Set true only when the user has read the consent text returned by an earlier auto_bind \"on\" call and agreed to it. Never set it on your own.",
- "type": "boolean"
-}AI-readable directory + commerce layer: 3,500+ SEA businesses, plus products from verified stores.
Free read-only crypto whale-tracking & market-data MCP tools across 14 chains. No auth.
AI-powered organic supply chain verification: certification, OFAC, FDA import checks.
A2A + MCP hub for retail grocery procurement — 20 markets on the SCHEMA algo record. Trade only.
Add one secure layer between your agents and this server.
