GYOTAK Fish Market

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

With no annotations to rely on, the description carries the behavioral disclosure burden. It explains that the URL is automatically issued after first payment confirmation, that calling the tool can issue a missing URL, and that referrers earn 5% on paid orders. It does not explicitly state what happens when the user has no paid order, but the conditional side effect is clearly disclosed.

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 description is front-loaded with the primary purpose and each sentence adds useful context around issuance, commission, and parameter behavior. The phrase 'call this to see it again' is slightly redundant with 'look up,' but overall the description is efficient and well-structured.

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?

The description covers the main outcome, conditional issuance, commission, and a parameter caveat, but it leaves one important gap: it never explicitly states that a paid order is a prerequisite or what happens if the caller has never had one. Since there is no output schema, and the annotations provide no safety/side-effect context, this missing eligibility detail keeps it from being fully complete.

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 input schema already describes all three optional parameters in full, including the customerKey omission rule and the default for name. The description's mention of omitting customerKey repeats schema guidance rather than adding new parameter-level meaning, so the high schema coverage keeps this at the baseline.

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 opens with a specific verb and resource: 'Look up your GYOTAK referral MCP URL.' It clearly distinguishes the tool's purpose from sibling payment, order, and catalog tools, making its function immediately identifiable without restating the tool name.

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 description gives clear context for when to call the tool: to re-view an already issued URL or to have one issued if a paid order exists but no URL is present. It also provides a conditional usage rule (omit customerKey for personal token URLs), though it does not explicitly name alternative sibling tools or say when not to use it.

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

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

With no annotations, the description carries the full burden, and it does well by disclosing that it returns top matching FAQ entries and suggests contact_gyotak on no match. The read-only nature is implied by 'Search' but not made explicit; still, the success and fallback behaviors are clearly stated.

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 with no wasted words: the main action is front-loaded, followed by return behavior and the fallback instruction. Every sentence contributes to the agent's understanding.

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 FAQ lookup with full schema coverage, the description covers the core invocation, return type ('top matching FAQ entries'), and the no-match path. The lack of an output schema is partially mitigated by the return description, though exact formatting or count of matches is left unspecified.

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 already describes 'question' as 'Question text (any language)', so the baseline applies. The description's topic list adds context about content areas but not about the parameter's format or constraints beyond what the schema provides.

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 uses a specific verb and resource ('Search GYOTAK FAQ') and lists concrete topic areas, making the tool's purpose immediately clear. It also explicitly contrasts with contact_gyotak by funneling no-match cases to that sibling, which sharpens differentiation.

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 description gives clear context: use this tool for FAQ lookup on the listed topics. It explicitly names contact_gyotak as the escalation alternative when no match is found. However, it does not distinguish from other search-oriented siblings like search_fish, leaving some when-to-use guidance implicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses exactly what the tool returns (status, amount, deadline, TX hash if paid), what happens for other order_ids (returns PromptPay guidance and nothing about the order), and the payment/confirmation flow. This is a transparent read-only description with no hidden side effects.

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 sentences, each essential: a warning, the return payload, and the fallback behavior/payment context. No fluff or redundant phrasing.

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 read-only tool with no output schema and no annotations, the description is complete: it tells what it returns, when to use it, when not to, and the payment context. Nothing an agent needs for correct invocation 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% for order_id, so the baseline is 3, but the description adds significant meaning: it specifies that only orders from GYOTAK test customers are valid, and that any other order_id yields PromptPay guidance instead of order data. This clarifies the parameter's domain and edge-case behavior beyond 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?

The description states a specific verb ('Returns') and resource ('Cardano preprod payment session'), and restricts it to orders placed by a GYOTAK test customer. It also clarifies the tool's scope is test/QA only, distinguishing it from sibling payment tools like confirm_payment or create_payment.

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 description explicitly forbids use for customer orders ('Test / QA only — do not use for customer orders'), giving a clear when-not condition. It also describes behavior for any other order_id, which implicitly tells agents that the tool is only meaningful for test customer orders.

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

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

No annotations are provided, so the description carries the burden of signaling side effects. The verb 'Check' implies a read-only, non-destructive operation, which is useful. However, it does not disclose the return shape, idempotency, or any authentication/rate-limit implications, leaving some behavioral ambiguity.

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, direct sentence with no filler. The action and target are front-loaded, making it immediately scannable for an agent.

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 one fully documented parameter and no output schema, the description covers the invocation trigger (previously submitted inquiry) but does not clarify the tool's return value (e.g., boolean vs. reply content). This is the main completeness gap, though the tool is simple enough that an agent can still infer basic usage.

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 input schema already fully documents inquiryId with type and example, so schema coverage is 100%. The description adds only the context that the inquiry was previously submitted; no additional parameter semantics are necessary or provided.

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 uses a specific action ('Check') and a concrete resource ('GYOTAK staff reply to a previously submitted inquiry'). It clearly distinguishes this tool from siblings like ask_gyotak (submission) and check_payment_status (payment), even without naming alternatives.

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 description situates the tool in a clear workflow: after an inquiry has been submitted, check whether staff has replied. It does not explicitly name alternatives or exclusions, but the 'previously submitted inquiry' context is unambiguous and provides enough guidance for an agent to know when to invoke it.

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

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

With no annotations, the description carries the full burden and does so: it discloses the on-chain irreversibility of a link, that no customerKey argument exists, that the buyer's X account is self-declared and unverified by GYOTAK, that auto-binding is off by default, and that 'off' does not retroactively remove recorded links. This is exactly the behavioral context an agent needs before mutating state.

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 almost every clause carries operational information. It is somewhat long and the buyer's-X-account disclaimer sits awkwardly mid-paragraph rather than with the other behavioral caveats, but there is little pure 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?

There is no output schema and no annotations, and the description compensates well: it explains what a listing-only call returns, that stamped purchases carry a public verification URL, and that the first auto_bind 'on' call returns consent text to be shown verbatim in both Japanese and English. Given the tool's complexity, an agent has enough to invoke it safely.

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 cross-parameter semantics the schema does not: handle must be re-passed on every link call, auto_bind 'off' needs no handle, and consent must only be set after the returned consent text is shown to the user. It does not, however, document the purchase_id format expectation beyond the schema example.

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 first sentence states a specific verb and resource — linking the caller's own on-chain purchase proofs to their X account so a post can be verified against the chain. This is clearly distinct from the verification/listing siblings (verify_catch, get_order_history), and the scope ('your own purchases') is explicit.

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 description explicitly routes behavior: a no-argument call only lists linkable purchases and links nothing 'every time', handle must be passed to actually link, and auto_bind requires a specific two-call consent sequence. It also warns the agent to let the user choose the handle first because the link is irreversible.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that it executes a settlement (a mutating action) and that for non-test orders it returns guidance without changing anything. It also mentions prerequisites that may affect behavior (pending payment session, allowance). This goes beyond simply stating the action and provides useful context about side effects and network (preprod). However, it doesn't explicitly state whether the settlement is reversible or what exactly happens to the order after settlement, leaving some ambiguity.

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 description is concise and well-structured, with the most critical information ('Test / QA only — do not use for customer orders') front-loaded. Every sentence adds necessary context: the exclusion, the alternative payment method, the specific action, prerequisites, and the fallback behavior. No redundant words or fluff, making it efficient for an agent to parse quickly.

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?

Given the tool's moderate complexity and lack of output schema, the description covers the essential aspects: what it does, when to use it, prerequisites, and behavior for non-matching inputs. It does not explicitly describe the return value or output format, which might be important for an agent to know (e.g., success/failure status). However, for a test/QA tool, this might be less critical, and the description still provides sufficient context to decide whether to call it and what to expect in terms of side effects.

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 input schema already describes both parameters (order_id with example format, customer_key as the test customer's key). The description adds the requirement that customer_key must belong to a test customer, but this is already in the schema. It also mentions that the payment session must be pending, which relates to the order_id indirectly. With 100% schema coverage, the description adds marginal value beyond the schema, so the baseline of 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?

The description clearly states the tool's purpose: it executes a Cardano preprod A→B→A settlement for a test customer's order. It explicitly identifies itself as test/QA only and distinguishes itself from customer payment flows (PromptPay QR) and from sibling tools like check_payment_status or create_payment by specifying its exact action and scope. The verb 'Executes' and the resource 'Cardano preprod A→B→A settlement' are specific and unambiguous.

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 description gives explicit when-to-use guidance: only for test/QA, not for customer orders, and only when certain prerequisites are met (test customer's customerKey, pending payment session from create_payment, monthly auto-settle allowance). It also states the behavior for non-matching order_ids (returns PromptPay guidance and changes nothing), effectively saying when not to use it. While it doesn't name a specific alternative tool, it clearly indicates the condition for use and provides a fallback behavior.

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

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

With no annotations provided, the description is the only source of behavioral context. It discloses the asynchronous workflow ('Staff will reply via Discord' and 'Use check_reply to retrieve the response later') but does not mention side effects, whether the submission is stored, or any rate/format constraints. That is partial disclosure, not full.

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 description is two concise sentences, with the action and condition front-loaded and the essential follow-up instruction immediately after. Every word contributes; there is no redundant or filler content.

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 two-parameter submission tool with no output schema, the description is largely complete: it gives the trigger, the action, and the retrieval path. It does not describe what the call returns or how to distinguish this from ask_gyotak, but these are minor gaps for such a simple 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?

Input schema coverage is 100% and each parameter already has a description. The tool description only reinforces 'question' implicitly and adds no new semantic detail about either parameter, so the schema carries the burden and the 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?

The description states a clear action ('Submit a question'), a target ('GYOTAK staff'), and a triggering condition ('when FAQ does not have the answer'). However, it does not differentiate from the sibling ask_gyotak, whose name suggests a similar action, so the agent is left to infer the 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?

Explicitly directs when to use the tool ('when FAQ does not have the answer') and points to the follow-up tool ('Use check_reply to retrieve the response later'). It stops short of naming ask_gyotak as an alternative or stating when not to use this tool, so a small guidance gap remains.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it only works for test customers, computes THB→tADA conversion, creates a preprod session with a 30-minute expiry, and creates nothing for unsupported order IDs. The side-effect boundary is clearly stated.

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 warning is front-loaded, and the two sentences pack in scope, exclusions, parameter constraints, behavior, and a time-bound expiry. Nothing is redundant.

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?

The description is complete for selection and invocation, but with no output schema it only vaguely says 'returns the payment details' and does not specify the returned fields or how they connect to siblings such as check_payment_status. Minor gap in an otherwise strong definition.

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?

Although the schema already documents order_id and provides an example, the description adds crucial parameter-level meaning: the ID must belong to a GYOTAK test customer, and any other value causes a non-creating fallback. That materially changes how an agent should treat the parameter.

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 an exact scope: a test/QA-only helper that creates a Cardano preprod payment session and returns payment details. It distinguishes itself from a production payment path by explicitly saying it is not for customer orders.

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 explicit when-to-use ('Test / QA only'), when-not-to-use ('do not use for customer orders', 'do not call it after placing a customer order'), and what happens with invalid input ('returns PromptPay guidance and creates nothing'). This leaves no ambiguity about whether the agent should select it for a real order.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that retail prices are always included, that customerKey enables wholesale pricing and one-tap checkout, and that delivery is Thailand-only. These are meaningful behavioral details beyond the tool's name and schema, though it stops short of discussing output format 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?

The description is four sentences, front-loads the primary purpose, and then adds only the essential conditional logic and delivery constraint. Every sentence contributes actionable information with no filler or repetition.

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?

Given no annotations and no output schema, the description covers the essential returns, optional parameter behavior, and a critical geographic restriction. It does not explicitly compare against search_fish or other sibling tools, but it is sufficiently complete for a read-only catalog retrieval tool with two optional parameters.

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. The description adds semantic value by clarifying which type of user should pass each optional parameter and what behavior changes when they do. This goes beyond the schema's per-parameter descriptions by linking them to customer types and checkout behavior.

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 clearly identifies a specific verb and resource: 'Get GYOTAK's full fish catalog.' It enumerates the key returned data (real-time availability, retail prices, freshness tiers, traceability records), making the tool's purpose unambiguous. The word 'full' also helps distinguish it from sibling search-oriented tools like search_fish.

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 description provides explicit guidance on when to pass customerKey vs lineUserId, and it clearly states that international delivery is not accepted. It does not explicitly name alternative sibling tools or state when to prefer search_fish, but the contextual usage instructions are clear enough for an agent to invoke the tool appropriately.

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

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

With no annotations, the description carries the full burden and does so unusually well: it discloses that exact GPS coordinates are never returned, that v3 records only carry a commitment plus a zero-knowledge range proof, and that the district name is a GYOTAK-applied label outside that proof. It also explains the Midnight blockchain verify-link trust model, which is exactly the kind of context an agent cannot 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?

Front-loaded with purpose and return fields, then the privacy caveat, then the verification route — a logical ordering. The middle sentence is dense and long (zero-knowledge proof, district labeling), but every clause conveys non-obvious information rather than 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?

With no output schema, the description usefully enumerates the returned fields and adds the privacy/trust caveats an agent needs. It stops short of covering result-set behavior: no pagination, ordering, empty-result handling, or what happens when date and tier are combined or both omitted (neither is required).

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%: the date format (YYYY-MM-DD) and the tier enum semantics (fresh=last 30 days, tier1=31-60, tier2=61-90) are already documented in the schema. The description only restates 'by date or freshness tier' and adds no syntax or interaction semantics, so the 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 catch records by date or freshness tier') and immediately enumerates what is returned (catch date, district, blog post URL, per-batch verify link). It also separates itself from the sibling verify_catch by positioning that tool as the on-chain alternative, so an agent can route 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?

Gives an explicit alternative path: 'To check a record on-chain without trusting GYOTAK, open its verify link, or call verify_catch with network "mainnet"...'. That is clear when-to-use-other guidance. It does not, however, explain when to pass date vs tier, what happens if both or neither are supplied, or how this differs from other record-retrieval siblings such as get_komon_records.

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

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

There are no annotations, so the description carries the full burden, and it succeeds. It discloses that the tool takes no arguments, returns static text, and summarizes the actual content (retail vs. B2B wholesale, LINE contact, tier pricing, application required). This makes the behavior fully transparent for a simple static-info tool.

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 description is dense but every part earns its place: purpose, key details, call triggers, argument behavior, and sibling routing. It is front-loaded with the core purpose and does not waste words on generic 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?

For a zero-argument tool returning static text, the description is complete. It covers what the tool returns, when to invoke it, what not to use it for, and which alternatives to choose. No output schema is needed because the description already tells the agent the response is static text with known 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?

The tool has zero parameters, which sets a baseline of 4. The description reinforces this by explicitly saying 'Takes no arguments,' matching the empty input schema. There is no additional parameter meaning to add because there are no 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?

The description states exactly what the tool does: returns the two ways to buy from GYOTAK with contact details. It is specific about both retail and B2B wholesale paths, which differentiates it from the listed siblings such as get_catalog, place_order, and ask_gyotak.

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 description explicitly says when to call it: when the user asks how to buy, how to open a wholesale account, or how to reach GYOTAK. It also gives clear alternatives: use get_catalog for availability/prices and ask_gyotak for other questions, so an agent knows exactly when not to use this tool.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal meaningful context: records represent PUF registrations with minutiae extraction, on-chain commitment, and shielded records do not expose GPS. However, it does not explicitly state that the operation is read-only, describe auth requirements, or clarify response behavior beyond the data model.

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 description is compact, with the first sentence clearly stating the action and resource and the second adding necessary context. There is no filler, tautology, or redundant repetition. It is appropriately front-loaded and scannable.

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?

Given the absence of an output schema, the description could do more to explain the return structure, pagination, or whether all records are returned by default. It does cover the core semantics of the records and notes GPS shielding, which is helpful. Missing usage guidance and explicit behavioral expectations keep it below a 4.

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 input schema covers the only parameter ('status') with 100% description coverage and an enum. The tool description does not add parameter-specific meaning beyond the schema, which is acceptable under the baseline when schema coverage is high. It provides helpful background about what a 'record' is, but not about the status filter itself.

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 names a specific verb ('Get'), a clear resource ('GYOTAK KOMON physical authentication records'), and a source ('the database'). It also adds useful domain context about PUF registration and on-chain commitment, making the tool's purpose understandable. It does not explicitly distinguish itself from sibling tools like get_catch_reports or verify_komon, but the resource is specific enough to avoid major ambiguity.

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 description provides no guidance on when to use this tool versus alternatives, nor does it state exclusions or prerequisites. With many sibling tools such as verify_komon and get_catch_reports, the agent is left to infer the appropriate selection without explicit routing.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses the result limit ('last 20 orders') and eligibility ('registered VIP customer'), but it does not describe return format, error behavior, or what happens when the user is not found or not eligible.

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 description is a single well-structured sentence with the core action front-loaded and the eligibility requirement stated immediately after. No unnecessary words.

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 operation with no output schema, the description covers the essential context: what is returned, the limit, and who is eligible. It omits details like return shape or failure modes, but these are less critical given the low complexity.

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 input schema already fully describes lineUserId with 100% coverage, providing a baseline of 3. The description adds extra semantic value by clarifying that the user must be a registered VIP customer and linking the parameter to B2B order history.

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: 'Get B2B order history' with a concrete constraint of 'last 20 orders'. This clearly distinguishes it from sibling tools like place_order or create_payment.

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 description gives a clear prerequisite: the caller must have a lineUserId of a registered VIP customer. This provides enough context for when the tool is applicable, though it does not explicitly mention when not to use it or name alternatives.

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

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

No annotations are provided, so the description carries the burden. It states outputs (facts, constraints, URLs) and implies a read-only operation via the verb 'get'. It also notes freshness requirements ('do not reuse'). However, it does not explicitly state side effects, authentication implications, or rate limits, leaving some ambiguity despite the 'get' implication.

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 description is a single, front-loaded sentence that efficiently lists the content types and ends with a clear usage directive. It is concise with no fluff, though it is a bit long in enumerating items. Overall, it is well-structured and to the point.

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 or annotations, so the description must stand alone. It lists the categories of returned data (order facts, photo URLs, verification URLs, claims, disclosure) but does not detail the structure or format of the response. Given the complexity of the output, this is a moderate gap, but the list provides enough orientation for an agent to use the result.

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 baseline is 3. The description mentions photo URLs and referral URL, which loosely relate to includePhotos and customerKey, but does not add new meaning beyond the schema. The schema already explains both parameters effectively, so the description provides no extra value.

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 clearly states the tool fetches facts and constraints for writing a social media post about GYOTAK, listing specific deliverables (order facts, photo URLs, verification page URLs, allowed/forbidden claims, referral disclosure). This makes it distinct from siblings like apply_referrer or report_share, which serve different purposes.

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 description explicitly instructs to call the tool each time the user asks for a post and not to reuse previous results, providing clear when-to-use guidance. It also clarifies that wording is left to the user/assistant, setting scope. However, it does not name alternative tools or give when-not-to-use conditions, but the directive is strong.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It states that the tool is read-only in nature ('Show'), explicitly scopes it to the current connection, and discloses output limitations such as 'no buyer details' and 'last 5 paid referred orders.' This gives the agent a solid understanding of what the tool will and will not do, though it does not cover error or authentication failure 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?

The description is front-loaded with the core purpose and then lists the exact components of the summary in a compact enumeration. Each clause adds specific, useful detail without filler or repetition. It is appropriately sized for the amount of information being conveyed.

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?

Given there is no output schema, the description does the necessary work of specifying what the response contains: referral URL, order counts, commission, unpaid balance, payout destination status, and last 5 paid orders. It also covers the single parameter's usage condition, making the tool fully actionable for an agent.

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 schema already documents the customerKey parameter and explicitly says to omit it when connected through a personal token URL, so the description largely repeats that guidance. The added phrase 'Only works for the customer of this connection' provides slight extra context, but the description does not meaningfully expand beyond the schema's 100% 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?

The description opens with a specific verb and resource — 'Show your referral summary as a GYOTAK referrer' — and then enumerates exactly what the tool returns (referral URL, paid/unpaid orders, commission, payout status, last 5 orders). This clearly distinguishes it from siblings like get_order_history or check_payment_status by focusing on the referrer summary rather than general orders or payments.

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 description gives clear context for when the tool is applicable: 'Only works for the customer of this connection.' It also provides a concrete parameter condition: if connected through a personal token URL, omit customerKey. It does not explicitly name alternatives or say when not to use this tool versus siblings, but the context is sufficiently clear for a self-contained summary tool.

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

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

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining mode-specific requirements, the customerKey resolution behavior, and the personal token URL shortcut. This elevates it above the baseline without needing to restate every parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Place an order' and immediately distinguishes two concrete modes (VIP wholesale and guest retail), each with its own required inputs. This makes the tool's function unmistakable and separates it from sibling tools like create_payment or check_payment_status.

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

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

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

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

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

With no annotations, the description carries the behavioral burden, and it clearly discloses that the tool has no lookup, verification, or send side effects. However, it does not explain how the required phone parameter is used or whether it influences the guidance, which is a transparency gap.

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 sentences carry the core behavior, the fallback, and the boundary with no filler. The first sentence is a bit dense with the parenthetical, but the overall structure is coherent and front-loaded.

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?

The description covers the main behavior and limitation, but there is no output schema or annotations and the role of the mandatory phone input is unexplained. An agent can select and call the tool, but it may not know what the tool does with its only input or exactly what response to expect.

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 schema already describes 'phone' as the phone number used at registration (100% coverage), so the description adds little parameter meaning. It does not connect the phone to the order confirmation email or say whether the phone shapes the explanation, which keeps this at the baseline.

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 opens with a specific verb and object: it 'explains where a lost customerKey can be found.' It also defines what the tool is not ('does not look up, verify or send anything') and names contact_gyotak as the fallback, making its role distinct from look-up and verification 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?

It states the condition for use (a lost customerKey) and gives the exact recovery path: check the order confirmation email, and if it cannot be found there, contact_gyotak. The explicit non-action statement also tells the agent not to expect verification or sending from this tool.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals that the tool returns a customerKey and instructs saving it in AI memory, which is key for future orders. It does not mention potential failure modes or duplicate registration behavior, but covers the essential workflow.

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 with no filler. The purpose, prerequisite, and return-value handling are each stated once, efficiently and in logical order.

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?

The description explains what to collect, what will be returned, and how to handle the result, which is sufficient for a registration tool with no output schema. It does not cover edge cases like validation errors or duplicate registrations, but those are not critical for basic usage.

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 description doesn't need to explain parameter meanings. The description lists the same fields as the schema and adds no new semantics beyond the conversational collection requirement.

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 clear action: 'Register as a GYOTAK customer.' It identifies the resource (customer) and differentiates itself from siblings like place_order and recover_customer_key by focusing on customer creation.

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 description explicitly tells the agent to collect all required information via conversation BEFORE calling, which gives a clear prerequisite. It does not mention alternatives like recover_customer_key for already-registered customers, so some usage context is missing.

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

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

With no annotations present, the description carries the full burden and does so well: it discloses the return value (masked destination on file plus the masked address the link was sent to), the security constraint (form URL never shown in chat, link goes only to the email on file), and an explicit behavioral instruction (never ask the user to type the number or wallet address). This is unusually rich disclosure.

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 action and usage trigger are front-loaded, and nearly every sentence carries operational value (destination types, return shape, security behavior). It is long and slightly over-explained in places, but no sentence is pure 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?

Although there is no output schema, the description explicitly states what is returned (the masked destination and the masked email address), and it covers the security constraints and user-facing instructions an agent needs. Nothing material for correct invocation 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% and the single customerKey parameter is already documented in the schema, including the 'omit when connected through a personal token URL' guidance. The description adds no parameter-level detail, 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?

The description states a specific verb and resource: it emails a link to the payout-registration form for a GYOTAK referrer's commission destination. It even enumerates the two supported destination types (Thai PromptPay QR, USDC on Base / USDM on Cardano), so an agent knows exactly what this tool accomplishes.

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 an explicit trigger: 'Call this when the user wants to register, see, or change their payout destination.' That covers the main invocation paths clearly. It does not name when-not-to-use or a competing sibling, but no sibling overlaps this payout-registration purpose.

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

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

The description discloses that GYOTAK records the report and later verifies that the post is public and contains the referral URL. Since no annotations are provided, this gives adequate transparency about the tool's behavior and follow-up.

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 description is two concise sentences, front-loading the core action and then providing essential use instructions. No redundant wording is present.

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?

The description covers what to do, when to do it, and what happens after reporting. It does not describe the response format or failure handling, but the absence of an output schema makes this acceptable.

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 schema already covers all parameters, and the description reinforces that post_url must be a public https URL and that customerKey can be omitted under certain conditions. This adds practical meaning beyond the bare field names.

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 clearly states the tool's purpose: reporting a social media post that promotes GYOTAK with a referral URL. It also distinguishes this action from related referral tools by emphasizing the post-reporting step.

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 explicitly says to call 'right after posting' and to include the platform and public URL, giving clear when-to-use guidance. It does not explicitly contrast with sibling tools like my_referrals or apply_referrer, but the timing and action are specific enough.

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

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

With no annotations provided, the description carries the full behavioral burden. It does disclose the conditional behavior that providing lineUserId includes VIP tier pricing, which is useful. However, it says nothing about read-only nature, return format, error handling, or rate limits, so transparency is moderate.

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 description is a single, front-loaded sentence covering the core action, then a second sentence addressing the optional parameter. Every word earns its place, with no filler or redundancy.

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 search tool with two parameters and no output schema, the description covers the basics. However, it omits what the search returns, does not differentiate from get_catalog, and does not state whether any authentication or prerequisites apply, leaving moderate gaps.

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. The description adds meaningful parameter context by specifying accepted language values for 'query' and explaining that 'lineUserId' modifies pricing to include VIP tiers, going beyond the schema's minimal descriptions.

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 clearly states the operation ('Search fish by name') and specifies supported languages (Japanese, Thai, English), making the tool's purpose concrete. However, it does not explicitly differentiate from sibling tools like get_catalog, which may also relate to fish data, so it falls just short of a 5.

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 description gives no guidance on when to choose this tool over alternatives such as get_catalog or other fish-related tools. It implies its use by stating what it does, but lacks exclusions or comparisons, leaving an agent to infer usage context on its own.

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

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

No annotations exist, so the description carries the full burden and does so well: it discloses that raw hex plus decoded fields are returned, that the exact position is not on-chain (only a commitment), that a ZK range proof is carried, that the region name is an off-chain label, and that comma-separated batchIds are checked against a single contract-state fetch with per-ID found/not-found 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 each subsequent sentence adds a distinct, non-redundant fact. It runs long, but no sentence is filler or restates 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 no output schema, the description compensates by describing the return content (raw hex plus decoded fields) and the shape of the multi-ID response. The proof/label caveats close the remaining interpretive gap for an agent.

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: batchId accepts several comma-separated IDs processed in one fetch with per-ID found/not-found results, and network support spans preprod and mainnet.

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 (verify) and resource (GYOTAK catch record), plus the exact source (Midnight blockchain on-chain state). It explicitly contrasts itself with the sibling get_catch_reports, so an agent can route between 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?

Explicitly names the alternative (get_catch_reports) and the condition that selects this tool instead: trustless verification without trusting GYOTAK. It also notes what the sibling returns (date, district, verify links, never GPS), making the choice concrete.

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

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

With no annotations, the description carries the full behavioral burden and does well by disclosing that it reads on-chain state, returns raw hex and decoded fields, and preserves GPS privacy via shielded records. However, the statement 'Currently preprod only' conflicts with the network parameter enum that includes mainnet, creating ambiguity about whether mainnet is usable.

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 description is compact and front-loaded with the core action and resource. Every sentence adds useful context: what it does, what it returns, how it differs from the sibling, its privacy property, and its current environment.

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 tool with no output schema and no annotations, the description adequately explains return content, source of truth, and usage distinction. The main gap is the unresolved contradiction between 'preprod only' and the network enum exposing mainnet, which prevents it from being fully unambiguous.

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 input schema has 100% parameter description coverage, so the baseline is 3. The description adds no additional parameter-level detail beyond what the schema already provides, and the 'preprod only' note slightly muddies the network parameter's documented mainnet option.

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 names a specific verb (Verify), a specific resource (GYOTAK KOMON record), and a specific source (Midnight blockchain). It also distinguishes itself from get_komon_records by clarifying that it reads on-chain state rather than GYOTAK's database, and it states the output (raw hex plus decoded fields).

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 explicitly contrasts with get_komon_records, telling the agent that this tool is for independent verification directly from the chain. It also adds a clear environmental constraint, 'Currently preprod only,' which helps the agent decide when not to use it.

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

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

With no annotations, the description carries the full safety burden and does disclose the key traits: it is 'Read-only' and returns 'only stamped (on-chain) proofs', which is a meaningful result filter an agent would otherwise not know. It does not cover error cases (e.g. unknown purchase ID, missing key) or authentication requirements beyond the key mechanics.

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 dense sentences, each earning its place: purpose and trace chain first, trigger conditions second, input and return behavior last. No filler or repetition.

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 two-parameter read tool with no output schema and no annotations, the description covers purpose, invocation triggers, input choices, and the shape of the return ('arguments for verify_catch and verify_temp'). Only failure modes and pagination/empty-result behavior are unaddressed.

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 both parameters are already documented, including the purchaseId precedence rule and the personal-token case. The description's 'Pass the customerKey from this conversation, or a purchase ID (PB-…)' largely restates that, adding only light conversational framing, so the baseline of 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?

The description states a specific verb and resource ('Show a purchase proof and trace it') and spells out the trace chain: purchase → catch → storage temperature. That chain immediately distinguishes it from the sibling verifiers verify_catch and verify_temp, so an agent can route 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?

It gives concrete trigger conditions -- 'when the customer asks to see what they bought, where it was caught or how it was stored' -- and signals the downstream relationship by mentioning verify_catch and verify_temp. It stops short of explicit when-not-to-use guidance or naming a competing tool to avoid.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It clearly states this is a read-only operation ('Reads on-chain state'), explains what the data represents (hourly averages committed on-chain), and explicitly discloses the limitation that it does not prove temperatures stayed within limits at every moment. It also notes network support (preprod and mainnet). It doesn't specify output format or error behavior, but the key behavioral caveat about hourly averages is well disclosed.

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 description is front-loaded with the core function ('Verify ... DIRECTLY from the Midnight blockchain'), followed by the key trust differentiator, the critical limitation, and network support. Every sentence earns its place: the first sentence states the purpose, the second explains why this tool exists (vs the dashboard), the third warns about what the data doesn't prove, and the fourth notes supported networks. No fluff or redundancy.

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?

Given the tool's moderate complexity (4 optional parameters, no required parameters, no output schema), the description covers the essential context: what it verifies, why it's different from the dashboard, the hourly-average limitation, and supported networks. It doesn't describe the return format or error cases, but for a read-only verification tool with heavily documented parameters, the described context is largely sufficient. The trust/verification framing is particularly valuable for agent decision-making.

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 four parameters are already described in the input schema. The tool description adds context about what the parameters filter (network, freezerId, hourStartUtc, contractAddress) by explaining the purpose of verification, but it doesn't add new parameter-level semantics beyond the schema. The baseline of 3 is appropriate because the schema does the heavy lifting and the description reinforces the verification context.

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 ('Verify'), a specific resource (GYOTAK cold-chain storage temperatures from the Midnight blockchain), and immediately distinguishes itself from the dashboard reading from GYOTAK's D1 database. It clearly explains the independent verification purpose and the hourly-average limitation, which differentiates it from sibling tools like verify_catch or verify_komon. The scope is precise: reads on-chain state and returns decoded hourly temperature records per freezer.

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 description gives explicit guidance: use this when you need independent verification without trusting GYOTAK, unlike the dashboard. It also clarifies the limitation that hourly averages do not prove continuous compliance, which is a key usage consideration. It names the alternative context (the dashboard) and explains the trust difference, giving clear when-to-use reasoning.

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