FrankoX

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

The description adds useful behavioral context beyond annotations: the conversation is private and account-bound, content is untrusted, and it does not verify or enroll a company. However, despite destructiveHint=true, it does not explain what side effects occur, what persistent state is created, or why the operation is marked destructive.

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 tightly written sentences with no filler. The core purpose and consent requirement are front-loaded.

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

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

For a destructive, open-world creation tool with six undocumented parameters and no output schema, the description is too sparse. It leaves important details unstated, including what is returned, what persistent effects are created, and how request_key/client_message_id should be used.

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 0% across six parameters. The description only alludes to consent and company non-enrollment; it does not clarify text, language, request_key, client_message_id, or the consent object's required fields.

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

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

The description gives a specific verb and resource: 'Open a private account-bound agent conversation.' It is clearly distinct from sibling tools such as get_agent_conversation, list_agent_conversations, and reply_to_agent_conversation.

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 only usage condition mentioned is 'with explicit user consent.' It does not explain when to create a new conversation versus replying to an existing one, when to list/get conversations, or other prerequisites or exclusions.

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 a non-destructive, idempotent write in a closed world. The description adds meaningful lifecycle context: the draft is private and unverified, requires real company confirmation before authority, and needs independent review/publication permission before search visibility.

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 and front-loads the purpose before the lifecycle constraints. The second sentence is dense and slightly awkward ('before authority and independent review/publication permission'), but there is little wasted text.

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 complex write tool with nested objects and no parameter descriptions, the description adequately covers the tool's gating and privacy posture but does not compensate for the missing parameter semantics. It is minimally complete rather than fully sufficient.

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 0%, so the description must clarify parameters, but it only indirectly references the consent requirement. It adds no meaning for idempotency_key, referral_source, or the nested profile fields, leaving most parameter semantics to inference from the raw 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 (Submit) and resource (manufacturer draft), with clear qualifiers: explicitly consented, private, and unverified. It does not differentiate from the sibling update_manufacturer_draft or register_manufacturer_interest, so it falls short of a 5.

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 prerequisites such as real company confirmation and publication permission, but it never says when to use this tool versus create_agent_conversation, register_manufacturer_interest, or update_manufacturer_draft. It provides condition-level context but no alternative routing 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description's one contribution beyond that is the access-scoping constraint (only the authenticated client/customer's own conversation), which is meaningful, but it says nothing about authorization failure behavior or what is returned.

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 short sentence with the read-only scope front-loaded and no padding. The phrasing is slightly tangled ('client and customer account's'), costing a bit of immediacy, but nothing is wasteful.

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 rich annotations and no output schema, the description covers enough to act, but it omits the key gap: how thread_id is sourced (presumably from list_agent_conversations) and that a non-matching thread is rejected. Those omissions are the difference between adequate and complete.

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

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

Schema description coverage is 0% and the single required parameter thread_id has no documentation in the schema, so the description must compensate — and it does not. It never mentions thread_id, its provenance, or its 36-character format, leaving the agent to infer how to obtain a valid identifier.

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 verb ('Read') and a resource ('conversation'), and the qualifier 'own' signals it returns a single conversation scoped to the caller rather than a collection. It never states that it retrieves by thread identifier, and the awkward phrasing ('the authenticated client and customer account's own conversation') leaves the exact subject of the read fuzzy, so it only weakly separates itself from get/list siblings.

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?

'Read only ... own conversation' implies single-item retrieval, which hints at the boundary against list_agent_conversations, but no sibling is named and no condition is given for choosing one over the other. There is also no guidance on when the call fails, e.g. when the thread belongs to another account.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety bar is covered. The description adds two things beyond them: the profile must be 'verified opt-in' (an access precondition) and the response deliberately omits private contacts and documents, which is meaningful output-scope disclosure.

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 front-loaded sentence with the resource, the key constraint, and the privacy boundary; nothing is redundant or 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 one-parameter read tool with no output schema, the description covers access conditions and output boundaries well. The remaining gap is provenance for record_id, which an agent needs in order to actually obtain a valid ID.

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 0%, so the description must carry the load; calling the ID 'opaque' correctly tells the agent not to parse or synthesize it. However it never says where a valid record_id comes from (a search result, presumably) or what form it takes, despite the schema's 1-36 char constraint.

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?

Specific verb (Retrieve) plus resource (verified opt-in public company profile) and access condition. It is distinguishable from get_public_product_profile by resource type, though the description never names that sibling to reinforce the split.

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 phrase 'verified opt-in public profile' implies the tool only applies to opted-in entities, which is useful context, but there is no explicit when-to-use/when-not guidance and no pointer to an alternative (e.g., search_manufacturers) for non-opted-in or enumeration cases.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world. The description goes further by disclosing the data-scoping behavior: only verified, opt-in records are returned and no private contacts or documents are exposed. It does not say what happens on a non-verified or missing ID, which is the remaining behavioral 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?

A single compact sentence with the resource scope front-loaded and the privacy guarantee appended. No filler and nothing redundant.

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 with full annotation coverage, the core is present. Still missing are the shape of the returned profile (no output schema exists) and the behavior on missing, unverified, or non-opted-in records, which an agent needs to handle failures 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 0%, so the description must compensate; 'opaque ID' is useful because it tells the agent the record_id is not a human-readable key. However, it never maps the term to the record_id parameter or notes the 1-36 character constraint, leaving partial compensation only.

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: 'Retrieve a verified opt-in public profile by opaque ID.' The resource name ('product' profile) implicitly distinguishes it from the sibling get_public_company_profile, though it never says so explicitly.

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

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

Usage is only implied: you call it with an ID to read a public profile. There is no stated condition for choosing this over the near-identical get_public_company_profile sibling, and no guidance on what to do when a record is not verified or not opted in.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context the annotations lack: results are auth-scoped to the calling client and customer account. It does not explain what 'bounded' means operationally (result cap, pagination, ordering), which matters for a list tool.

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 front-loaded sentence with no filler; the scope constraint follows the verb and resource. Nothing is wasteful, though the terseness is the same trait that leaves gaps elsewhere.

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?

A one-param read tool with strong annotations and no output schema does not need much, and the auth-scoping note is a real addition. Still missing: whether the result is a bare array, ordering of conversations, and what 'bounded' enforces — all of which an agent needs to call this correctly the first time.

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 0% and the single 'limit' parameter is documented in the schema only by type and a 1-20 range. The description's 'bounded' is the sole nod to result sizing, and it is ambiguous — it could refer to pagination windows or a fixed cap rather than to the 'limit' parameter. It does not compensate for the coverage gap.

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?

Specific verb (List) and resource (private conversations) with an explicit scope: 'for this authenticated client and customer account'. This implicitly separates it from get_agent_conversation (single) and create_agent_conversation (write), though no sibling is named. Clear enough to select 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?

No statement of when to use this versus get_agent_conversation or when to prefer it over creating a conversation. The word 'private' hints at a visibility boundary but neither prerequisites nor exclusions are stated. Usage must be inferred from the one-line purpose.

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 write, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: a human-consent gate and the fact that no enrollment or verification side effect occurs, which an agent cannot infer from 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?

Two short sentences with no filler, and the approval constraint is front-loaded before the scope negation. Every clause carries 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 write tool with a complex nested schema, no output schema, and 0% parameter documentation, twelve words is thin. Nothing covers idempotency behavior, the purpose enum choice between DRAFT and INTEREST, or what the caller gets back after recording.

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 0% across 3 required params, including a nested consent object and a nested MultilingualText company_name. The description only thematically gestures at the consent requirement; it says nothing about idempotency_key semantics, the consent.purpose enum values, or the multilingual name structure, so it does not compensate for the coverage gap.

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 interest') and immediately bounds it with 'Does not enroll or verify a company,' which separates it from enrollment/verification flows. It doesn't explicitly distinguish it from the closest sibling, create_manufacturer_draft, so it stops short of a 5.

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 precondition ('only after explicit user approval') and a clear exclusion ('does not enroll or verify'), so the agent knows the gating condition. It never names the alternative sibling to use when the user actually wants a draft or enrollment, leaving the routing implicit.

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 destructiveHint=true, openWorldHint=true, and idempotentHint=false, but the description does not explain the destructive behavior, whether replies are appended or overwrite content, or how conflicts are handled. "No authority changes" is useful reassurance, but it does not compensate for the missing disclosure around the destructive annotation and non-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?

A single compact sentence that front-loads the action and scope. It is efficient, though its terseness contributes to the missing parameter and behavioral 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?

With five required parameters, no output schema, and annotations indicating a destructive, non-idempotent, open-world mutation, the description is too thin for correct invocation. It should explain at minimum the roles of revision and client_message_id, the append semantics, and any failure/conflict 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?

Schema description coverage is 0% for all five required parameters, and the description only indirectly maps to thread_id via "existing conversation." It does not explain text, language, revision, or client_message_id, even though revision and client_message_id appear to carry important concurrency/idempotency semantics.

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 ("Reply") and resource ("existing account-bound conversation"), making clear it operates on an existing thread rather than creating or listing one. It does not explicitly name sibling tools, but the wording distinguishes it from create_agent_conversation, get_agent_conversation, and list_agent_conversations.

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 phrase "existing account-bound conversation" implies it should be used only for threads that already exist, and "no external outreach" sets a scope boundary. However, it does not say when to use this versus create_agent_conversation or get_agent_conversation, nor does it mention prerequisites such as having a valid thread_id.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description usefully adds that only public projections are touched and that no scoring changes or autonomous research occur, reinforcing data-scope boundaries beyond the annotations. It still leaves the actual matching/filter behavior opaque.

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?

Only two short sentences, so nothing is bloated. However, the front-loaded sentence is the least informative part, and the second sentence is framed entirely as negation, spending the limited budget on what the tool is not rather than what it does.

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 13 undocumented parameters, no output schema, and no explanation of return shape or matching semantics, the description is nowhere near sufficient for correct invocation. An agent would have to guess at filter semantics and result format.

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 0% across 13 parameters (moq, country, product, capacity, keywords, hs_cn_code, certification, specification, source_language, preferred_language, canonical_concept_id, delivery_geography, limit). The description adds no meaning for any of them — no format hints, no interaction rules, no indication of which filters combine or are recommended.

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 phrase "Filter only permitted public opportunity projections" hints at filtering public opportunity data, but the wording is jargon-heavy and never states plainly that this performs an opportunity search/match. It offers no differentiation from the sibling `search_opportunities`, so an agent cannot tell which to choose.

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

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

There is a scope exclusion (only permitted public projections, no private/customer matching), but no positive guidance on when to use this instead of `search_opportunities` or the other search_* siblings. The agent must infer the triggering conditions entirely.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior. The description adds useful provenance/scope context ('only verified opt-in public') and a data-interpretation caveat ('no availability or demand inference'). It does not describe result shape, pagination, or matching behavior, so the added value is modest.

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?

It is a single front-loaded sentence with no filler, so it is concise and structurally efficient. The brevity is not wasted, though it leaves substantial gaps addressed under contextual completeness.

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 13-parameter search tool with no output schema, the description covers only a broad scope constraint. It gives no filter usage guidance, no return format expectations, and no indication of how results relate to the many sibling search tools. Annotations cover the safety profile, but the description is far too thin for the tool's complexity.

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 13 parameters with 0% schema description coverage, and the description provides no information about any of them. With no parameter semantics in the schema and none added by the description, an agent has no guidance on how filters such as moq, capacity, hs_cn_code, canonical_concept_id, or source_language should be used.

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 verb and resource ('Search ... manufacturer projections') plus a data scope ('verified opt-in public'). However, 'projections' is undefined jargon, and it does not differentiate this tool from siblings like search_suppliers, search_products, or search_opportunities. The purpose is inferable but not crisp.

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

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

There is no explicit when-to-use guidance, no alternatives named, and no prerequisites. The phrase 'no availability or demand inference' is a caveat about interpretation, not a routing rule for choosing this tool over a sibling.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuine value beyond them by disclosing that returned profiles are 'abstract' and that private counterparties/contacts are stripped. It omits result ordering, pagination behavior (default 10 / max 20), and whether all filters combine with AND semantics.

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 tight sentence with the key scoping fact front-loaded and no filler. It is efficient rather than verbose, though its brevity borders on under-specification given 13 undocumented parameters.

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 13-parameter search tool with no output schema and no parameter descriptions, the definition does not say what filters exist, how results are ranked or truncated, or what a returned profile contains. An agent could call it, but only by guessing at most of the query surface.

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 has 13 parameters with 0% description coverage, so the description carries the full burden and supplies nothing about them. Self-explanatory names like 'country' and 'product' help slightly, but ambiguous ones ('capacity', 'moq', the 'source_language' vs 'preferred_language' pair, 'canonical_concept_id', 'delivery_geography') are left entirely undefined.

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

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

Names a specific verb and resource ('Search ... abstract public opportunity profiles') and flags that results exclude private counterparties and contacts. It is distinguishable from the sibling search_* tools by resource, though it never explicitly contrasts itself with search_manufacturers, search_products, or request_opportunity_match.

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?

Says nothing about when to pick this tool over search_manufacturers/search_products/search_suppliers or the state-changing request_opportunity_match. The only scoping statement ('private counterparties and contacts excluded') describes what results contain, not when to use the 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 declare readOnly, idempotent, non-destructive and closed-world, and the description's 'verified opt-in public' is consistent with openWorldHint=false while adding real information: unverified or non-consenting profiles are excluded from results. Nothing is said about match behavior, ranking, result counts, or empty-result handling.

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 front-loaded sentence with no filler. It is efficient, though the terseness is under-specification rather than true economy given the 13-parameter surface.

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 faceted search with 13 optional filters, no output schema, and no parameter docs, the description omits matching semantics (exact vs fuzzy/keyword), how filters combine (AND vs OR), pagination beyond limit's cap of 20, and result ordering. An agent can call it but cannot predict what it will get back.

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?

13 parameters at 0% schema description coverage and the description explains none of them. Cryptic names like moq, hs_cn_code, canonical_concept_id, and especially the source_language vs preferred_language pair (query translation vs result language) are left entirely unexplained, so an agent must guess.

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

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

States a specific verb ('Search') and resource ('product profiles') plus a scope qualifier ('verified opt-in public'), which separates it from search_manufacturers/search_suppliers/get_public_product_profile. It does not say what attributes are searchable, but the core identity of the tool is unambiguous.

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?

'only verified opt-in public' is a corpus restriction, not usage guidance; it tells the agent what it cannot find but not when to pick this over search_opportunities, search_suppliers, or search_manufacturers. No exclusions, prerequisites, or alternative routing are given.

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 caveat that existence does not establish available stock is genuinely useful behavioral context that annotations do not convey. Beyond that, nothing is disclosed: no ranking or sort behavior, no result size expectations, no statement that all 13 filters are optional and combinable, no indication of what a match is scored on.

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 front-loaded sentence with no filler, and the most important caveat is attached immediately. The wording 'candidates' is slightly opaque, keeping it from a 5.

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?

A 13-parameter, zero-description-coverage search tool with no output schema needs far more: what a result looks like, how filters combine, and how this differs from the other search_* siblings. The single sentence leaves the agent guessing on nearly everything except that results are not stock guarantees.

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 0% across 13 parameters, and the description says nothing about any of them. Ambiguous fields such as canonical_concept_id, source_language vs preferred_language, capacity, and delivery_geography receive no interpretation, leaving the description to compensate entirely and failing to do so.

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 verb (Find) and a resource (public manufacturer/supplier profile candidates), so the general purpose is graspable. But 'candidates' is vague and there is no differentiation from the sibling search_manufacturers or get_public_company_profile, which an agent must distinguish this from.

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 never says when to use this rather than search_manufacturers, search_products, or get_public_company_profile. The only guidance is a negative caveat that a hit does not imply stock, which is a clarification about results, not about tool 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 flag this as non-read-only, destructive and non-idempotent, so the safety bar is lower. The description does add real context with 'optimistic revision checks', telling the agent that a stale revision will fail the call. However, it never clarifies whether 'update' replaces the whole draft profile or merges fields, which is exactly what makes the operation destructive here.

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 front-loaded sentence with no filler, but its brevity is achieved partly by omitting the operation's semantics rather than by tight editing.

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 and annotations only cover safety flags, so the description must explain conflict behavior and update semantics; it does neither. An agent knows what to call but not what a revision mismatch returns or whether omitted fields are cleared.

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 0%, so the description must carry the burden. It only hints at the meaning of 'revision' (optimistic concurrency) and says nothing about draft_id or the required full 'profile' payload, leaving two of three required parameters undocumented anywhere.

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 ('Update ... draft') plus meaningful scope: the authenticated submitting agent's own unconfirmed draft. It does not explicitly contrast with create_manufacturer_draft, but the name/verb pairing makes the operation distinguishable from a creation tool.

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 word 'unconfirmed' implies a precondition (only drafts not yet confirmed can be updated), but there is no explicit when-to-use guidance, no mention of the sibling create_manufacturer_draft, and no statement of what to do when the draft is already confirmed.

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