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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered; the description adds real value on top by specifying the returned fields (EEC decision, per-producer duty rates, expiry date, link). Crucially it discloses the dataset's bounded coverage — measures renewed in 2026 only, not exhaustive — which is exactly the kind of non-obvious behavior that prevents false negatives.

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

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

Purpose is front-loaded in the first clause, followed by return contents and then the coverage caveat, so the agent gets what it needs early. The only waste is the awkward sentence break inside 'the decision that sets duty rates', which is a formatting artifact rather than redundant 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 no output schema, the description correctly takes on the burden of describing return values (decision, rates, expiry, link), and the non-exhaustive caveat handles the main correctness risk. What is still missing is the filter-combination semantics for a tool whose three parameters are all optional, which matters for a lookup that may return everything.

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 each of the three parameters already documented including examples ('грузовые шины', 'CN, UA, AZ'), so the baseline is 3. The description restates the parameter names but does not explain how they combine (AND vs OR) or how prefix matching on the TN VED code behaves, so it adds little beyond the schema.

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

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

The description opens with a specific verb and resource — 'Check EAEU trade defence measures (antidumping duties)' — plus the three facets it can be queried by (code, product, origin country). This is a distinct domain from siblings like tnved_search or classification_rulings_search, so an agent can route to it without ambiguity.

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 through the parameter list; the description never states when to prefer this over tnved_search or tnved_code_info, nor whether all three filters are optional (i.e. that an empty call lists everything). The one genuine guidance element is the caveat that absence of a match is not proof a measure applies, which tells the agent how to interpret a negative result.

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

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

The annotations already declare readOnly, idempotent, non-destructive, and openWorld; the description justifies the openWorld flag by disclosing that currencies are converted at Bank of Russia rates (a network fetch). It also discloses the VAT base composition and the shape of the result ('line-by-line breakdown with sources'), which is useful beyond the annotations. It stops short of stating failure behavior when neither code nor duty_rate is provided, or how rounding is 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?

One line stating purpose and scope, followed by a compact formula digest and a return-value note. It is dense but front-loaded and every clause maps to a computed component or parameter family; minor cost is that the component list reads as a wall of commas rather than a structured list.

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 16-parameter calculator with no output schema, the description supplies the calculation logic, the currency-conversion behavior, and the return shape, which is most of what an agent needs to call it correctly. The remaining gap is edge-case behavior — what happens if both code and duty_rate are omitted, or if a specific rate is chosen without the matching quantity_* value.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining why the quantity_* parameters exist, listing the rate forms (ad valorem, per kg/pcs/pair/litre, combined 'X% but not less than Y EUR') that the duty_rate string must match. It also clarifies the VAT base as customs value + duty + antidumping + excise, which is information the schema alone does not convey.

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

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

States a specific verb and resource — calculating Russian import customs payments for a single goods item in RUB — and enumerates the exact components computed (ETT duty, antidumping, excise, import VAT, 2026 clearance fee). That enumeration makes it unmistakable against siblings like tnved_search, antidumping_check, or customs_clearance_fee, which each cover only a fragment of this calculation.

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 one goods item' implicitly scopes usage to a single-line landed-cost calculation, and the formulas imply it is the aggregating tool. However, it never says when to use this versus customs_clearance_fee or calc_recycling_fee directly, nor what to do when no rate source is supplied. Guidance is inferable but not 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 cover the safety profile (readOnly, idempotent, closed-world, non-destructive), so the description's job is to add domain behavior — and it does: official coefficient table, base rate of 20 000 RUB, the temporal validity window of Dec 2025 through 2030, and the personal-use preferential rates. It even discloses the return payload (coefficient, band, source). It does not say what happens for a date outside the table window, which is the one behavioral gap.

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

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

Three short paragraphs: what it computes, the table it uses, and what it returns — front-loaded and logically ordered. Slightly dense with legislative citations and duplicated rate figures, but every element is informative rather than filler.

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

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

For an eight-parameter, read-only calculator with no output schema, the definition supplies scope, legal source, valid date window, and the shape of the result. The only missing pieces are out-of-range date handling and an explicit statement that parameter requirements (e.g. engine_volume_cc for ice) are enforced — the latter being covered by the schema.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the engine enum, power units, and the ICE/hybrid volume requirement — baseline 3 applies. The description reinforces the banding logic (engine type, volume, kW power band, age, year) but adds no syntax or edge-case detail beyond what the schema 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?

The description names a specific verb+resource (calculating the recycling fee / утилизационный сбор) and pins the scope to M1 passenger cars imported into Russia, referencing the exact legal basis (Decree 1291 as amended by 1713). That is enough to separate it from siblings such as calc_import_payments or customs_clearance_fee, though it never explicitly states that it covers only the recycling fee and not the other import charges.

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 context is implied by the scope sentence (you are pricing a recycling fee for an imported passenger car), and the description notes both the commercial and personal-use tables. It gives no explicit when-to-use/when-not-to-use guidance against calc_import_payments, and does not warn that non-M1 vehicles (trucks, buses, motorcycles) are out of 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 cover the safety profile (read-only, idempotent, non-destructive), so the description's job is to add domain context, which it does: it discloses that results are legally binding across the EAEU and constitute the strongest evidence for a code, and it lists the returned fields (decision number, date, product, TN VED code/heading, source link). It does not mention result volume, ordering, or what happens when no ruling exists.

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

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

Three short sentences, front-loaded with what the tool does, followed by the evidentiary weight rationale and then the return shape. No filler or restatement of the tool name.

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

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

With no output schema, the description properly compensates by enumerating the returned fields, and it conveys the legal significance of the data. Minor gap: nothing on combining the two optional filters or on behavior when no matching ruling is found.

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 both parameters are documented in the schema with examples, so baseline 3 applies. The description adds nothing about the two parameters, notably not whether 'code' and 'query' are combined with AND semantics or whether one is preferred.

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: searching EEC decisions on classification of specific goods, with the scope narrowed to goods classification rather than tariff lookup generally. It implicitly distinguishes itself from tnved_search by framing the outputs as 'binding for all EAEU customs and the strongest evidence for a code', though it never names the 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?

Usage is implied rather than stated: the note that these decisions are binding and are 'the strongest evidence for a code' tells an agent this is the authoritative source when a code needs justification. However, there is no explicit when-to-use/when-not, no mention of how it relates to tnved_search or tnved_code_info, and no guidance on when to query by code versus by product words.

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 behavior, so the bar is lower. Beyond that, the description adds genuinely useful context: the rate year (2026), the numeric bracket range (1 231 to 73 860 RUB), and that the bracket table plus legal source are returned alongside the fee.

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

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

Three short lines, front-loaded with the definition, then the value range, then the return contents. The parenthetical Russian legal term is useful rather than filler; only mild redundancy between the fee range sentence and the parameter's name.

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 one required parameter and no output schema, the description fills the remaining gap by stating what is returned (fee, full bracket table, legal source) and which jurisdiction and year the rates apply to. Little an agent would need in order to call it correctly is missing.

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

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

Schema coverage is 100% and the single parameter is fully documented in the schema. The description reinforces that the fee is driven by the total customs value of the declaration rather than per-item value, but adds no format or rounding detail beyond that, 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 names the specific resource (customs clearance fee / сбор за таможенные операции), ties it to import declarations into Russia for 2026, and states the computation basis (total customs value). That is enough to separate it from siblings like calc_import_payments, calc_recycling_fee, and antidumping_check.

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 import-declaration context implies when the tool applies, but there is no explicit guidance such as when to use this versus calc_import_payments or calc_recycling_fee, and no stated prerequisites or exclusions. Usage is inferable but not spelled out.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds two genuinely useful facts beyond them, the authoritative source and the rate direction (RUB per 1 unit), but says nothing about the validity period of Central Bank rates or whether a non-trading day falls back to a prior quote.

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 source, the unit convention and the use case packed into it; nothing is redundant and nothing needs reordering.

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

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

For a two-parameter read-only lookup with full annotation coverage and no output schema, the definition is nearly sufficient, and 'RUB per 1 unit' usefully implies the return shape. It stops short of noting that quotes are date-stamped by the Central Bank and may not exist for arbitrary dates, which an agent calling with a weekend date 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?

Schema description coverage is 100%: on_date documents the YYYY-MM-DD format and today default, and currencies documents the code list plus the all-if-omitted behavior. The description adds no parameter meaning beyond that, which is the correct baseline when the schema does the work.

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 resource (official Bank of Russia exchange rates), states the unit convention (RUB per 1 unit), and gives the business context (customs payments). It is distinguishable from every sibling, none of which is a rate lookup, though it never states the retrieval verb or scope 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?

'used for customs payments' implies the context in which an agent would reach for this tool, but there is no explicit when-to-use rule, no mention of when a different tool (e.g. calc_import_payments, which presumably consumes these rates) is the better choice, and no 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 read-only, idempotent, non-destructive, open-world, so safety is covered. The description adds real value beyond that: it discloses arithmetic validation, an Incoterms-based customs value explanation, and per-line TN VED query suggestion — behaviors an agent couldn't infer from the schema. It doesn't mention behavior on unparseable or low-confidence files, which keeps it short of 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?

Front-loaded with the purpose, then the extracted-field list, then the derived behaviors, then the handoff. Dense but every clause carries information; the field enumeration is long but directly useful for verifying extraction quality.

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 only two optional parameters, no output schema, and full schema coverage, the description compensates well by enumerating the returned line fields and the derived checks. The only gap is the concrete response envelope (e.g. how warnings about arithmetic mismatches are surfaced).

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 both parameters are documented in-schema, including the xlsx/csv vs PDF/DOCX routing. The description adds no parameter-level guidance of its own, 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 (parse a supplier's commercial invoice or packing list into customs-ready line items) and enumerates exactly what is extracted, so an agent can tell it apart from tnved_search or calc_import_payments immediately.

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 downstream: 'Feed the lines to tnved_search and calc_import_payments', establishing this as the first step of a pipeline. It lacks an explicit when-not-to-use clause, but the extraction-then-classify framing 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, closed-world, non-destructive behavior, so the safety profile is covered. The description adds value by disclosing what the response actually contains (load dates, list dates, sources), which is important because there is no output schema. It does not mention date formats or how missing/never-loaded data is represented.

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 clause with no filler, and the most useful information (that it exposes data versions) is front-loaded. It is a sentence fragment rather than a full statement, which slightly reduces immediate clarity but wastes no words.

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

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

For a zero-parameter, read-only metadata tool with no output schema, the description covers the essential return contents well enough for an agent to decide to call it. Gaps are minor: no date format, no statement of which datasets are absent if not yet loaded.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The field list it does provide relates to the return payload rather than inputs, which is appropriate 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?

The description names the resource precisely: data versions of this server, enumerated as tariff load date and source, antidumping and rulings list dates, and fee table source. It is clearly distinguishable from every sibling (searches, calculators, parsers) as the metadata/provenance tool. It lacks an explicit verb such as 'returns' and the name 'server_status' is broader than the actual content, which keeps 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?

There is no explicit statement of when to call this versus the sibling tools. Usage is only implied: an agent can infer it is for checking data currency/provenance before trusting tariff, antidumping, or fee results. No exclusions or prerequisites are 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, non-destructive, and closed-world, so safety and repeatability are known. The description adds real value beyond that by disclosing the returned data composition and that the duty rate is decomposed into ad valorem / specific / combined parts, plus the conditional filtering of antidumping measures. It does not cover behavior on invalid or out-of-range codes (schema allows 4–10 digits) or how requests behave for missing tariff lines.

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

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

Front-loaded with the core action in the first sentence, then a compact enumeration of return contents. No filler or restatement of the title; the phrasing is dense but readable. Slightly long return-list sentence could be tightened, but every element carries information.

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

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

With no output schema, the description carries the burden of describing returns, and it does so at a reasonable level — name, parent headings, duty rate decomposition, antidumping measures, and rulings. It is complete enough for an agent to judge relevance and call it correctly, though it stops short of describing output structure or edge-case behavior for unrecognized codes.

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

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

Schema description coverage is 100%, so the schema already documents both parameters, making 3 the baseline. The description adds genuine meaning beyond the schema by clarifying that origin_country acts as a filter — omitted ('if given') it returns antidumping measures unfiltered rather than failing, a conditional behavior the schema does not state.

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

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

States a specific verb and resource ('Get everything known about one TN VED EAEU code') and scopes it to a single code, which implicitly separates it from the sibling tnved_search. The second paragraph enumerates exactly what 'everything' covers — official name with parent headings, parsed duty rate, antidumping measures, and classification rulings — so an agent knows what it will receive.

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

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

Usage is implied rather than stated: the description signals a single-code lookup and hints that origin_country is only relevant for antidumping checks ('filtered by origin country if given'). There is no explicit statement of when to prefer antidumping_check or classification_rulings_search, or when this aggregate tool is the better choice than those narrower siblings.

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 the description adds real value beyond them: it discloses the return payload (candidate 10-digit codes, official names, ETT import duty rate) and the important interpretive caveat that matches are candidates rather than rulings. It stops short of stating how many candidates are typical or how ranking works, so it is strong but not exhaustive.

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

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

Four short sentences, front-loaded with the action and query modes, followed by return shape, the follow-up tool, and the caveat. No filler or restatement of the tool name.

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

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

With no output schema and only two parameters, the description carries the necessary burden: it covers input semantics, returned fields, and the downstream tool to call. An agent has everything needed to invoke it correctly and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by specifying that queries should be Russian technical vocabulary (material, function) or a code prefix, reinforcing the schema's example. The limit parameter is left to the schema with no guidance on when to raise 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?

Names a specific verb plus resource ('Search the TN VED EAEU commodity nomenclature') and states both accepted query modes (product words or code prefix). An agent can immediately distinguish it from tnved_code_info, which is explicitly framed as the follow-up detail lookup.

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

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

Gives explicit when-to-use ('text search matches nomenclature wording, so use technical terms... not brand names'), names the alternative and the handoff sequence ('Use the candidates to pick a code, then call tnved_code_info for details'), and adds a scope caveat that results are not a classification decision.

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