Unan Trading

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered by structured data. The description adds useful content scope (two business entities, terms and response-time data) but says nothing about freshness, source of truth, or how the two entities are returned together. Given annotation coverage, a 3 is appropriate.

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, front-loaded with the most identifying fields. It reads as a fragment rather than a sentence, which slightly weakens the opening but wastes no 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?

With no output schema, the enumeration of returned fields is exactly the compensation needed and makes the return content predictable. The only remaining gap is that it does not state the shape in which the Maldives and Brazil data are delivered, which is minor for a static, zero-parameter read.

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 nothing for the description to disambiguate beyond confirming this is a parameterless lookup. Baseline 4 applies and no meaning is missing.

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 enumerates the specific resource contents (legal names, registration numbers, addresses, contacts, delivery terms, minimum orders, response times) and scopes them to two named entities, Unan Trading Maldives resort supply and Brazil export. That is concrete enough to separate it from the quote/offer/product siblings, but it is a noun phrase with no verb, so the action (retrieve company profile and terms) is only implied.

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 when-to-use framing, no prerequisite, and no reference to alternatives such as request_quotation or list_brazil_export_offers. An agent must infer from the field list alone that this is the reference/contact lookup to consult before or independently of quoting.

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 a safe, read-only, idempotent, closed-world computation, so the description's job is to add substance — which it does by disclosing the estimate fallback for missing current prices, the 200 kg minimum, and the pricing tiers used in the calculation. It does not, however, explain any currency, tax, or validity-period assumptions behind those prices.

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 purpose and pricing are front-loaded in the first sentence, followed by input requirements and then the return value. It is dense but nearly every clause carries operational information; only the parenthetical price list makes the opening sentence long and slightly hard to scan.

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 7-parameter tool with a nested cuts object and no output schema, the description covers what the caller must supply, what happens when optional data is missing, and what comes back (monthly and annual savings, re-balanced mix, pre-filled report link). Nothing an agent needs in order to invoke it correctly is absent.

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 meaning the schema lacks: the per-kg price for each level, the 200 kg minimum order, and the explicit either/or relationship between the cuts object and premium_kg/secondary_kg. The 'estimates must be presented as estimates' rule for current prices also clarifies the semantics of those optional fields.

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

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

The description names a specific verb and resource — comparing a Maldives buyer's monthly beef cost three ways (current spend, individual cuts from Unan Trading, FullSet blended price) — and enumerates the exact price tiers (Custom US$24, Cross Wagyu US$31, Pure Wagyu US$37/kg, 200 kg minimum). This is unmistakably distinct from siblings like list_brazil_export_offers or request_quotation.

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 clearly frames the use case and the required inputs (monthly kg per cut via cuts, or premium_kg/secondary_kg, plus level, ideally current prices per kg). It also states a fallback rule when current prices are absent (market estimates used, must be presented as estimates). It stops short of explicitly naming when to route to a sibling such as request_quotation instead.

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?

Beyond the read-only annotations, the description adds a critical behavioral constraint: export prices are only on request and must never be estimated or invented. It also specifies FOB Brazil and the product/container scope, though it does not describe return format or whether offers change over time.

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

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

The description is front-loaded with the core purpose, then product categories, trade term, and pricing constraint. Every sentence carries useful information, and there is no redundant wording.

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-parameter, read-only list tool with no output schema, the description covers the company, product offerings, container formats, Incoterm, and the no-price-estimation rule. It does not explicitly describe the returned list structure, but the essential calling context is present.

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 the baseline is 4. The description appropriately does not invent parameter details and instead explains the offer scope and pricing policy.

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 resource: current export offers and FullSets from Unan Trading Ltda, including named product categories and container types. It is clear what the tool lists, but it does not explicitly distinguish this browsing tool from siblings like search_products or get_fullset_beef_quote.

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

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

Usage is implied: the tool is for importers worldwide to view current offers, and pricing must go through a request rather than being estimated. However, it does not explicitly say when to use this tool versus request_quotation, get_fullset_beef_quote, or search_products.

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?

Beyond the annotations (openWorldHint=true, idempotentHint=false), the description discloses that this is an outbound message to an external party with a one-business-day email reply, and imposes a human-confirmation gate — real behavioral context. It stops short of describing failure behavior or what happens on resend/duplicate submission for a non-idempotent send.

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

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

Four tight sentences, front-loaded with purpose, then the gate condition, then detail. The trailing market sentence is dense and slightly crammed with quoted enum values, but no sentence is filler.

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

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

For a 10-parameter outbound-send tool with no output schema, the definition covers what it does, the mandatory human approval, the recipient and expected reply, and how to pick the market. That is enough for an agent to call it correctly; the only mild gap is error/resend behavior.

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

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

With 60% schema coverage across 10 parameters, the description compensates for the most ambiguous ones: it explains the two market enum values, the meaning of buyer_confirmed, and where product_id should come from. It says nothing about phone, message, delivery_date, or delivery_location, though those carry their own schema 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 first sentence gives a specific verb and resource plus the recipient: 'Send a quotation request to Unan Trading on the buyer's behalf.' It also states the outcome channel and latency, which clearly separates it from the read-only siblings (search_products, list_brazil_export_offers, get_company_info).

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

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

Explicit precondition is stated: use only after the buyer has seen the exact details and asked for them, with buyer_confirmed=true as the proof. It also adds a negative rule ('Do not invent contact details') and routes the agent to search_products for product ids, and explains which market value applies to which order type.

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 read-only, idempotent, closed-world, non-destructive, so the bar is lower; the description still adds real business context — USD per unit, prices exclude GST and resort-island freight, free delivery in Malé and Hulhumalé, and final prices confirmed on written quotation. It does not disclose result shape or how max_results truncation behaves, which is the remaining 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?

The purpose and catalog are front-loaded, then pricing terms, then the operational hints. Dense but every clause carries information — no filler. The catalog enumeration is long, though it doubles as retrieval vocabulary, so it earns its space.

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 still tells the agent that results carry ids usable in request_quotation, which is the key downstream fact. It omits what fields a result contains (name, price, unit size) and pagination behavior, minor for a three-parameter search tool but not nothing.

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 67%: query and category carry descriptions and category has an enum. The description reinforces the query-empty-lists-category behavior, which links the two parameters, but says nothing about max_results (its default of 15 and cap of 50 exist only in the schema). Adequate but not compensating for the undocumented 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?

Opens with a specific verb and resource ('Search Unan Trading's Maldives wholesale price list') and enumerates the catalog scope (certified Brazilian beef, Halal lamb, fruit, coffee, juices, water, pantry). An agent can distinguish this from get_fullset_beef_quote or list_brazil_export_offers without opening any schema.

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

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

Gives two concrete usage rules: leave query empty to list a whole category, and use returned ids in request_quotation. That sections the work before and after this call. It does not say when to prefer this over list_brazil_export_offers or get_fullset_beef_quote, so sibling differentiation is only partial.

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