Gemalli B2B Trade

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

Annotations already declare the operation read-only and non-destructive, lowering the burden. The description adds useful behavioral context by stating the regulatory basis and clarifying that a match means 'the goods may need an export licence.'

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 only two sentences with no filler. The core purpose is front-loaded, and the usage guidance is included efficiently.

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 read-only, non-destructive tool with three parameters and clear workflow placement, the description covers the essential semantics. It omits explicit return-format or error behavior, but that is not critical given the self-explanatory check 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?

The schema already documents hs_code and destination, and the description reinforces destination as optional with legal context. However, the locale parameter is not explained beyond its enum values, and the description does not significantly add meaning 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 an explicit action and resource: 'Check whether an HS customs code falls under EU dual-use export controls (Regulation 2021/821 and equivalents)'. It also mentions optional destination filtering and distinguishes this from related siblings like check_sanctions and lookup_hs_code.

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 usage context: 'Use it after lookup_hs_code, before the person commits to a shipment.' This tells the agent when to invoke it in a workflow, though it does not explicitly name exclusions or alternative tools.

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 indicate a safe, read-only operation. The description adds meaningful behavioral context beyond that: it returns possible matches with a similarity score, and it warns that matches require further verification rather than being definitive. This helps the agent set expectations without contradicting the annotations.

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 concise sentences cover purpose, result, and usage guidance. The most important information is front-loaded, and every sentence earns its place without 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 read-only screening tool with annotations covering safety and a schema covering parameters, the description is mostly complete: it explains what it screens, the source, the output nature, and the follow-up action. The only minor gap is that it does not describe how topic/country filtering affects screening, but the schema provides those options.

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 75%, so the schema already documents most parameters. The description adds some semantic value by clarifying that the query can be a company or person and that screening covers multiple list types, but it does not add meaningful detail about limit, topic, or country 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 states a specific verb ('Screen'), the target resource ('a company or a person'), and the domain (consolidated sanctions, PEP, and law-enforcement lists). It clearly distinguishes itself from siblings like check_dual_use by naming the exact list types and the OpenSanctions source.

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 concrete use case: 'Use it before the person commits to a counterparty.' It also clarifies how to interpret results ('Treat a match as a reason to verify further, not as proof'). It does not explicitly mention when not to use it or point to alternatives like check_dual_use, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns a full profile and mentions per-locale identifiers, which is useful. It doesn't disclose behavior like whether locale is optional or how missing locales are handled, but the schema covers the locale parameter.

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

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

Two sentences, front-loaded with the action and resource, followed by usage context. No wasted 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 read-only single-resource fetch with full schema coverage and safety annotations, the description is nearly complete. It could mention what happens if the slug doesn't exist or how locale affects the response, but those are minor gaps given the annotations and schema.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds context that the profile is per-manufacturer and that identifiers are for the same profile in other languages, but doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Fetch') and resource ('one manufacturer's full profile'), and enumerates the profile contents (company description, country, certifications, identifiers in other languages). It also distinguishes itself from siblings by naming list_manufacturers and search_products as prior steps.

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

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

Explicitly says when to use it: after list_manufacturers or search_products, when the person wants to know who the supplier is. This gives clear context and implies the alternative tools are for discovery, not profile detail.

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 mark readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral context by explaining the structure of the delivery_terms field (enum values, null handling, empty-list meaning) – information not present in annotations or schema. This goes beyond the baseline, though it doesn't address rate 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 a single paragraph that leads with the main purpose and available fields, then details the delivery_terms structure. While somewhat long, each clause earns its place – the delivery_terms explanation is essential for correct usage. It could be tightened slightly, but it's well organized 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?

Given the tool is a simple read operation with annotations covering safety and full schema coverage, the description is largely complete. It explains the nuanced delivery_terms format and usage trigger. However, it doesn't mention potential edge cases (e.g., product not found) or the full return shape, which would be useful. Still, it's sufficient for correct invocation.

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

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

Schema description coverage is 100%: both 'slug' and 'locale' have descriptive text. The tool description does mention 'requested language' which maps to locale, but it doesn't add any syntax or format details beyond the schema. This meets the baseline but does not elevate it.

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 ('Fetch'), a clear resource ('one product'), and enumerates the exact data fields returned (MOQ, lead time, Incoterms, HS code, etc.). It implicitly distinguishes from siblings like search_products (search vs. fetch) and get_manufacturer (supplier only vs. full terms).

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 final sentence explicitly instructs when to use the tool: 'Use it once the person has picked a product from search_products and wants the terms.' This gives a clear trigger and preconditions, routing the agent appropriately without needing to guess.

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?

Discloses live data reading, advises against caching, explains the price format (whole minor units), and clarifies that empty credit packs are expected ('that is the answer, not a fault'). This goes far beyond the readOnlyHint annotation, which only indicates a safe read operation. It gives the agent confident expectations about freshness, formatting, and edge cases.

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

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

Four sentences that front-load the main purpose, then logically cover usage trigger, price formatting, caching guidance, and the empty-credit-pack caveat. Every sentence earns its place; there is no filler or redundancy. The structure is easy to scan and understand.

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 tool with no output schema, the description covers the critical return information: prices, limits, price format, credit packs, and per-action costs. It also explains the live nature of the data. It does not list exact field names or the exact structure of the plan object, but it provides enough for an agent to interpret the response correctly.

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, so there are no parameter meanings to explain. Per the calibration baseline, a zero-parameter tool earns a 4 because the schema is trivially complete and the description cannot add parameter-specific value. The description instead focuses on output semantics, which is appropriate.

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

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

States 'Return Gemalli's current subscription plans with their prices and limits, read live from the platform.' This clearly identifies the action (return), resource (subscription plans), and source (live from platform). The title 'Plans and prices' reinforces the purpose, and none of the sibling tools (products, manufacturers, categories, etc.) overlap, so it is well differentiated.

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

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

Explicitly says 'Use it when the person asks what Gemalli costs or what a plan includes.' This gives a clear trigger condition. It also adds practical advice about formatting prices and not caching. It does not mention alternatives or when not to use it, but no alternatives are relevant among the siblings, so this is a minor gap.

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 annotations already indicate read-only and non-destructive behavior, but the description adds critical behavioral context: anonymous users are valid (returned as 'guest'), the semantics of previous_guest and linked_at fields, and guarantees about never returning other parties' data or secrets. This goes well beyond what annotations provide.

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 efficient and well-structured. It leads with the core purpose, then expands on edge cases and semantics without redundancy. Each sentence contributes new, necessary information for correct invocation.

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 that the tool has no parameters and no output schema, the description fully covers the return values (role, language, company, plan) and important nuances (anonymous handling, linking behavior). Nothing an agent needs to call it correctly is missing.

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

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

The tool has zero parameters and the schema coverage is 100% (trivially satisfied). The baseline for 0 params is 4, and the description correctly avoids adding parameter-specific info since none exist.

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 function: it reports the current user's role, interface language, and (when signed in) company and plan. This is specific to the viewer, distinguishing it from the sibling tools that handle other domains like products or HTS codes.

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 makes it obvious this tool is used when an agent needs to know who it is acting for, but it does not explicitly mention alternatives or exclusions. Given the tool's unique scope, the context is clear enough without explicit 'when not to use' guidance.

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 mark this as read-only and non-destructive, so the description's main contribution is behavioral. It reveals that names are returned in the requested locale and that the output maps to the identifier search_products expects, which goes beyond the schema.

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

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

Two sentences with no filler. The first states what the tool lists and for whom; the second states why and how to use it. Every sentence earns its place.

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

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

For a one-parameter list tool with safety annotations and an explicit integration with search_products, nothing essential is missing. The absence of an output schema is mitigated by the description's explanation of the category-name-to-identifier relationship.

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

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

The single parameter locale is fully documented in the schema with an enum and a description. The description's 'requested language' phrasing reinforces the schema but adds no new semantics, so baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: "List the product categories on Gemalli" and clarifies that names are localized. This clearly distinguishes it from sibling tools like list_manufacturers and explicitly ties it to search_products' expected identifier.

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 names two concrete use cases: offering a pre-search category choice and converting a category name into the identifier search_products expects. It does not explicitly exclude alternatives, but the context is clear and sufficient for a simple list 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?

Annotations already cover readOnlyHint=true and destructiveHint=false. On top of that, the description adds genuinely useful behavior: results are limited to verified manufacturers, include specific fields, are localized, and are sorted newest first. No contradictory behavioral claims.

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

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

Two sentences with no filler: the first front-loads the action, return shape, localization, and ordering; the second gives routing guidance. Every sentence earns its place.

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

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

For a list operation with two optional, fully documented parameters and read-only annotations, the description is complete: it states scope, returned fields, ordering, and the appropriate alternative. The lack of an output schema is compensated by listing the returned fields in prose.

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

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

Schema description coverage is 100%, so the schema fully documents limit and locale. The description only restates language localization and adds no new semantics 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 opens with a specific verb and resource: 'List verified manufacturers published on Gemalli.' It also names the returned fields and ordering, and its scope ('verified', platform-level) distinguishes it from search_products and get_manufacturer.

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: 'Use it to show what the platform carries' and directs filtering/search use cases to 'search_products'. This clearly differentiates the tool from its closest sibling.

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 mark the tool as read-only and non-destructive. The description adds meaningful behavioral context: which pages appear depends on whether the person is signed in, and labels come in the requested locale. No contradiction with annotations.

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 earning its place: what the tool returns, when to use it, and a behavioral caveat. The key purpose is front-loaded and there is no 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 simple read-only list tool with one optional parameter and no output schema, the description covers the trigger, the data returned, and the signed-in dependency. It does not describe a structured return shape, but the description's mention of 'label' and 'address' is sufficient for this simple case.

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 locale parameter is fully documented in the schema. The description adds a small amount of context by linking the locale to output labels ('in their language'), but does not need to compensate for any schema gaps.

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 ('List') and resource ('the pages of gemalli.com'), and states the output content ('label in their language and the address'). It is clearly distinct from the sibling commerce tools, which are about products, manufacturers, and inquiries.

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 it before offering a link, so you point at a page that exists rather than guessing.' It does not name alternatives or state when not to use it, but the intended call context 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?

The annotations already indicate readOnlyHint=true and destructiveHint=false, so safe read-only behavior is covered. The description adds valuable context on return contents: official names in the requested language, chapter, and similarity score. This goes beyond the annotations without contradicting them.

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

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

Two tightly written sentences with no filler. The purpose, input variants, return contents, and downstream usage are all packed into a compact description that is easy 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 read-only lookup tool with one required parameter and no output schema, the description gives enough context: what inputs are accepted, what the response includes, and how the result should be used next. The schema covers length and default constraints, so nothing essential 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 67%, so the schema already documents query and limit, and the locale enum is self-explanatory. The description reuses 'by description or by code prefix' from the schema and refers to 'requested language' for locale, but adds little new parameter-specific meaning. It does not explain limit further, but that is already covered by the schema.

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

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

States a specific verb ('Find') and resource ('Harmonised System (HS) customs code'), and clarifies the two accepted input forms: product description or code prefix. It also distinguishes itself from sibling tools by tying its output to the follow-up use of check_dual_use, so an agent can select it without opening schemas.

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 tells the agent when to use this tool ('when the person needs a customs classification for an import, an export or a quote') and what to do next ('then pass the code to check_dual_use'). This gives clear selection and chaining guidance beyond just describing the function.

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 adds 'It returns information only and sends nothing,' which goes beyond the readOnlyHint annotation by ruling out side effects like sending an email or triggering an outreach action. This is valuable context not present in annotations alone.

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 sentences, front-loading the key result and then giving usage guidance. Every sentence contributes meaning, with no filler or repeated schema information.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description is complete: it states what is returned, who should use it, example scenarios, and confirms no side effects. No critical information is missing for correct invocation.

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

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

Schema coverage is 100%, and the single optional parameter 'from' is already described in the schema as the company or platform the person represents. The description reinforces this through examples like logistics and investor, but does not add substantial new meaning 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 uses a specific action ('Return') and names the exact resource returned: Gemalli's partnership/investment terms and the founder's direct contact. It also clarifies who the tool is for, which distinguishes it from buyer-facing tools like request_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?

It explicitly states when to use the tool: when the person represents a company that would work with a trade platform rather than buy on it, with concrete examples. It implies a buyer scenario should use a different tool, but does not name an alternative explicitly.

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 only say readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the description usefully fills in what actually happens: the manufacturer receives the request, the person receives an email with a sign-in link, and no account is required first. It also warns against inventing an email address, which is a real behavioral constraint. It doesn't cover retry/rate-limit behavior in the description, though idempotency is covered in the schema.

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?

Five sentences, each carrying distinct information (purpose, contact-input constraint, recipient behavior, no-account prerequisite, usage trigger), with the core action front-loaded. Dense but not padded.

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

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

For a 12-parameter mutation tool with no output schema, the description covers the essential context: what is sent, who receives what, and the no-account prerequisite. Idempotency and field-level semantics live in the schema, so nothing critical is missing, though a note on the response the caller sees would round it out.

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 already 92%, so the baseline is 3. The description adds meaningful value on top: 'ask them and pass exactly what they give you, never invent an address' constrains how buyer_name and buyer_email should be populated, which the schema alone does not convey.

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+resource ('Send a request for prices, samples or terms to a manufacturer') and clarifies the on-behalf-of framing. This clearly separates it from sibling write tools like partnership_inquiry or submit_join_request, which have different targets and 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?

It gives a clear trigger ('Use it once they have chosen a supplier') and notes 'No account is needed beforehand.' It stops short of explicitly naming alternative tools or when NOT to use this one, but the preconditions are clear enough for correct selection.

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 contradiction with annotations: readOnlyHint=true and destructiveHint=false align with the non-mutating 'Search' action. Beyond the annotations, the description adds behavioral context — results are localized product cards limited to seller-confirmed Incoterms and include price range, MOQ, and supplier. Pagination and limit behavior are left to the schema, which is a minor 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?

Four sentences, each earning its place: scope, filter dimensions, return shape, and usage trigger. The purpose is front-loaded in the first sentence. The filter list partially overlaps with schema descriptions, but the description stays compact and free of 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 read-only search tool with all-optional parameters, full schema coverage, and no output schema, the description covers the essentials: what is searched, what filters exist, what results contain, and when to use it. Pagination defaults and locale mechanics are not mentioned, but those are already documented in the schema's parameter descriptions.

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

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

Schema description coverage is 100%, so the schema fully documents all 10 optional parameters. The description's filter enumeration (free text, category, manufacturer, country, MOQ max, price max, Incoterms) summarizes the parameters but adds no meaning beyond what the schema already provides, meriting the baseline 3.

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 ('Search wholesale products published on Gemalli') and states the output shape ('product cards in the requested language with price range, minimum order and the supplier'). It is clearly distinct from siblings like get_product, check_dual_use, or request_quote, though it never explicitly names the alternative.

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 final sentence gives explicit usage context: 'Use it when the person is looking for goods to buy or source.' This is clear when-to-use guidance, but there are no when-not-to-use conditions or named alternatives, so it does not reach a 5.

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 only declare this is a non-read-only, open-world, non-destructive write; the description adds meaningful context beyond that: the team follows up by phone, contact details must be captured verbatim and never invented, and consent is required. It does not discuss duplicate handling, though the schema's operation_id covers idempotency.

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, front-loaded with the action, then sourcing rules, then the consent restriction. Dense but every sentence carries a distinct constraint; no 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 an 11-parameter write tool with no output schema and only safety-related annotations, the description supplies the operational essentials: required contact data, data-sourcing discipline, and the consent gate. Return/duplicate behavior is delegated to the schema, which is 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?

Schema coverage is 100%, so the baseline is 3. The description reasserts the three required fields and supplies a rationale for phone ('the team follows up by phone'), but adds little beyond what the per-field schema descriptions already say about name, email, locale, source, and operation_id.

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 ('send the platform team a request to join Gemalli') and scopes the audience to manufacturer/trader/agent/logistics/broker/finance roles. The phrase 'rather than buy on it' implicitly separates it from buyer-side siblings like request_quote, though no sibling is named outright.

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

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

Gives a clear when-not rule: 'Use it only when the person has asked to be contacted, never to record someone you are merely discussing.' It also constrains who qualifies (non-buyer roles). It stops short of naming an alternative tool such as partnership_inquiry, so routing between the two still requires inference.

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