Gemalli B2B Trade

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

With no annotations, the description carries the full behavioral burden. It discloses that the operation is a lookup, that results can be narrowed by destination, and that non-empty results imply a potential export licence need. However, it does not mention empty-result behavior, side effects, or authorization, though 'Public:' hints at open access.

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 with no filler. The core purpose and the practical business consequence are both front-loaded, and every clause adds value.

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 with no output schema, the description covers the input, optional narrowing, and the meaning of a non-empty result. It does not explicitly state what an empty result means or how locale affects the response, but the core call decision is sufficiently supported.

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%, with hs_code described as coming from lookup_hs_code and destination described as ISO-2. The description adds the meaning of destination narrowing and the practical implication of results. Locale, however, has only an enum and no explanatory description in either the schema or the tool description, so the agent is left to infer its purpose.

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: 'cross-reference an HS code against the EU 2021/821 dual-use control list'. This clearly distinguishes it from siblings like check_sanctions and lookup_hs_code. The title reinforces the purpose, and the description leaves no doubt about what is checked.

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 concrete usage context: 'surface it before signing a CartMandate' and explains what a non-empty result means. It does not explicitly name alternatives or when not to use this tool versus check_sanctions, but the practical trigger is clear 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, the description carries the full burden, and it discloses key behavior: public access, no bearer required, fuzzy matching, top-N results, and a 0..1 similarity scale. It stops short of rate limits, pagination, or any statement about side effects, though a screening call is clearly read-oriented.

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 front-loaded sentences cover action, dataset, output shape, workflow trigger, and authentication, with no filler. Every sentence adds operational value.

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 includes source data, use case, output shape, similarity scale, and auth requirements, so an agent has enough to call it correctly. Minor gaps remain: no guidance on interpreting similarity thresholds, no pagination/rate-limit detail, and no output schema to compensate.

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 documents query, limit default, and country format; the description adds meaning by explaining fuzzy matching, top-N ranking, and the data categories behind topic enum values (sanction, PEP, crime). The topic parameter itself still lacks a direct description, but the prose compensates partially.

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: fuzzy-match a name against the OpenSanctions consolidated dataset, and it enumerates the exact list types (EU/US/UK/UA/UN sanctions, PEP, crime). That concrete scope distinguishes it from check_dual_use and the product/HS-code siblings even without naming them.

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 use it BEFORE signing a CartMandate, so the buyer agent can refuse a counterparty with sanctions/PEP exposure. It does not, however, state when not to use it or name an alternative such as check_dual_use for export-control screening.

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 adds meaningful behavioral detail: the response matches the route payload, includes base columns, locale translation with fallback chain, and an alternate-locale slug map. It does not cover missing-slug behavior or default locale behavior, but it is notably transparent.

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?

One information-dense sentence with the purpose front-loaded and no filler. Every clause adds useful context about the returned payload.

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 two-parameter fetch with no output schema, the description gives a clear picture of the response composition and localization behavior. It is slightly incomplete on what happens when locale is omitted and what exactly 'base columns' are, but an agent can still invoke the tool 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?

Schema coverage is 100%, giving a baseline of 3. The description adds extra meaning by explaining how locale drives the translation fallback chain and that the response includes an alternate-locale slug map, going beyond the schema's one-line locale description.

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 precise operation: fetch a single manufacturer profile by slug. This differentiates it from list_manufacturers, search_products, and get_product, and matches the title 'Producer profile'.

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 clearly implies when to use this tool: when you have one manufacturer slug and need a single profile. It does not explicitly name alternatives or when-not-to-use conditions, 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does well by disclosing that this is a read-only fetch and by detailing the return payload: B2B trade fields, media gallery, and manufacturer reference. It does not cover edge cases like not-found behavior, but for a simple getter this is strong transparency.

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 that front-loads the action and resource, then packs the payload specifics and endpoint equivalence into the remainder. Every clause earns its place; 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 two-parameter getter with no output schema, the description is largely complete: it names the route, the parameter-driven localization behavior, and the key payload sections. It could add error/not-found behavior or clarify the locale's effect on slug resolution, but nothing essential to making the call is missing.

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

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

Schema description coverage is 100%, so the schema already documents both slug and locale. The description adds detail about the returned payload but not about parameter semantics themselves, so the 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 starts with a specific verb and resource: 'Fetch a single product by slug.' It also enumerates the exact payload contents (B2B trade fields, media gallery, manufacturer reference), which makes the tool's purpose unmistakable and distinguishes it from sibling search_products, which presumably returns lists.

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 clearly implies when to use the tool: when you have a product slug and need the full details of a single product. It does not explicitly name alternatives like search_products for cases where the slug is unknown, so it stops short of full 5-level guidance, but the usage context is clear and not misleading.

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 discloses the scope ('all categories'), locale-dependence ('localised names'), and deterministic ordering ('categories.sort_order then slug'). These are meaningful traits beyond the schema. It stops short of describing default locale behavior when the optional parameter is omitted, 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?

Two sentences, no filler. The core function is front-loaded, with ordering and usage context following in strong, relevant order. Every clause 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 single-parameter list tool with no output schema, the description is complete. It covers what the tool does, how results are ordered, and when to use it. No required information is missing for an agent to select and invoke it 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 only parameter, locale, has 100% schema description coverage with an enum and clear meaning. The description adds a small complement by saying names are 'localised,' but it does not explain parameter details beyond the schema. The baseline of 3 applies because the schema already documents the parameter fully.

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 all product categories with localised names.' It clearly distinguishes this from siblings like list_manufacturers and search_products by stating its purpose is to build dropdown filters before a search, which an agent can immediately act on.

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 an explicit usage context: 'Use for building dropdown filters before calling search_products.' This tells the agent when to invoke this tool, though it does not explicitly mention alternatives or when not to use them. The sibling list and the reference to search_products provide enough orientation.

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. It discloses a read-only listing behavior (non-destructive), returns only 'published profiles' with a limit, orders by recency, and states the returned attributes. It does not mention authentication or rate limits, but for a simple list operation the disclosed behavior is adequate.

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 concise sentences with no wasted words. The purpose and return info are front-loaded, and the routing guidance is a natural second sentence. 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?

For a two-parameter list tool with no output schema and no annotations, the description adequately covers what it returns, ordering, limit behavior, and the alternative search path. It lacks explicit notes on authentication or error conditions, but these are minor for a read-only list operation, so it is nearly 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 coverage is 100% for both parameters, giving a baseline of 3. The description adds value by linking 'limit' to 'first N published profiles' and 'locale' to 'localised name' and 'per-locale slug', clarifying how the parameters affect output beyond the 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 description states a specific verb ('List') and a resource ('vetted Ukrainian manufacturers from the Gemalli marketplace'), and details the return fields (localised name, country, certifications, per-locale slug). However, it does not explicitly differentiate from siblings like get_manufacturer or search_products, so it lacks explicit sibling 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?

The description explicitly provides an alternative condition: 'For text + country search, use Wave 3b auth tools.' This tells the agent when not to use this tool and routes to an appropriate alternative, satisfying the 'when-not' guidance clearly.

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 explains the search modes ('Free-text or code-prefix search') and the return payload ('matching HS codes with localised names + chapter rollup + similarity 0..1'), which goes beyond taxonomy-level descriptions, though it omits details like no-match behavior or pagination.

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

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

Two sentences with no filler. The description front-loads the core purpose and public access, then states inputs, outputs, and downstream integration in a compact, well-organized way.

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, the description does a good job of summarizing return values and intended use. A minor gap is that terms like 'chapter rollup' are not expanded, and there is no mention of edge-case behavior, but the core calling context is adequately covered.

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 query and limit well, and the description adds some meaning by noting free-text/code-prefix search and localised names, which clarifies locale. However, it does not deeply elaborate parameter formatting or edge cases, and coverage is moderate rather than high.

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 action and resource: 'classify a product against the Harmonised System (HS) tariff schedule.' It also names the output directly and connects to a sibling tool, making it easy to distinguish from generic product search or sanctions checking.

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 useful and explicitly routes the output to check_dual_use. It does not explicitly state when not to use this tool versus other siblings, but the recommended downstream usage is a strong practical guideline.

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 behavioral burden. It clearly signals a read-only information lookup ('Get ... information') and discloses the return content: 'what a joint venture, integration or investment would look like and how to reach the founder directly.' It does not mention auth or rate limits, but for a simple info tool this is adequate.

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 its core purpose and every clause contributes. The long enumeration of organisation types is verbose but useful for eligibility classification, so the length is largely justified.

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 one optional parameter and no output schema, the description is thorough: it explains who should call it, when to call it, what it returns, and that it provides direct founder contact. Missing details are minimal and unlikely to block 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%, so the single optional parameter 'from' is already documented in the schema. The description adds no further meaning about this parameter, so the value-add is at 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?

States a specific verb and resource: 'Get Gemalli partnership and investment information.' The description then defines the scope as 'joint venture, integration or investment' and enumerates eligible organisation types, making it clearly distinct from buy-side product or compliance sibling 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?

Gives an explicit trigger: 'Call this whenever your principal is an organisation that could partner with a global B2B trade platform rather than merely buy on it.' It also provides a when-not condition by contrasting partnership-oriented organisations with ordinary buyers, effectively routing agents away from product and lookup 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?

With no annotations, the description carries full behavioral disclosure burden. It explains the no-account requirement, that the manufacturer receives the request, that the principal gets a sign-in link by email, and that the reply and supplier contacts appear there. It also notes agent_name is recorded as the source. Slight gaps remain on side effects (e.g., email sending) but coverage is strong.

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 pack essential guidance: action, no-account note, principal data requirement, workflow outcome, and usage timing. The capitalized instruction is eye-catching and front-loaded. 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?

The description covers the full flow, prerequisites, and outcome, all within a modest length. While it doesn't enumerate every parameter, the schema already does that at 90% coverage. The only minor omission is a note on required fields among the four mandatory parameters, but that is evident from the 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 90%, so the schema already documents most parameters clearly. The description adds minimal parameter-specific meaning beyond highlighting buyer_name/buyer_email authenticity ('never invent an address') and confirming the sign-in link goes to buyer_email. This is sufficient given the rich 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 ('Send a Request-for-Quote') and resource ('to a manufacturer'), and clarifies it is done on behalf of the person being helped. It clearly distinguishes this from sibling tools like partnership_inquiry or search_products by focusing on the quote request action.

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 timing: 'Use this once they have chosen a supplier and want prices, samples or terms.' It also provides a critical prerequisite: 'ASK YOUR PRINCIPAL FOR THEIR NAME AND EMAIL FIRST' and warns against inventing an address. This gives clear when-to-use and what-to-prepare 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?

With no annotations, the description carries the behavioral burden. It discloses that only published products are searched, that results are localized, and that FTS is involved. It does not mention sorting, pagination behavior, or result-count defaults, though these are partially covered by schema parameter descriptions.

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 wasted words. The purpose is front-loaded, and the filter list is compact and scannable. Every clause adds useful 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?

Given 9 optional parameters and full schema coverage, the description provides a sufficient high-level overview and return shape ('localised product cards'). The main gap is explicit usage routing versus sibling tools, which is minor for actually invoking the tool 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?

Schema description coverage is 100%, so the baseline is 3. The description's filter list largely mirrors schema parameter names and adds only modest extra context (e.g., q is FTS-backed, country is ISO-2, slugs for category/manufacturer). It does not substantially enrich 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 states a specific verb ('Search') and resource ('published product catalogue'), and enumerates the filter dimensions. This clearly distinguishes it from sibling tools like get_product (single product lookup) and list_categories (taxonomy listing).

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 implies usage: search and filter the catalogue. However, it does not explicitly state when to prefer this tool over get_product, list_manufacturers, or other siblings, nor does it give when-not-to-use guidance. An agent must infer the tool's role from sibling names.

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