Gemalli B2B Trade

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is covered. The description adds real behavioral context beyond that: authorization comes from the visitor pass, and a ticket belonging to someone else is 'simply not found' rather than erroring — a meaningful disclosure about access failure behavior. It stops short of saying what the call returns or whether the visitor is notified.

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

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

Three short sentences, zero filler, with the core action front-loaded and the anti-pattern (duplicate ticket) stated before the identity caveat. Every sentence carries distinct 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 two-parameter append tool with no output schema and annotations covering the safety profile, the description supplies purpose, trigger, identity model, and failure semantics. The only minor gap is the absence of any note about what happens on success (e.g., whether a message id or updated thread is returned).

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

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

Schema description coverage is 100%, so both parameters (message, ticket_id) are already documented, including that ticket_id comes from create_feedback_ticket. The description adds no syntax, format, or constraint detail beyond the schema, so the baseline of 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 ('Add a message to an existing feedback ticket') plus the scoping qualifier ('of the current visitor'). It explicitly contrasts with the sibling create_feedback_ticket ('Do NOT create a second ticket for the same problem'), so an agent can route correctly without opening either schema.

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

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

Gives the triggering scenario ('when they remember a detail ("only in Chrome") after the ticket was created'), names the alternative to avoid, and states the identity precondition ('Identity comes from the visitor pass'). This is explicit when/when-not 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 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 declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so mutation semantics and safety are partly structured. The description adds real context beyond that: a state precondition (won't close already-resolved tickets) and that identity is derived from the visitor pass, so no caller identity argument is needed.

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

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

Three short sentences, front-loaded with the action and trigger, followed by the negative boundary case and the identity note. Every sentence carries information; 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 mutation tool with no output schema, the description covers purpose, trigger, exclusion, and identity source. It leaves the observable result of closing (and whether it is reversible) implicit, which annotations partially mitigate.

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

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

Schema description coverage is 100%, so both parameters (ticket_id and reason) are already documented in the schema, including the provenance of ticket_id. The description adds nothing about the optional reason field or accepted values, so the baseline 3 applies.

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

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

States a specific verb and resource (close a feedback ticket) scoped to the current visitor's ticket, which cleanly separates it from create_feedback_ticket, list_my_feedback, and get_feedback_thread. The closing condition and the exclusion of already-resolved tickets make the operation unmistakable.

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 states when to use it ('when they say it is no longer relevant or they worked it out') and when not to ('a ticket the team already finished ... is NOT closed — say so instead'). It stops short of naming a sibling tool to use in that case, leaving the alternative implied rather than specified.

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 readOnly=false, destructive=false, openWorld=true; the description adds real behavior the agent could not infer: identity comes from the visitor pass (never a user id) and contact_email is required for unsigned visitors because otherwise there is no fix-notification channel. It does not cover rate limits or what the tool returns, but for a create call it is well above the annotation baseline.

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 call-once and confirmation guardrails, then the identity/email constraint. Every sentence carries a distinct rule with no filler, though the final sentence could be marginally tighter.

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 write tool with no output schema, the description covers the critical non-obvious behaviors (single invocation, confirmation gate, implicit identity, conditional email requirement). It is complete enough to call correctly, with only secondary params left to the schema, which already documents them thoroughly.

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 100% schema coverage the baseline is 3, and the description adds genuine semantics beyond it: it clarifies that no user-id parameter should ever be passed (identity is implicit from the visitor pass) and reinforces the conditional requirement on contact_email. The remaining params (locale, subject, message, transcript, page_url) are left entirely to 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 and resource ("Record a feedback ticket") plus the content scope (question, problem, suggestion) and the owning team, which cleanly separates it from siblings like add_feedback_message or close_feedback_ticket. It stops short of explicitly naming those siblings, so it is clear but not fully 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?

It gives an explicit precondition ("only after the person confirmed the wording you read back to them") and an explicit when-not ("Call it ONCE"), which is strong usage guidance. It does not route the agent to an alternative tool for follow-ups or lookups, so it does not reach the alternatives-aware top band.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered; the description goes well beyond it with caching cadence, the `retired: true` flag and why retired text is still returned, the silent/empty-answer semantics, and the validation failure mode for non-uuid ids. That is behavioural context an agent could not infer from the structured fields.

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

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

The core guidance is front-loaded and the no-ids/with-ids split is easy to scan, but there is waste and noise: a stray fragment ('off.'), theatrical phrasing ('If this door is silent'), and guillemets around a log description. A shorter, cleaner statement of the same rules would serve the agent better.

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

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

For a two-parameter, read-only lookup with no output schema, the description supplies return shape (short lines vs. full text), the retired flag, the empty-result meaning, and the error case. Nothing an agent needs in order to call this 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?

Schema coverage is 100%, so the baseline is 3; the description still adds intent — three ids is prompt-sized while 50 is review-screen-sized — which tells the agent how to size the call, not just its limit. It also repeats the absent-vs-`validation_failed` distinction already present in the schema, so part of the value is duplication rather than new meaning.

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 concrete verb and resource: returns platform rules for the agent as short lines for a prompt, and it names no sibling because none overlaps — it is the only knowledge/rule tool in the list. The two modes (all active rules vs. full text by ids) are stated up front, so the agent knows exactly what it gets without opening the 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?

Explicit operating instructions: call once and cache by `rev`, re-read on a platform poke or when the fallback poll comes due, use no-`ids` for all active rules, use `ids` for full text including retired ones. It also covers the negative case — an empty answer is normal and must not change behaviour — which is exactly the when-not guidance agents need here.

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/no-destructive/no-open-world profile, and the description layers on real operational context the annotations cannot: it is a demo with test payment and no charge, company search and emails are switched off, and the agent must never promise buyers. It also discloses locale fallback behavior. This is exactly the kind of beyond-schema behavior disclosure that earns a high score.

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 core purpose is front-loaded and each sentence carries policy or output information rather than filler. However, the 'order window' idea is repeated three times and the pricing-rule caveat is verbose, so it is slightly padded for a two-parameter read tool.

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 carries the full burden of describing return content and does so thoroughly — plan names, USD prices, quotas, country limits, top-up rules, roles, stages, and segment/question mapping. Combined with the demo-state caveats, an agent has everything needed to call and interpret it.

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% for both parameters, and the description's statements about locale (uk, ru, en, fallback en) and hs_code (2-10 digits, picks the clarifying question and segments) largely restate the schema. Baseline 3 applies since the schema does the heavy lifting and the description adds little parameter-level syntax.

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 ('Read the buyer-search package offer') and enumerates the exact payload: plans with USD prices, company quotas, country limits, top-up rules, roles, order stages, and per-HS-code clarifying question plus segments. It explicitly distinguishes itself from the sibling get_subscription_plans, so an agent can route without opening either schema.

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

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

Gives clear context ('Use it in the sales chat to answer questions and to suggest a plan and segments') and a firm behavioral boundary ('You only suggest: the person chooses and pays in the order window, never through you'). It also carves out the subscription-plans pricing rule. What's missing is an explicit when-not-to-use condition beyond that one contrast.

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 it read-only and closed-world, so the description focuses on data semantics instead: two separate lists (`reasons` live, `retired` kept only for reading old feedback) and the label-vs-source_label distinction with the 'never translate from label' warning. It does not state caching lifetime or whether retired entries can appear in the live list, leaving minor gaps.

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

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

Purpose is front-loaded in one short sentence, followed by ordered operational guidance. It is dense and includes downstream UI instructions (send `reason_shown_lang` with the rating) that belong to a different call, which is scope creep but each sentence still carries real 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?

There is no output schema, so the description must describe the return shape — and it does: the `reasons`/`retired` split, plus `label`, `lang`, `source_label`, `source_lang`, and `rev`. Given a single optional parameter and read-only annotations, nothing needed 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?

Only one parameter, `locale`, and the schema already documents the exact → base → English fallback chain at 100% coverage. The description never discusses the input parameter, instead explaining response-side fields (`lang`, `source_lang`), so it adds no meaning beyond the schema here.

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+resource: returns the reason options a person can pick after rating the agent. It immediately distinguishes itself from sibling write tools like rate_agent_result or add_feedback_message by framing itself as a read-only dictionary lookup.

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 invocation guidance: call once when the widget opens, cache the result, re-read only when the platform signals a dictionary change or lazily via `rev`. It also prescribes the degraded path — if the call returns nothing, still show the free-text field and count the rating.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the return shape (full conversation, not just the ticket) and the authentication model ('Identity comes from the visitor pass'), explaining why no visitor id is passed.

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 read action and its scope before the usage caveat. The closing clause slightly restates the same point ('not to decide anything' / 'the agent does not answer on their behalf'), which is mild redundancy but not bloat.

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 read tool with no output schema, the description covers what the agent needs: what is returned (the whole conversation), how identity is resolved, and the behavioral boundary. Nothing required to invoke 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?

Schema coverage is 100% with a single required ticket_id, so the baseline is 3. The description adds meaning the schema does not carry by explaining that visitor identity is derived from the pass rather than any parameter, clarifying the scoping of the lookup.

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 (Read) and resource (one feedback ticket of the current visitor) and enumerates exactly what the thread contains: the original request, later additions, and team answers. The phrase 'one feedback ticket ... with its whole conversation' implicitly separates it from list_my_feedback (plural) and add_feedback_message (write).

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 usage directive — 'Use it to SHOW the ticket, not to decide anything' — and an explicit boundary that the agent must not answer on the team's behalf. It stops short of naming the alternative tool (e.g., add_feedback_message) an agent should use when a reply is actually required.

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?

Beyond the readOnlyHint and non-destructive annotations, the description discloses critical behavioral traits: guest responses return `reason: "guest"` with no data, no memory is kept without a cabinet, the person is inferred from the visitor token (never an id), and `origin: model` traits are guesses worth confirming. This is rich, actionable context that annotations alone do not 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 front-loaded with purpose and content, then usage and guest caveats. It is somewhat long and includes a parenthetical redundancy ('there was nothing to carry'), but every part contributes meaning and no section feels superfluous.

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?

No output schema exists, so the description must explain the return shape, and it does: up to six traits, last five conversation outcomes, the `origin` field with human/model semantics, and the empty-guest response with `reason: "guest"`. Together with the usage and sign-in instructions, an agent has everything needed to call and interpret the result.

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

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

With zero parameters the baseline is 4, but the description adds important semantic guidance: 'The person is taken from the visitor token — never pass an id.' This prevents a common misuse (passing an id) and explains the implicit identity source.

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 statement: 'What the platform remembers about THIS person between conversations,' and details exactly what is returned (six stable traits and last five conversation outcomes). It is clearly distinct from the write sibling remember_about_person and from knowledge tools like get_agent_knowledge.

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 'Call it before you answer, so you do not ask again what they already told you' and instructs to 'call this door again right after sign-in.' These are clear contextual triggers, though no explicit alternative tool is named or a when-not-to-use case beyond guest behavior.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description goes well beyond them: it defines the shape of delivery_terms, explains each place_kind value, documents null semantics, and tells the agent that an empty list means 'Incoterms on request'. It also warns that specs_display is already localized and that raw `specs` tokens must never be copied, which is exactly the kind of trap an agent would otherwise fall into.

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 payload is front-loaded: the field list comes first and the usage trigger last. The delivery_terms/specs_display clauses are dense but each carries non-obvious semantics, though the capitalized emphasis and em-dash parentheticals make the middle sentence harder to skim than necessary.

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 carries the burden of explaining returns, and it does so for the two trickiest fields (delivery_terms, specs_display). The remaining fields (price range, photos, HS code) are named but their formats are not described; for a simple two-param read, that gap is tolerable.

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 does not: it explains the language fallback (requested language, English fallback) and how locale propagates into place_city and specs_display. Only the `slug` per-locale vs base distinction is left entirely to 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 and resource (fetch one product's trade terms) and enumerates the concrete fields returned: MOQ, lead time, Incoterms, HS code, packaging, price range, photos, supplier. It also implicitly separates itself from search_products, which is the only sibling that could be confused with it.

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 an explicit trigger: use it once the person has picked a product from search_products and wants the terms. That establishes both the prerequisite and the sibling that precedes it. It doesn't state a when-not case, but the ordering guidance is unambiguous.

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 readOnlyHint, the description adds meaningful behavioral context: quotes come from the sales desk, pricing depends on catalogue/languages/markets, and the tool returns contacts ('contacts you get back'). It also warns against inventing pricing information, which is valuable for an AI agent. It does not detail the exact return structure, but the no-param, read-only context lowers that burden.

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 purpose and then explains context. It is somewhat verbose, especially the prohibition list ('state, estimate, guess or recall'), but each sentence adds safety or use-case value. It is longer than necessary for a zero-param tool, but not padded with irrelevant detail.

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?

Despite lacking an output schema, the description tells the agent what will happen (gets contacts back) and the correct follow-up action ('offer to introduce them'). It covers the central use case and guards against misuse. Minor gaps remain about the exact contact format, but overall the description is complete enough for safe, 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?

The tool has zero parameters and the schema coverage is 100% (vacuous), so the baseline is 4. The description's focus on when and how to use the tool is sufficient; there are no parameter meanings to clarify beyond the empty 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 action with resource: 'Explain how to get Gemalli pricing.' It clearly distinguishes itself from catalogue tools by noting manufacturer goods prices 'stay available through the catalogue tools,' which separates it from siblings like search_products or get_product. Despite the tool name 'get_subscription_plans,' the description unambiguously frames its purpose as explaining pricing access, not returning plan data.

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 states when to call: 'Call this when the person asks what Gemalli costs.' It provides a clear exclusion: 'Do NOT state, estimate, guess or recall any price...' and points to alternatives for manufacturer goods prices via 'catalogue tools.' This is direct when/when-not guidance with an alternative category, leaving no ambiguity.

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 cover the safety profile (read-only, not destructive, not open-world); the description goes far beyond them, disclosing that anonymous access is a valid non-error result, that previous_guest/linked_at carry conversation-link semantics, that buy_url null means no payment page, that credits null must never be offered, and that it never returns another party's data or secrets.

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

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

Front-loaded with the purpose, and most sentences do work since there is no output schema to carry the return-value detail. However it is a single dense run-on paragraph mixing identity, billing, credits and privacy semantics with no structural separation, making it harder to scan than it needs to be.

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 carries the full burden of explaining return values, and it does so thoroughly (role, language, company, plan, guest/previous_guest, linked_at, credits, buy_url, action_costs, wallets and the low flag). Nothing an agent needs to interpret the response 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 takes no parameters and schema coverage is 100%, so the baseline is 4. There is nothing for the description to disambiguate beyond confirming the call takes no input.

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 resource (the current viewer's identity, role, interface language, company and plan) and is clearly distinguishable from all siblings, which are feedback, product, sanction and quote tools. An agent can tell what this returns 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 strong guidance on interpretation and downstream behavior ('call something free only when its credits is 0', 'prefer those [fresh wallets] over this first reading', 'send the person to Office Live' when buy_url is null), which implicitly tells the agent when this reading applies. It lacks an explicit 'call this when...' trigger, but the routing conditions relative to other answers are 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 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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description goes beyond them by disclosing the response envelope: count vs total, has_more semantics, the 50-item ceiling, and an explicit caution against concluding absence from a partial list. That is exactly the behavioral context annotations cannot carry.

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

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

Front-loaded with the purpose sentence, then use cases, then alternatives, then response-size semantics in a logically ordered progression. The pagination paragraph is slightly long but every clause carries operational value; little could be cut without losing guidance.

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 must carry return-value explanation, and it does: it names the fields returned (name, country, certifications, profile identifier) and fully explains the pagination envelope. Nothing an agent needs to call this correctly or interpret the result is missing.

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

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

Schema coverage is 100%, so both parameters are already documented, making 3 the baseline. The description adds meaning beyond the schema by tying locale to the returned text fields and confirming result ordering, plus restating the 50 cap in the pagination guidance.

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 ('List verified manufacturers published on Gemalli') and enumerates the returned fields and ordering ('newest first'). It explicitly distinguishes itself from search_products, so an agent can route without opening either schema.

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

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

Gives concrete invocation triggers quoted as user phrasings ('who makes X', 'which factories/producers/suppliers are on the platform'), an explicit disambiguation rule ('a question about companies stays this tool even when it names a product'), and names the alternative with its condition ('to find a specific product or filter goods by country, use 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?

Annotations already declare this a safe, read-only, closed-world call, so the safety burden is covered. The description adds genuinely non-obvious behavioral context: identity is derived from the visitor pass, guests are matched via conversation label, and cross-device invisibility is expected rather than a bug — this preempts a false-negative interpretation by the agent.

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 what is listed and for whom; the second sentence earns its place by heading off a misread of empty results. Slightly dense em-dash construction, but 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?

With no parameters and no output schema, the description carries only the identity/scoping burden, which it discharges well. It says nothing about result ordering, volume, or pagination, but for a zero-argument self-scoped list that is a minor gap.

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. There is nothing in the schema or description to clarify, and the description correctly spends its words on identity semantics instead of parameter detail.

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 ('List the feedback tickets') plus a clear scope ('of the current visitor', 'for the Workspace tab'), which separates it from ticket-scoped siblings like get_feedback_thread. It does not explicitly name an alternative tool, but the scoping does the differentiation work.

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 rather than stated: the agent is expected to infer 'use this to see your own feedback'. The description does usefully explain when results will be empty (guest on another device), but it names no alternative tool for reading others' or threaded feedback.

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?

Adds substantial behaviour beyond the annotations: unknown reason codes are dropped but the rating is still saved (reason_dropped: true), a later call replaces an earlier one, and target_ref is verified with ref_check values (verified/mismatch/unchecked/absent) while never causing the rating to be discarded. These are exactly the edge cases an agent needs and are not derivable from readOnlyHint/openWorldHint/idempotentHint.

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

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

Front-loaded with the core action, then each subsequent sentence delivers a distinct operational fact (replacement semantics, unknown-code handling, report/view_key gotcha, ref_check outcomes). No sentence merely restates the tool name or the title.

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, no-output-schema mutation tool, the description supplies the return-field semantics (reason_dropped, ref_check) and the failure-mode guarantees that would otherwise be missing. Combined with the rich schema descriptions, an agent has everything needed to call it correctly and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter rules the schema cannot express: target_ref for a report is the view_key and NOT the report_key because one report is read across many country pages, and reason_code must come from get_feedback_reasons. It doesn't touch several other parameters (signal, knowledge_ids, probe), so not a 5.

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 ("Record what a person thought of something the agent produced") and enumerates what can be rated: reply, export, report, email. This lets an agent distinguish it from siblings like add_feedback_message or create_feedback_ticket 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 clear timing guidance ("Send it as soon as they press the thumb") and explains that reason/comment may follow in a second call that replaces the first, plus points to get_feedback_reasons for codes. It stops short of naming exclusions or the sibling that handles a different case (e.g., add_feedback_message), so it lacks the when-not half 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?

Beyond the destructiveHint/openWorldHint annotations, it discloses the actual write semantics: human overwrites anything, model overwrites only model, newer wins within a source, unknown keys are reported but do not abort the rest, and a model write over a human-stated trait returns why: person_said_it with current. That is exactly the kind of behavior an agent cannot infer from structured fields.

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

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

Front-loaded and generally well ordered, but it is long and contains a literal duplicated fragment ('the person stated it, `model` if you inferred it.' appears a second time dangling after the overwrite rules). That repetition costs clarity on the single most important parameter.

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 write with no output schema, it covers the key whitelist, source semantics, overwrite conflict response, truncation limits in the schema, and the guest failure mode. Minor gaps remain: no statement of what a successful per-key answer looks like in full, or whether a returned unknown-key name means the call was partial.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the closed key whitelist, that source decides whether the write lands (not just a label), that value is a few words, and that recall is the one-line conversation outcome. It only stops short of operational detail such as what the per-key response looks like exactly.

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: store stable traits about 'THIS person' so the next conversation does not start from zero, and names what it is not (name/email/phone, enquiry product/volume). It does not name the obvious read counterpart get_person_memory, so sibling differentiation is implicit rather than explicit.

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

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

Gives explicit when-to-use (stable traits) and when-not (name, email, phone, product, volume, deadline, spec, with a reason for each exclusion), plus the guest case that returns sign_in_required. It also routes conflict handling: ask the person about the discrepancy instead of deciding for them.

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?

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), yet the description adds real behavioral context the annotations cannot: count vs total, has_more, the 50 cap, offset paging, and the explicit instruction not to report zero results from a partial slice. It stops short of stating result ordering, locale fallback behavior, or whether total reflects the same filters, so it is strong but not exhaustive.

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 most critical, failure-prone information (partial results) is front-loaded in the first two sentences, then purpose, then the sibling exclusion. It is on the long side and repeats the 50 limit and offset paging that the schema already carries, which is the only real waste.

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, zero-required search tool with no output schema, the description covers return contents ('product cards in the requested language with price range, minimum order and the supplier'), pagination semantics, and the downstream routing decision. Nothing an agent needs to call it correctly or to report results honestly is missing.

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

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

Schema coverage is 100% and the schema already documents every parameter, including the Incoterms 'any match' rule and the 1–50 limit range, so the description is largely restating field names ('free text, category, manufacturer, country of origin, maximum minimum-order quantity, maximum price or delivery basis'). It adds only modest meaning, such as framing price as a range and locale as affecting returned text; the baseline of 3 applies when the schema does the heavy lifting.

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+resource+corpus: 'Search wholesale products published on Gemalli,' followed by the exact filter dimensions. It explicitly separates itself from list_manufacturers by declaring 'this tool returns goods, and a list of goods is not an answer about companies.' An agent can route between the two without opening either schema.

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

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

Gives a positive trigger ('when the person is looking for GOODS to buy or source') and an explicit exclusion plus named alternative ('when the question is about the COMPANIES themselves ... use list_manufacturers instead'). It also supplies an interpretation rule for partial slices, which is a usage condition, not just a warning.

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.