EximAgent

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the threshold-spike mechanism, but leaves the key behavioral question unanswered: what the threshold is, whether it is fixed, and how sensitive the flagging is.

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

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

Two sentences, no filler, with the core behavior front-loaded and the usage note trailing. Every clause earns its place.

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

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

Output schema exists, so return values need no explanation, and annotations cover safety. However, the description's central concept (a threshold) is never defined and has no corresponding parameter, and the relationship to exim__market__anomalies is unaddressed, leaving a real gap for an agent deciding how to invoke 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%, so the schema fully documents hsCode, measure, originCountry, and destinationCountry with formats and defaults. The description only restates the filter dimensions already in the schema, adding no syntax or semantic value beyond it. 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+resource: flags months where a measure spikes or drops past a threshold, scoped to a destination/origin/HS code corridor. Clear enough for an agent to understand what it returns, but it never distinguishes itself from the sibling exim__market__anomalies, which reads as the same concept without the corridor scoping.

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?

"Use it to spot unusual movement in a corridor" implies the usage context but gives no when-not conditions, prerequisites, or alternatives. An agent choosing between this and exim__market__anomalies or exim__analytics__query gets no routing signal.

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 a closed-world read, so the safety profile is covered. The description adds that the output is a static reference containing coverage, filters, time windows and worked examples, but says nothing about size, pagination, or freshness/versioning of the catalog.

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, zero waste: the content of the catalog comes first, the routing instruction second. Nothing repeats the title or the schema.

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 an output schema present, return values need not be explained, and the parameters are fully covered by the schema, so the description only needs to establish purpose and routing — which it does. It stops short of noting any preconditions such as dataset scope or whether the catalog is version-specific.

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 the `field` and `section` parameters are already documented, including the section enum. The description's mention of 'coverage, allowed filters and time windows' loosely maps to the section enum values but adds no syntax or format detail beyond the schema — 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 — it lists analytics fields plus their coverage, filters, time windows, and examples — which an agent can distinguish at a glance from the query/sql executors in the same family. The scope of the resource (metadata catalog vs. data results) 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?

Explicitly routes the agent: 'Call it before building an analytics query or SQL so you use valid fields,' naming the sibling alternatives and the precondition that selects this tool. It does not state a when-not-to-use case (e.g., skip if field names are already known), so it falls just short of full 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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds one genuinely useful behavioral fact — results are deduplicated — but says nothing about paging behavior, caps, or cost, which the schema only partially covers (offset requires orderBy).

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, output shape first, usage second, zero filler. Well 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?

Output schema and rich parameter descriptions carry the return-shape and query-syntax burden, and annotations cover safety. The description is nearly complete for this complexity; only routing against the SQL/anomalies siblings is left implicit.

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% and the spec/filters/measures/groupBy/timeWindow parameters all carry their own descriptions and examples. The description adds no parameter-level meaning beyond that, so 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 (returns aggregates), the exact metrics (shipment count, value, weight, price per kg, unique buyers/sellers) and the group-by dimensions (HS code, country, company, month, year). An agent can tell this is a general aggregation engine, though it never names a sibling (e.g. analytics__sql) to contrast with.

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?

Use cases are stated (market sizing, rankings, totals), which implies when to reach for it. However, with siblings like analytics__sql, analytics__anomalies, market__growth and market__compare, there is no explicit 'use X instead when...' guidance, so the agent must infer boundaries.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful operational constraints beyond annotations: raw fact tables require a WHERE clause and results are row-limited.

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 tight sentences with the core purpose and key constraints front-loaded. Every clause carries useful information with no repetition.

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

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

For a read-only SQL tool with an output schema and full parameter documentation, the description covers the important constraints: read-only, single SELECT, allowed tables, WHERE requirement, row limits, and the fallback sibling. It does not enumerate allowed tables, but the catalog sibling likely covers that.

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 each parameter is already documented, so the baseline is 3. The description adds a general SQL constraint about raw fact tables needing WHERE, but does not expand on limit or offset semantics 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 and resource: running one read-only SELECT over allowed trade tables. It also distinguishes the tool from the analytics query sibling by explaining when SQL is needed instead.

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 condition for choosing this tool: use it when the analytics query cannot express the question. However, it does not name the exact sibling or state additional exclusions, so it falls short of the most complete 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that every company is scored and each gets one-sentence reasoning, but with an output schema present even this is partly redundant, and it says nothing about cost, latency, or limits on collection size.

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 that conveys action, scope, input, and output with zero filler. Nothing to trim.

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 full schema coverage, an output schema, and annotations covering the safety profile, the description is nearly sufficient. The only real gap is routing guidance versus the other ranking tools (profile-match__rank, employees__rank), which the definition never addresses.

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 collectionId, question, and rankingCriteria; baseline is 3. The description restates 'plain-language question' but adds no syntax, format, or weighting semantics, and never mentions the optional rankingCriteria parameter.

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

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

States a specific verb (ranks), resource (every company in a collection), and the driving input (a plain-language question), plus the output shape (0-100 score + one-sentence reasoning). This distinguishes it from collection__get/list and from the profile-match__rank / employees__rank siblings, though no sibling is named 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?

No when-to-use or when-not-to-use guidance, no alternatives named, and no prerequisites stated (e.g., that the collection must already exist and contain companies). The agent must infer the scenario from the purpose sentence alone.

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=false, destructive=false, idempotent=false; the description adds real context beyond them by stating the copy is *independent* (later edits don't propagate) and that 'the source is unchanged'. It does not mention required account permissions or behavior on name collisions.

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 tight sentences with zero filler, front-loading what is copied and then the non-destructive guarantee. Nothing needs to be trimmed.

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 full annotations and an output schema, the description covers scope, source immutability, and target prerequisites. Minor gaps remain around permission requirements and naming-conflict handling, but these are not blocking 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%, but the `to` property's schema text ('Latest month, YYYY-MM.') is misleading for a destination-account field; the description's 'another existing account' corrects that misreading. It confirms the name default and adds that the copy target must already exist, though it leaves the accepted identifier form (name vs id) for `to` unstated.

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 ('Copies a collection ... as an independent copy') and states what is carried over (items, columns, provenance), which distinguishes it from collection__create and collection__get. It stops short of explicitly naming a sibling to route against, but the scope 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?

Usage is implied rather than stated: 'to another existing account' signals the prerequisite of a target account, but there is no explicit when-to-use/when-not guidance or comparison to create/get/list. An agent can infer the scenario but must reason about it.

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=false, destructiveHint=false, and idempotentHint=false. The description adds useful context ("empty," optional default template, manual-prospecting use), but does not disclose the non-idempotent implication (repeat calls create separate collections) or any auth constraints.

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 packed sentences with the core purpose front-loaded and the routing guidance second. No filler or 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?

With an output schema present, return values need not be explained, and the description covers purpose, scope, and the key alternative. It is essentially complete for a simple create tool, with only minor behavioral gaps (duplicate handling).

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 all four parameters (name, description, businessType, templateName) are already documented in the schema, including the export/import enum and the template-existence note. The description adds no parameter detail beyond this, 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 ("Creates an empty collection") and clarifies the resource with a parenthetical ("a company list"). It further scopes the intent to "manual prospecting," which distinguishes it from discovery-oriented siblings like exim__search__run.

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 routes the agent to an alternative: "For automated discovery use search run." This is a clear condition-based exclusion, though it doesn't spell out when-not to create a collection (e.g., duplicate handling or preconditions).

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 and destructiveHint=false, covering the safety profile. The description adds the contents of the returned metadata, but with an output schema present that is largely redundant and it says nothing about auth or scope limits. With annotations doing the heavy lifting, a 3 is appropriate.

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

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

Two tight sentences, zero filler, with the purpose stated first and the routing alternative second. Every clause earns its place.

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

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

For a simple read-only get with full annotation coverage and an output schema, the description supplies what an agent needs to select and call it. Nothing critical is missing, though it does not address pagination or edge cases.

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% and the single parameter is documented in the schema as 'Collection name or id'. The description adds no syntax, format or naming guidance beyond what the schema already provides, so 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 (returns) and resource (a collection's metadata) and enumerates the fields returned: name, totals, priority counts and status. It also routes the agent away from using this tool for company rows. It stops short of a full sibling differentiation (e.g., vs collection__list or collection__analyze), so 4 rather than 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?

Explicitly names an alternative ('Use collection items list for the company rows') with the condition that selects it, which is genuine when-to-use guidance. No explicit when-not or prerequisites beyond that single routing hint, so it does not reach the 5 bar.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is largely covered. The description usefully adds the implicit side effect that a company record is created when only a URL is supplied, but it omits that repeated calls are non-idempotent and can produce duplicate collection rows.

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 that packs the verb, resource, identifier options, side effect, and optional fields without filler. It is efficient, though the omission of the collection-identifier requirement is a content gap rather than verbosity.

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 8-parameter write tool with complex not/anyOf schema constraints and zero formally required parameters, the description covers the company side but never mentions that either collectionId or collectionName is mandatory. An agent relying on it alone could easily submit a call with no collection identifier, which the opaque schema would then reject.

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 all eight parameters, giving a baseline of 3. The description restates the companyId/companyUrl choice and the optional priority and product fields but adds no format or constraint detail 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?

Clear specific verb+resource: adds a company to a collection, and it names the two acceptable company identifiers plus the implicit-create behavior. It does not explicitly distinguish itself from siblings like exim__collection__create or exim__collection__items__list, 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 implies usage via 'by company id or website URL', which hints at the alternative acceptance paths, but it never states when to prefer one over the other, when not to call it, or how it relates to sibling tools such as collection copy-to or create.

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 behavior, so the safety profile is covered. The description adds the shape of returned data and the presence of filters/paging, but says nothing about page-size behavior, ordering defaults, or the fact that full enumeration requires carrying a cursor forward — details only found 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?

One front-loaded sentence with zero filler; the returned fields come before the filter/paging mention. It stops short of being underspecified, but the terseness is a deliberate trade-off rather than padding.

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?

An output schema exists and the rich input schema documents paging, ordering, and the collectionId/name duality, so much of the burden is carried elsewhere. For an 11-parameter listing endpoint, however, the description gives no orientation on how collectionId vs name, or column vs value, relate, and offers nothing on cursor-based enumeration.

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 per-parameter meaning is already documented, and the description's mention of filters and paging is a light topical pointer rather than new detail. Baseline is 3 under full coverage; the field list ('score, priority, country, contacts and outreach stage') corresponds to the priority/stage/column/value filters, giving modest added orientation.

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 (lists company rows in a collection) plus the fields returned (score, priority, country, contacts, outreach stage), which distinguishes it from collection-level siblings like collection__get or collection__list. It does not explicitly differentiate from exim__companies__list, but the collection scoping is clear enough on its own.

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?

Use is only implied by 'with filters and paging'; there is no statement of when to choose this over exim__collection__get, exim__companies__list, or collection__analyze, and no prerequisites or exclusions. An agent can infer it is the row-level reader for a collection, but nothing routes it away from alternatives.

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 as a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: results are ordered most recent first. It says nothing about pagination semantics beyond the word 'paging', which the schema already handles via cursor/limit.

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 zero filler. The ordering and paging facts are stated immediately and nothing is wasted.

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 an output schema present, return values needn't be described, and annotations cover the safety profile. Ordering and paging are noted. The gap is minor: it doesn't confirm that all filters are optional or note the deleted-collections default, though the schema covers those.

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 all eight parameters with enums and defaults. The description adds no parameter-level detail (e.g., it doesn't explain the q/sort/facets JSON semantics), so the baseline of 3 for fully covered schemas 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 (Lists) and resource (your collections) plus the default ordering and paging behavior. It's clear what the tool does, but it never differentiates itself from nearby siblings like exim__collection__get or exim__collection__items__list, so an agent must infer the boundary.

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 when-to-use guidance and no alternatives named. There is no indication of when to prefer this over collection__get or items__list, or of any prerequisite scope/permission. The only hint is the implicit 'yours' scope.

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

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

Annotations already establish that this is a safe, read-only, idempotent operation. The description adds useful behavioral context by defining the comparison basis (same HS codes and country, with overlap and volume versus this company), though it does not mention identity requirements or result edge cases.

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

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

Two sentences, front-loaded with the core behavior, and the alternative routing is concise. Every sentence contributes directly to tool selection and interpretation.

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

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

Given annotations, full schema descriptions, and an output schema, the description covers the essential purpose and the main alternative. It leaves some sibling differentiation implicit, especially against companies similar/suppliers/customers, but is otherwise complete enough for correct invocation.

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

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

Schema description coverage is 100%, and the schema itself explains name, taxId, country, and limit. The description supports the country/company framing but does not add syntax or selection guidance beyond the schema, so it meets the baseline rather than exceeding it.

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

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

The description gives a specific verb and resource: it lists companies importing the same HS codes into the same country, with overlap and volume compared to the target company. It also explicitly distinguishes itself from the profile-match tools, so an agent can separate this from weighted-fit scoring workflows 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?

It clearly directs weighted fit-score use cases to the profile-match tools, which is a strong explicit alternative. However, it does not differentiate this tool from closely related siblings like companies similar, suppliers, or customers, so some selection guidance is still inferred.

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 and closed-world, so the safety profile is covered. The description usefully enumerates the payload (shipments, shared HS codes, first/last seen, share of exports), but says nothing about the identity-resolution requirement (taxId or name, as enforced by the schema) or what happens when no match is found.

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

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

A single sentence that front-loads the resource and its ranking, then lists the returned fields. 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?

An output schema and rich annotations carry most of the weight, but the description omits how the company is identified (taxId preferred, or name+country), how truncation at the default limit of 100 behaves, and the empty-result case — the gaps an agent would most likely hit.

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%, with taxId flagged as 'the strong identity key', name scoped by country, and limit bounds documented. The description adds nothing beyond the schema, so 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 ('Lists the importers a company sells to') and adds the ordering key ('ranked by value'). The downstream direction distinguishes it implicitly from the sibling suppliers tool, but it never names an alternative 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?

There is no when-to-use / when-not-to-use guidance and no mention of when to prefer suppliers, competitors, graph or profile instead. The only usage signal is the implied 'tell me who a company sells to', leaving all routing decisions to inference.

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, closed-world and non-destructive, so the safety profile is covered. The description contributes real content about the analytical outputs (competitor count, shared-supplier peers, single-source risk), but says nothing about result sizing (the limit cap of 1000/default 100) or that identity resolution drives which company's graph 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 dense sentence with no filler, leading with what is returned. Slightly list-like, but every clause corresponds to a distinct output the agent will receive.

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 an output schema present, the description needn't explain return values and annotations cover safety, so the remaining gaps are the ones that matter most here: when to use this versus the per-relation siblings, and how the company is identified. Adequate but incomplete for a tool in a crowded sibling cluster.

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 parameter documentation bar is met by the schema itself and baseline 3 applies. The description adds nothing on parameters and does not clarify the non-obvious requirement that taxId OR name (+country scoping) must be supplied, which the schema expresses only as a cryptic anyOf/not 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?

The description names a specific verb and resource and enumerates the exact payload (top suppliers/customers, competitor count, shared-supplier peers, concentration risk), so the agent knows precisely what comes back. It does not, however, distinguish this bundled network view from the very similar siblings exim__companies__suppliers, exim__companies__customers and exim__companies__competitors.

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 statement of when to prefer this aggregate over the individual sibling tools, nor any prerequisites. An agent choosing among graph/suppliers/customers/competitors/similar gets no routing signal from the description.

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 adds that results are 'resolved' companies with a trade profile, which is useful context, but says nothing about ordering, pagination beyond the limit param, or what an empty result means.

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 verb and resource up front and filter axes in a trailing clause. The filter enumeration largely duplicates what the schema already labels, slightly diluting an otherwise tight definition.

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?

An output schema and rich annotations carry most of the weight, so the definition is nearly sufficient. The notable gap is that no parameters are required, yet the description never says whether country/hsCode are effectively mandatory or what an unfiltered call returns, nor what 'resolved' presupposes.

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 explains hsCode padding, ISO2 country codes, role enum and the YYYY-MM date format in more detail than the description. The description only recaps those dimensions at a high level, adding no syntax or constraint information of its own.

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 ('Lists resolved companies trading an HS code in a reporting country') and adds the return shape ('each with its trade profile'). It never distinguishes itself from near-siblings like companies__suppliers, companies__customers or companies__competitors, so an agent must infer the difference.

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 by the HS-code-plus-country scoping, and the filter list gives a hint of how to narrow results. There is no explicit when-to-use, no when-not-to-use, and no pointer to the sibling tools that retrieve similar company sets.

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, so safety is covered. The description adds the identity-priority rule (tax id is the strong key) and the fields returned, but says nothing about failure behavior, ambiguity resolution, or cost/latency.

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 tight sentences: the first front-loads what is returned, the second covers identity. No filler, no repetition.

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

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

With an output schema present and annotations covering the safety profile, the description only needs to carry the invocation contract, which it does. It is slightly thin on what is returned when identity is ambiguous or no record matches, but 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 description coverage is 100%, and the schema already labels taxId as 'the strong identity key' and name as 'used with country when no tax id'. The description largely restates that, adding no format or syntax detail 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?

States a specific verb and resource ('Returns one company's trade profile') and enumerates the payload contents — HS codes, corridors, counterparties, recurrence — which distinguishes it from siblings like exim__companies__list, exim__companies__graph and exim__company__shipments.

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 explains how to identify the company (tax id, or name plus country), which is useful invocation context, but never says when to choose this over adjacent tools such as exim__company__resolve or exim__companies__graph, nor what happens on a miss.

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 contributes one genuinely useful behavioral fact — results are ranked by HS-code overlap and volume — but says nothing about how many are returned by default, how the seed company is required, or how ties are handled.

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 well-formed sentence with the ranking behavior front and center. Minor waste in the opening 'Same result as companies competitors' framing, which is a sibling comparison rather than a statement of what the tool 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 an output schema and full annotations present, the description does not need to explain return values, and it correctly conveys the ranking concept. It is incomplete in one respect that matters for invocation: nothing tells the agent that a seed identity (taxId, or name plus country) is required to get any result, a constraint buried in a hard-to-read anyOf/not 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%: taxId is labeled the strong identity key, name is used with country when no tax id, country is the ISO-2 scope, and limit defaults to 100. The description adds nothing beyond that, so baseline 3 applies. It notably does not surface the at-least-one-of taxId/name constraint expressed in the schema's anyOf, though that is schema's job.

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 and semantics: companies trading the same HS codes into the same country, ranked by overlap and volume. It also names its sibling (companies competitors), which makes the relationship explicit. It falls short of 5 only because leading with 'Same result as companies competitors' makes the tool read as an alias rather than stating on its own terms when an agent should pick it over that sibling.

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 cross-reference to companies competitors implies the two are interchangeable, but it does not say when to use this versus companies__customers, suppliers, graph, or profile-match__lookalike, all of which sit in the same 'find related companies' space. Usage is implied, not directed.

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, closed-world and non-destructive, so the description is free to add behavioral value — and it does, disclosing that results are ranked by value and annotated with shipment counts, shared HS codes, first/last seen dates, and import share. It doesn't say what happens on ambiguity or how ranking handles ties, but for a read tool that is a minor gap.

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

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

A single dense sentence with the resource front-loaded and the returned metrics trailing as modifiers. Nothing is repeated and nothing is wasted.

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 rich annotations, a fully described schema and an output schema, the description only needs to frame the return content — which it does. The one omission is guidance on identity resolution (taxId vs name+country), though that is partially carried by the schema descriptions.

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

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

Schema description coverage is 100%, so each parameter (taxId, name, country, limit) is already documented in-schema, including the 'strong identity key' note on taxId. The description adds no parameter-level meaning beyond 'a company buys from', 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 — 'Lists the exporters a company buys from' — and pins down the direction of the relationship (upstream suppliers), which quietly separates it from the sibling companies/customers tool. It also enumerates the payload (shipments, shared HS codes, first/last seen, share of imports), so an agent knows exactly what it gets.

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 by the name and purpose: an agent can infer 'call this when I need a company's suppliers.' There is no explicit when-to-use, no named alternative (e.g. companies/graph for network context, companies/profile for a single entity), and no mention of the taxId-vs-name identity tradeoff that determines result quality.

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 safety and repeatability are covered structurally. The description adds that output includes a derived trend and peak months, which is mildly informative behavioral context, but omits anything about data range, latency, or behavior on missing/unknown company identity. An output schema exists, so return-value detail is largely redundant 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 that names the resource, the granularity options, and the key derived outputs with no filler. Every clause earns its place.

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

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

For a read-only, annotated tool with a full output schema and fully described parameters, the description covers what is returned and at what granularity. It does not mention the identity-resolution requirement (taxId as the strong key, or name + country) or the extent of history covered, leaving minor gaps.

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%, with taxId, name, bucket, and country all documented in the schema itself. The description only restates the month/quarter bucketing already covered by the bucket parameter, so it adds no syntax or format detail beyond the schema. 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?

"Returns one company's value and shipment series by month or quarter, with trend and peak months" states a concrete verb (returns) plus the exact resource and granularity, so the agent knows this is a per-company time series, not a market-level one. It distinguishes itself implicitly from trend-oriented siblings, but never names an alternative tool to disambiguate from exim__market__trend or exim__shipments__price-trend.

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 scope phrase "one company's" implies the use case (single-company historical trade analysis), but there is no explicit when-to-use, when-not-to-use, or named alternative. The agent must infer that market/route-wide trends belong to other 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld=false), so the description only needs to add context. It adds the notion of disambiguation hints, but says nothing about what happens on no-match, whether results are cached/stale, or how authoritative the profile is — with openWorldHint=false the agent may wrongly assume live web lookups.

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, delivering the return payload first and the disambiguation qualifier second. Slightly dense phrasing ('from its name') costs little but keeps it from perfect.

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 four well-documented params, an output schema, and rich annotations, the description's burden is narrow and mostly met: purpose and disambiguation are covered. The remaining gap is sibling disambiguation against resolve/profile/enrich, which matters heavily in a 70-tool 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?

Schema coverage is 100%, so each parameter already has a description; baseline is 3. The description contributes the rationale that the three optional fields exist to disambiguate the name, which is useful framing but not syntax or format detail 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?

Specific verb ('Returns') plus concrete resources (website, profile, summary) keyed off a company name, so an agent knows exactly what comes back. It does not differentiate itself from close siblings like exim__company__resolve, exim__companies__profile, or exim__enrich__company, which is the only thing keeping it from 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 clause 'with optional country, address and product hints to disambiguate' implies the usage context (ambiguous company names, supply extra signals), but no explicit when-to-use rule, no exclusions, and no named alternative such as resolve or enrich. Usage is inferable rather than stated.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuine value by disclosing that the result carries a graded confidence, a reason, and possible entity splits — implying one call may yield multiple entities. It stops short of stating cost, latency, or what happens when no match is found.

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, zero filler, with the core purpose front-loaded and the workflow hint second. Nothing redundant with the title or annotations.

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 a full schema, an output schema, and rich annotations, the description only needs to supply workflow placement, which it does. The one gap is the undefined notion of "escalate" — an agent cannot tell which sibling to escalate to from this text alone.

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 name, country and products are already fully explained with their disambiguation roles. The description adds nothing about parameter use beyond implying that a packed multi-entity name is acceptable, which the schema itself states.

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 ("Matches a company name to its website") and even previews the return shape (confidence 0-2, reason, entity splits). This clearly separates it from downstream tools like exim__enrich__company, which the description names.

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 ordering ("Use it before enrich company") and a conditional gate ("escalate only when the result says so"). The escalation target is left unnamed and the triggering condition is vague, so the routing advice is clear but not fully actionable.

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 covered. The description adds the substantive behavioral fact that both import and export directions are included, but says nothing about result truncation, the 100-row default cap, or pagination behavior.

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

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

Two short sentences, zero redundancy, and the core scope (exporter OR importer) is front-loaded before the use case.

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?

An output schema exists, so return values need no explanation, and the annotations cover safety. What remains thin is disambiguation from the many adjacent shipment tools and any hint about result volume — small but real gaps for a five-parameter, heavily-siblinged tool.

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 schema already carries parameter meaning, including the HS-code padding rule and ISO2 country codes. The description only restates that HS code and countries are filterable, adding no syntax or tie-breaking semantics of its own — baseline 3.

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

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

States a specific verb and resource (lists shipments) plus the scoping relation (the named company is exporter or importer) and the available filters. An agent can tell this is the company-anchored shipment lookup rather than a product- or route-anchored one, though it never names the sibling it is not.

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?

"Use it to see what a company actually ships" gives a positive use case but offers no exclusions, prerequisites, or alternative routing despite several near-siblings (product__shipments, route__shipments, shipments__search) that an agent could easily confuse it with.

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 behavior, so the safety profile is covered. The description adds useful content about what the corridor contains, but says nothing about error behavior when a name is unknown or whether the snapshot may be stale.

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 sentence, front-loaded with the action and resource, with zero filler. It is appropriately sized for a single-parameter lookup.

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 an output schema covering return values and annotations covering the safety profile, the description only needs to name the operation and lookup key, which it does. Only the missing not-found behavior keeps it from a 5.

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 parameter is fully documented, including the kebab-case format and a discovery path. The description's 'by name' adds nothing beyond the schema, so 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 (returns) and resource (a saved corridor) and enumerates the payload: countries, HS code, defaults, tariff snapshot. It is clearly distinct from corridor__list and corridor__save, though it doesn't explicitly say so.

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 no when-to-use guidance or alternatives; the only routing hint ('Discover via corridor list') lives in the schema, not the description. An agent can infer single-item lookup vs list, but nothing is stated.

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, and non-destructive, so safety is covered. The description adds one genuinely new behavioral fact — results are ordered most-recent-first — but says nothing about pagination limits, result caps, or account scope.

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 verb-resource pairing and appends the ordering detail with 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?

An output schema exists, so return values need not be described, and the one param is fully documented in the schema. For a simple read-only list tool the description is essentially complete, with only minor gaps around page-size 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?

Only one parameter and schema description coverage is 100%, so the schema fully documents the cursor offset and how to feed it back. The description adds no additional meaning about the cursor, which is acceptable at the baseline.

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

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

States a specific verb (Lists) and resource (saved trade corridors) plus an ordering guarantee. It is clearly distinguishable from the sibling corridor__get and corridor__save by the plural listing verb, though it never names those siblings 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?

There is no when-to-use or when-not-to-use guidance; it does not mention the sibling corridor__get (single corridor) or corridor__save, nor when to page through results. Usage is only implied by the verb 'Lists'.

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=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds the composition of the corridor and the optional starring/currency/Incoterm behavior, but says nothing about the baseVersion conflict handling, auth needs, or what a repeat save does beyond the annotation hint.

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 that leads with the action and resource before the optional modifiers. Dense but free of filler, though the 'optionally starred with a default currency and Incoterm' clause packs several concepts tightly.

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?

An output schema exists, so return values need not be explained, and the 100%-covered schema carries parameter detail. For a mutation tool whose annotations already state the safety profile, the description is nearly complete, missing only when to prefer this over get/list or update.

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 all eight parameters are already documented in the schema, including the baseVersion optimistic-concurrency semantics. The description only restates the optional star/currency/Incoterm fields, adding no syntax or format detail 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?

States a specific verb (Saves) and resource (corridor), and defines what a corridor is composed of (exporter-importer-HS code lane) plus optional attributes. This is clearly distinguishable from the read-only siblings corridor__get and corridor__list, though neither is named.

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 'for reuse' implies the motivation to persist a lane, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. corridor list/get or update). Usage is left largely to inference.

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 behavior, so the safety profile is covered. The description adds the meaningful resolution semantics — three accepted input formats collapsing to a single canonical record — which is behavior the annotations do not convey. It stops short of describing handling of unknown or ambiguous inputs, so it is not a 5.

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, front-loaded with the operation and its inputs before the usage note; nothing is padded. The second sentence partly echoes the first and the schema, so it is tight rather than maximally economical.

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 an output schema present, return values need not be described, and annotations cover the safety profile, so the short description is nearly sufficient. The remaining gap is behavior on unmatched or ambiguous queries, which an agent normalizing messy country strings would want to know.

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?

There is only one parameter and schema description coverage is 100% ('Country identifier: name, ISO2, or ISO3'), so the schema already carries the semantics. The description only restates the same three formats, adding no format rules, casing behavior, or examples beyond the structured field. 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 (resolves) plus resource (country) and enumerates the accepted identifier forms (name, ISO2, ISO3) with the output target (canonical record). This is far more informative than the title alone. It does not explicitly contrast with the similarly-named exim__company__resolve sibling, though the resource difference is self-evident.

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?

'Use it to normalize country inputs' gives an implied usage context, but it is closer to a restatement of purpose than real routing guidance. No alternatives are named (e.g., whether lookups elsewhere accept raw country strings) and no when-not-to-use condition or prerequisite is stated.

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, idempotent, openWorld, non-destructive), so the bar is lower. The description still adds real behavioral context that is not in the annotations: repeats of the same URL are not re-charged, which is a meaningful cost/caching 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?

Two tight sentences with no filler, and the core purpose is front-loaded before the billing note. Appropriately sized for a single-parameter 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 rich annotations, an output schema, and 100% parameter coverage, the description only needs to frame purpose and behavior, which it does. The phrase 'relevant internal pages' remains somewhat vague about crawl depth, and no usage routing is given, but nothing essential for calling the tool 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 single url parameter is fully documented in the schema, including the same 'homepage and relevant internal pages' phrasing. The description adds nothing beyond what the schema already provides, so 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 (Reads) and resource (a website's homepage and relevant internal pages) plus the output format (markdown). Clear enough to act on, though it does not explicitly differentiate itself from sibling tools like exim__enrich__company or exim__profile__extract that also surface web 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 is a pure purpose statement with no when-to-use, when-not, or alternative-tool guidance. An agent gets no signal on when crawling a site is preferable to the enrich/profile/prospect siblings, nor any prerequisites.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds what the payload contains (effective rate, remedies, protection level), but says nothing about result volume, pagination behavior beyond the limit param, or data-source caveats. Adds some value against an already-strong annotation set.

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 sentence, no filler, with the resource named first and the scoping dimensions trailing. Nothing could be trimmed without losing 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. For a 7-parameter, zero-required query tool the description is adequate, but a note on what an empty result means or how defaults resolve would close the remaining 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?

Schema description coverage is 100% and every parameter is documented there, including HS-code padding rules and the origin/destination ISO2 conventions. The description only restates the same dimensions (HS code, origin, destination, date range) without adding format, default or fallback semantics. Baseline 3 applies when the schema carries the load.

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: returns effective rate, trade remedies and protection level, scoped by HS code, origin, destination and date range. That is concrete and recognizable. It does not, however, differentiate itself from close siblings such as exim__duty__fta or exim__tariff, leaving the agent to infer the boundary from names alone.

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 states when to choose this tool over exim__duty__fta, exim__tariff or exim__trade__lookup, nor any prerequisites. Usage has to be reverse-engineered from the parameter list. No exclusions or alternative routing is offered.

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, idempotent, closed-world read, so the safety burden is light. The description adds that the result is a comparison aggregated by agreement, which is useful context, but says nothing about pagination limits, response granularity, or the schema constraint that at least one of hsCode/destinationCountry must be supplied.

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 tight sentences with the purpose front-loaded and the use case second. No filler, no repetition of schema or annotation content.

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 a full output schema and 100% parameter documentation, the description does not need to explain return values, and the read-only annotations cover the safety profile. It is nearly complete, missing only a pointer to differentiate it from the adjacent duty/tariff tools.

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%, with dates, limit, hsCode format guidance, and ISO2 country codes all documented in the schema itself. The description adds no parameter-level meaning beyond that, 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?

The description states a specific verb and resource: it shows how much trade used an FTA preference versus full duty, broken down by agreement. That is more than a restatement of the title, but it never distinguishes itself from related siblings such as exim__duty__exposure, exim__tariff, or exim__landed__cost, so an agent must guess which duty tool fits.

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?

'Use it to find unused FTA savings' gives a use case but no explicit when-not conditions and no alternatives. It implies the usage context without helping the agent choose against the other duty/tariff 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 declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, and the description adds the crucial behavioral boundary that this operation creates drafts but performs no send — a side-effect distinction not derivable from the annotations alone. It does not cover persistence of the drafts, authorization requirements, or any limits, so it is helpful 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?

Two sentences, zero filler, and the non-sending constraint is front-loaded before the workflow hint. Every clause earns its place.

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

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

With an output schema present, return values need no explanation, and the 8 parameters are fully documented in the schema. The description supplies the workflow context (draft, then pair with send) that the structured fields cannot, though it omits whether drafts persist and how they are subsequently addressed.

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%, including nuances like the profile-based personalization and the includeLowConfidence/'email send' flag-matching constraint, so the schema carries the full parameter burden. The description adds no parameter-level meaning beyond what the schema already documents, which is the correct baseline of 3.

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

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

States a specific verb (generates), resource (personalized outreach emails), and scope (companies in a collection, derived from a brief), and immediately pins down the key differentiator against its nearest sibling exim__email__send: 'without sending'. An agent can distinguish the draft step from the send step 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?

The description routes the agent to the alternative ('Pair with email send to send the same drafts'), which is exactly the sequencing information needed for a generate-then-send workflow. It stops short of a 5 because it names no exclusions or prerequisites (e.g. that the collection must already contain companies).

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 destructiveHint=true, openWorldHint=true and non-idempotent, so the safety bar is lower. The description still adds real value beyond that: the confirm gating on preview vs. actual send and the specific pre-send checks (signature, sender-domain, OFAC SDN) are not in the annotations, giving the agent concrete behavioral context.

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

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

Two sentences, no filler, and the critical decision variable (confirm) is stated up front in the first sentence. Every clause earns its place by conveying the preview/send distinction.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description covers the destructive-send gating and the compliance checks, leaving only minor gaps such as volume limits or what happens to already-approved drafts — not essential for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including confirm, dryRun, regenerate and includeLowConfidence. The description reinforces the confirm semantics but adds no syntax or format detail beyond what the schema provides, 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?

The description names a specific verb and resource with scope: 'Sends outreach emails to the companies in a collection.' It clearly distinguishes the two modes (preview vs. real send), but it never explicitly references the sibling exim__email__draft, which is the natural alternative for the drafting-only case, so sibling differentiation is only partial.

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 useful conditional guidance ('without confirm ... preview only; with confirm ... sends') that helps an agent decide the mode. However, it never names exim__email__draft as the tool to reach for when the agent only wants drafts, nor does it state prerequisites such as needing an existing collection or an operator-owned sender domain, so usage is implied rather than explicit.

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 covered. The description adds the real value of stating this operates only over persisted data, but omits behaviorally important detail for a multi-filter tool: whether the three filters intersect (AND) or union (OR), and whether zero matches returns an empty set or an error.

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

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

Two sentences, no filler: the operation and scope come first, the exclusion second. Every clause earns its place.

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

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

With rich annotations, a full output schema and 100% parameter coverage, the description only needs to establish intent and scope, which it does. The remaining gap is filter-combination semantics, which no other structured field covers and which materially affects how an agent invokes 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% and each parameter (titles, departments, confidence enum, collectionId) is fully documented in the schema, so the baseline applies. The description restates the three filter dimensions but adds no format or combination semantics beyond that, and its use of "or" is ambiguous given all three can be supplied together.

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 (filters) and a specific resource (contacts already saved on a collection), and immediately scopes it with "Does not discover new contacts" — which cleanly separates it from discovery siblings like exim__prospects__find and enrichment siblings like exim__enrich__contacts.

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 exclusion ("Does not discover new contacts") gives a clear negative condition for when not to use it, plus the positive precondition that contacts must already be saved on a collection. It stops short of naming the alternative tool to use for discovery, so it is clear context without explicit routing.

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=true, idempotent=true, destructive=false and closedWorld=false, so safety is covered. The description's only added behavioral fact is that it operates on already-saved collection members rather than discovering new ones; it says nothing about ordering tie-breaks, empty-collection behavior, or cost/latency.

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 tight sentences: the capability first, the scope constraint second. No filler, no restatement of the title, and every word 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?

With an output schema and full annotation coverage, the description need not explain return values, and it is complete enough to call the tool correctly. Minor gaps remain: what happens if the collection has no contacts and what the ranking does with ties or missing data.

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% and the enum values are already documented in the schema, so the description's criterion list largely restates it. The only added nuance is the parenthetical gloss that 'decision-maker' means procurement/buyer plus seniority, which is a modest, not decisive, contribution.

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 (ranks) and a specific resource (contacts saved on a collection), and enumerates the four ranking criteria. It narrows scope against contact-discovery tools via 'Does not discover new contacts', though it does not name the closest sibling (exim__employees__filter) it should be preferred over.

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 exclusion ('Does not discover new contacts') gives one clear when-not boundary, which is useful. But there is no positive when-to-use guidance (e.g. 'use after items__add to order a saved list') and no named alternative such as exim__employees__filter or exim__prospects__find for discovery, so routing is only implied.

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 the return shape, which is beyond what the annotations declare, and it is consistent with openWorldHint=true (it fetches a live website). However, the annotations set readOnlyHint=false and idempotentHint=false while the description only says it 'reads' — it discloses neither what side effect occurs (e.g., a persisted/stored enriched profile) nor that repeated runs may differ. With annotations present the bar is lower, but the non-read-only behavior is unaddressed.

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, zero filler, with the return surface front-loaded before the input note. Nothing repeats the title or restates structured fields unnecessarily.

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 return-value schema exists, so the description needn't enumerate outputs in depth, yet it does helpfully. For a 7-parameter, non-read-only, open-world enrichment tool, the remaining gap is routing guidance against the many nearby company/profile tools; otherwise an agent has enough to call it correctly.

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

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

Schema coverage is 100% and each parameter carries a rich description, so the schema does the heavy lifting. The description still adds value by collapsing the convoluted not/anyOf 'exactly one of url|company' construct into the plain sentence 'Pass a URL, or a name to resolve,' which an agent can act on without parsing the JSON logic.

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 ('reads a company's website') and enumerates the returned artifacts (description, products with HS codes, certificates, trade markers, ports, branches, contacts), which no sibling tool's name implies. An agent can distinguish this enrichment tool from exim__enrich__contact or exim__companies__profile based on the stated output surface.

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?

'Pass a URL, or a name to resolve' gives the two input modes but never says when to prefer this over exim__company__resolve, exim__profile__extract, or exim__companies__profile. Prerequisites (does a resolved company need to exist first? when to use name+country vs url) are left 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 already declare the mutation and openness profile (readOnlyHint=false, openWorldHint=true, non-idempotent, non-destructive). The description adds genuine context beyond them: 'fills it in when found' discloses a conditional write-back and that the field may not be populated. It does not cover failure behavior, auth needs, or what happens when the email cannot be verified.

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 efficient sentence with the verb and outcome front-loaded and no filler. Nothing is wasted, though it is arguably terse for a tool with a conditional-update behavior worth expanding.

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?

An output schema exists, so return values needn't be explained, and the annotations carry the safety profile. Still missing: guidance on choosing between its two optional parameters (required count is 0, which is ambiguous for a tool that needs an identifier) and any pointer to the plural batch sibling.

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 'mail' and 'employeeId' are already documented in the schema. The description adds no meaning about how the two relate or whether one should be supplied, though the baseline for high coverage is adequate 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?

States a specific verb and resource: 'Re-verifies one saved contact's email'. The scope word 'one' implicitly distinguishes it from the plural sibling exim__enrich__contacts, and 'saved contact' clarifies it operates on existing records. It stops short of naming the sibling 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?

There is no explicit when-to-use or when-not-to-use guidance and no alternative is named. The phrase 'saved contact' weakly implies it applies to already-stored contacts rather than new ones, but an agent must infer when to pick this over exim__enrich__contacts or exim__enrich__company.

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 not read-only, open-world, and non-idempotent, so the description adds useful context by mentioning a hard cost cap and verified/probable marking. It still does not explain the cap value, billing mechanics, or whether results are persisted to the collection.

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 front-loaded sentences with no wasted text. The core purpose, filters, cost constraint, and output marking are all stated 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?

With a full input schema and an output schema, the description is complete enough for tool selection and invocation. The main remaining gap is that the 'hard cost cap' is not quantified or explained.

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 parameter semantics are already well documented. The description mentions several filter dimensions but adds little beyond the schema for limit, rowIds, collectionId, or onlyWithWebsite.

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: finds decision-maker contacts for companies in a collection. The collection scope and contact output distinguish it reasonably from sibling enrichment tools, though it does not explicitly name alternatives like exim__enrich__contact.

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 context is clear: use this when enriching companies within an existing collection, optionally filtered by department, seniority, title, or priority. It does not spell out when to prefer a different sibling tool or when not to use this one.

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 structurally. The description adds only the return nature (raw source record, optionally normalized), which is modest added context rather than rich behavioral 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?

Two sentences, zero waste. The core purpose is front-loaded and the usage hint follows immediately.

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 tool with full schema coverage, an output schema and complete annotations, nothing an agent needs 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 description coverage is 100%, so both parameters are already documented by the schema. The phrase 'optionally with English-normalized fields' restates the schema's wording for `normalized` rather than adding new meaning, 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: it 'returns the raw source record behind one shipment.' The provenance framing ('verify where a figure came from') distinguishes it in spirit from retrieval siblings like exim__shipments__get, though it does not name an alternative 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?

'Use it to verify where a figure came from' gives a clear use context. There is no explicit when-not condition or named sibling, but the intended scenario 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world. The description adds genuinely new behavior: the search widens until it finds strong matches, which tells the agent the result set is adaptive rather than a fixed-precision lookup. Rate limits and result-shaping details beyond that are absent.

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 the tool does and followed by the usage context; no filler. The semicolon-clause about hierarchy level is dense but 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?

An output schema and rich annotations are present, so return values and the safety profile need not be restated. The description covers purpose, scope, adaptive-search behavior, and downstream workflow, leaving little an agent needs that 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 all three parameters are already documented in the schema. The description restates the query (keyword or code) and level restriction but adds no syntax, default, or format detail beyond what the schema provides, 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 ('Finds') and resource ('HS codes') with both input modes (keyword or code) and the level restriction. It distinguishes itself well from data-query siblings like exim__tariff by framing itself as the classification step. It stops short of explicitly naming a sibling it replaces, so it lands at 4 rather than 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?

'Use it to classify a product before tariff, analytics or buyer search' gives a clear workflow context that implies when to reach for this tool over the tariff/analytics siblings. There is no explicit when-not or named alternative tool, so it is clear context without 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 readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description still adds real value by warning that content is truncated, which is a behavioral trait not visible in any structured field. It stops short of explaining truncation limits or how to retrieve untruncated content.

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 sentence, zero waste, with the operation and the returned fields front-loaded. Nothing could be removed without losing 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?

With an output schema present, return-value detail need not be repeated, and the description correctly confines itself to operation and payload characteristics including truncation. The one gap is the absence of any routing or prerequisite context, which is minor for such a narrow lookup tool.

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?

There is a single parameter with 100% schema description coverage, including the filename format cue and the discovery hint, so the schema does the heavy lifting. The description only restates 'by filename' without adding syntax or resolution details, matching the baseline 3 for fully documented schemas.

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 ('Returns a knowledge-base entry by filename') plus the payload ('tags, metadata and (truncated) content'), so the agent knows exactly what comes back. It does not explicitly name the counterpart sibling (exim__kb__list), but the get-vs-list distinction is unambiguous from the phrasing.

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 offers no when-to-use or prerequisite guidance; it only says what it returns. The only routing hint ('Discover via `kb list`') lives in the schema's parameter description, not in the tool description itself, so the description text carries no usage instructions.

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 fully covered by structured data. The description adds nothing beyond that — no pagination behavior, no default page size, no ordering, no note that the cursor comes from a prior response. With annotations carrying the load, this is minimal but not contradictory.

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 short, front-loaded sentence with no filler or redundancy. It is efficient, though its brevity borders on under-specification given the tool's listing semantics.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still, for a paginated list tool the description omits that results are paged (and how to continue), and gives no hint of the relationship with exim__kb__get for retrieving individual entries.

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% and the single cursor parameter is fully documented in the schema as a 0-indexed pagination offset returned by the previous response. The description adds no additional parameter meaning, 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?

The description states a specific verb and resource: 'Lists the entries in your knowledge base.' An agent can tell this is a read/list operation over KB entries. It does not, however, distinguish the scope from its sibling exim__kb__get, 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?

There is no when-to-use guidance, no condition that selects this tool over exim__kb__get, and no mention of what the list returns or how to drill into a specific entry. The agent must infer usage entirely from the name and namespace.

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