Celadon Wholesale

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 real value beyond that by enumerating the exact return payload (case size, prices, margin, ingredients, stock, link), which is important since there is no output schema; it omits error behavior for an invalid handle.

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 dense sentence with zero filler, front-loaded with the resource and immediately followed by the concrete return contents. Nothing to trim.

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-param read tool with full annotations and no output schema, the description covers what the agent needs: what identifies the product and what comes back. Missing only edge-case behavior (invalid/unknown handle, auth) that an agent might want 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?

The single 'handle' parameter has 100% schema description coverage ('Product handle from search results'), so the schema carries the semantics. The description adds nothing about handle format or sourcing beyond what the schema already says, 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 ('Full details for one wholesale product') and enumerates exactly which fields come back, which distinguishes it in substance from the search/list siblings. It stops short of naming the sibling it replaces, so an agent must infer the search-then-get pairing.

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 only implied: 'one wholesale product' and the schema note 'Product handle from search results' hint at the search→detail workflow, but the description never says when to call this instead of search_wholesale_products or quote_wholesale_order. No exclusions or prerequisites are stated.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without prose. The description adds value by disclosing the breadth of the returned policy set, including the unusual '6-hour cancellation' clause, which tells the agent what classes of questions this document can answer. It stops short of saying whether the terms are static or versioned.

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 sentence, front-loaded with the resource name followed by a tight content enumeration. Every listed item corresponds to a topic an agent might need to answer, so nothing 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?

With no parameters, no output schema and rich annotations, the remaining burden is telling the agent what the call returns — which the content list does well. The only gap is that it doesn't indicate whether the response is one static document or a structured set of fields, which mildly matters for follow-up reasoning.

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 takes no parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. Schema coverage is 100% but empty, so no compensation is needed.

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 the resource (Celadon's wholesale terms) and enumerates the exact content covered — eligibility, pricing, case packs, payment, cancellation, delivery, claims, authenticity. That enumeration clearly separates it from the sibling tools, which all operate on products or orders. It lacks an explicit verb, but as a document-fetch tool the content list is more informative than a verb would be.

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 statement of when to call this versus e.g. quote_wholesale_order or search_wholesale_products, though the content list strongly implies it is the tool for policy/process questions rather than catalog or pricing lookups. For a zero-parameter, zero-ambiguity tool this is adequate but not spelled out.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is low. The description still adds genuine value by disclosing the shape of the response — per-brand product count and lowest case price — which the annotations cannot convey.

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 sentence with no filler that front-loads the resource and then the returned fields. Nothing is repeated from the title and nothing could be cut without losing 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?

With no output schema and no parameters, the description carries the burden of describing what comes back, and it does so adequately. Minor gap: it does not say whether the brand list is paginated, filtered by availability, or returned in full, which matters for a catalog-listing call.

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 takes zero parameters, so there is no parameter semantics to explain and the schema coverage baseline of 4 applies. The description correctly spends no words on inputs.

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?

Names a specific resource (wholesale Korean skincare brands) and states what each entry carries (product counts, lowest case price). It is clearly distinct from product-level siblings like get_wholesale_product and search_wholesale_products, though it never explicitly says so.

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 only implied: as a zero-parameter catalog listing it is evidently the browse-first entry point before get_wholesale_product or quote_wholesale_order. No sentence states when to prefer it over search_wholesale_products or what precondition (account/wholesale access) applies.

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?

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds useful context that nothing is purchased and that a checkout link is returned. It also discloses the quote summary contents, though it does not cover auth, limits, or error 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 two tight sentences, front-loading the purpose and then adding the key constraint and return behavior. Every sentence adds useful information without 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 quote-generation tool with no output schema, the description sufficiently explains what is returned: checkout link, total units, total cost, estimated retail value, and delivery estimate. Some parameter-level and catalog-reference details remain implicit, but the core behavior is 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?

Schema description coverage is low at 0%, so the description should compensate more. It usefully clarifies that quantities are in cases, but it does not explain the handle field or the items-array structure and limits beyond what the schema shows.

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: "Price a wholesale order," and clarifies the case-based quantity unit plus the checkout-link outcome. It clearly distinguishes this order-quoting tool from sibling product lookup/search/list tools.

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 clear usage context: use this to price a wholesale order and generate a checkout link for buyer review/payment, with no purchase occurring here. It does not explicitly name alternatives or when-not conditions, but the intended workflow is clear.

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?

Annotations already cover the read-only/idempotent/non-destructive profile, but the description adds commercially meaningful behavior: all-inclusive pricing with shipping and import duties bundled, sales tax at checkout, and a 5-business-day delivery promise. These materially affect how an agent should frame results to a user; only pagination and result-ranking behavior are unaddressed.

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 tight sentences: purpose first, then the commercial model that governs every price filter, then the return shape. No filler and no repetition of schema 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?

With nine optional params, full schema coverage, and no output schema, the description usefully compensates by enumerating the returned fields (per-unit price, per-case price, US SRP, margin) and the pricing model. It falls just short of complete by saying nothing about how results are ranked by default or how limit interacts with a large catalog.

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 adds real meaning on top: it clarifies that listed prices are case-level and all-inclusive of shipping/duties, which reinterprets what max_case_price and max_unit_price actually bound, and explains that margin is versus US suggested retail (the basis for min_margin_pct and sort=margin).

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') plus a narrowly scoped resource ('Celadon's wholesale catalog of authentic Korean skincare') with the target audience ('US businesses'). The word 'catalog' plus the multi-result return description makes clear this is the browse/discover tool, distinct from the singular get_wholesale_product 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?

It establishes clear context (wholesale, by-the-case, US B2B) and implies discovery-style usage, but never says when to prefer this over get_wholesale_product, list_wholesale_brands, or quote_wholesale_order. No exclusions or prerequisites are stated, so the agent must infer routing from sibling names alone.

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