Karpata – company data from public registers

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

Annotations declare readOnlyHint=false and openWorldHint=true; the description explains the non-obvious reason — a verification record is persisted, so it is not a pure read ("Stored as a verification record (see get_record)"). It also discloses a credit cost, a genuine behavioral trait not present in any annotation. It stops short of describing latency, failure modes, or what a returned result looks like.

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 action and the country-specific sources, then the storage and cost facts. Dense and largely waste-free, though the telegraphic phrasing ("§81 list", "published accounts") assumes domain fluency and the two trailing clauses read as afterthoughts.

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 saying what happens on return, and it does so by pointing to the persisted verification record via get_record. Cost and per-country coverage are covered; an agent still lacks a sense of what a verdict looks like or how long the live lookup takes.

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 reinforces the country scope (SK/CZ/RO) that matches the enum, but adds nothing about regNo format or the date/account parameters beyond what the schema already documents.

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 action (live VAT risk check) and enumerates the exact per-country sources consulted: SK §81 list, CZ unreliable VAT payer (§109), RO inactive taxpayer. That is far more concrete than its siblings get_risk or verify_company, though it never explicitly distinguishes itself from them.

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

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

"Before paying a supplier" gives a clear situational trigger for when to call it, and "Costs credits" hints that it should not be called casually. However, it never states when NOT to use it or why an agent would pick this over verify_company or get_risk, which occupy adjacent territory.

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 safety (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds two useful traits — data source ('public register', 'with provenance') and cost ('Free') — but says nothing about behavior when regNo is unknown or invalid, whether results can be stale, or what 'provenance' concretely contains.

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 identifies the resource and its fields, then appends cost. No filler, nothing an agent has to scan past.

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

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

For a two-parameter read-only lookup with no output schema, the field enumeration effectively tells the agent what comes back, and the annotations cover the safety profile. Missing only error/not-found behavior to be fully complete.

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

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

Schema coverage is 100% and both parameters carry descriptions including the IČO/CUI mapping and the country enum, so the schema does the heavy lifting. The description adds nothing about the parameters themselves, which is acceptable at full coverage but earns only 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?

The description names the resource concretely ('basic company card from the public register') and enumerates the fields it returns (name, legal form, status, seat, main activity, VAT flag), which lets an agent distinguish it from get_financials and get_risk. It never states the verb ('returns') explicitly and doesn't name siblings, so it stops short of a 5.

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

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

Usage is only implied: 'basic' and 'Free' suggest this is the cheap first-look tool before deeper lookups like get_financials or get_risk, but no when-to-use/when-not or alternative is named. An agent can infer the role but must guess the routing rules.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds a genuinely important behavioral fact not in the annotations: the call consumes credits. The five-year coverage window is also useful context. It does not say what happens when filings are missing or the registration number is invalid.

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

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

Two short sentences with zero filler, and the resource and scope are front-loaded ahead of the cost caveat. Nothing needs trimming.

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 paid lookup with no output schema leaves the agent guessing about the return shape (statement sections, units, currency, ratio set) and about failure modes such as unknown or unfiled companies. Parameters and safety are fully covered elsewhere, so the gap is moderate rather than severe.

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

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

Schema coverage is 100%, and the schema already documents regNo as IČO/CUI and country as an SK/CZ/RO enum. The description only echoes the country list, adding no new meaning about formats, identifier validation, or required entity existence; baseline 3 applies when the schema does the heavy lifting.

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

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

Names a specific resource (financial statements) with concrete scope: up to five years of history plus ratios, limited to SK/CZ/RO. It never distinguishes itself from siblings like get_company or get_risk, so an agent must infer whether this is the right lookup for a given question.

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 and no mention of alternatives such as get_company or get_risk. The only usage-like signal is 'Costs credits,' which warns about cost but does not help select the tool.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description still contributes real behavioral information beyond that: the result includes an integrity verdict comparing stored content to its SHA-256, which is not derivable from the annotations or 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 compact sentence with zero filler, front-loading the resource and its integrity-verification behavior. It is a sentence fragment rather than a full clause, which slightly reduces readability but wastes nothing.

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

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

For a single-parameter read-only tool with no output schema, the description covers the resource, its key, and the notable return characteristic (SHA-256 match). Missing only edge-case behavior such as what happens when the id is unknown.

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 id parameter is already documented as coming from check_vat. The description adds no format, validation, or error semantics for the id, 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 resource (a stored VAT verification record) and the key (its id), and adds that it reports whether content still matches its SHA-256. That is more than a restatement of the name, though it never contrasts itself with siblings like get_company or check_vat.

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 schema note 'record id from check_vat' implies the retrieval follows a check_vat call, which gives an implicit usage context. However, the description itself offers no when-to-use/when-not guidance and does not route the agent away from sibling getters such as get_company or get_financials.

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 it as a read-only, open-world lookup, and the description adds two things the annotations do not: the score is rule-based with explanations and explicitly not a credit rating, and the call consumes credits. Those caveats materially affect how an agent interprets and budgets the call. It stops short of saying whether results are cached or what happens for unsupported registration numbers.

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 dense sentence listing the payload, followed by two short qualifiers for the score's interpretation and the billing cost. Nothing is redundant and the most decision-relevant caveats are front-loaded.

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

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

With no output schema, the description usefully enumerates what comes back (debts, reliability, insolvency, score plus reasons), which is exactly the burden it should carry. The remaining gap is sibling routing (risk score vs financial statements) and the size of the credit cost, but nothing essential to calling 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 both parameters (regNo with per-country formats, country with an enum) are fully documented in the schema itself. The description adds no parameter-level meaning beyond what the schema provides, 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?

Enumerates the specific data returned: state debts, tax reliability, insolvency proceedings, and a rule-based score with reasons. That is far more informative than the bare name 'get_risk', and the 'not a credit rating' caveat sharpens what the score means. It does not explicitly contrast itself with close siblings like get_financials or verify_company, 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?

'Costs credits' implies the tool is costly and should not be called speculatively, which is a usable usage signal. However, there is no explicit statement of when to reach for this versus get_financials (financial statements) or verify_company (registry verification), no prerequisites, and no exclusions. Usage is implied rather than 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: the bounded change history (last 200 changes since watching started), the plan watch-limit disclosure, and the 'Free' cost signal, which is meaningful context for an agent deciding whether to call.

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; each clause (state fields, watch limits, 200 changes, Free) carries information. It is dense rather than bloated, though the parenthetical list makes it slightly long for one sentence.

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 input parameters and no output schema, the description carries the return-shape burden and does so: it names the entity, the status fields, the change window, and the cost. An agent knows enough to call it and interpret the response.

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 there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the text contradicts or misdescribes the empty schema.

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

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

States the specific resource (the watched companies for the organization) and enumerates what comes back: register status, debtor/VAT lists, plan watch limits, and the last 200 changes. It is unmistakably different from watch_company/unwatch_company or search_companies in substance, but it never names a sibling or explicitly distinguishes itself.

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 content — an agent can infer this is for viewing the watchlist rather than modifying it. There is no explicit when-to-use/when-not-to-use guidance and no mention of alternatives such as search_companies or get_company for one-off lookups.

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 cover the safety profile (readOnlyHint=false, openWorldHint=true, non-idempotent, non-destructive), and the description adds the reasons behind them: it stores a verification record (explaining the write), consumes credits from the Compliance data package, and queries external authoritative lists. That is real value beyond the structured fields.

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

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

Front-loaded with the verb and scope, and each clause (scope, match disclaiming, record storage, credit cost) carries distinct information. The single long semicolon-chained sentence is dense but not padded.

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

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

With no output schema, the description compensates by explaining that results are candidate matches requiring review and that a verification record is persisted. It leaves the response shape and whether credit is charged on failure unstated, but nothing essential to invoking 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%, so name, country, and identifiers are already documented. The description adds only the 'legal entities only' constraint and a restatement that country and identifiers are optional, which is the baseline for well-covered 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 (screen), a specific resource (company name), and the exact scope: outside the Karpata index, legal entities only, against named EU and OFAC SDN lists. An agent can distinguish this from get_risk or verify_company 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 phrase 'outside the Karpata index' implicitly sets the condition for choosing this tool over the index-based siblings, and the 'lead to review, not a verdict' note sets expectations for interpreting results. It does not, however, name a specific alternative for companies already in the index.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and closed-database behavior are covered. The description adds that results include the registration number for downstream calls, which is useful, but says nothing about result-set size, the 50-item cap, ranking, or truncation 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 sentences, front-loaded with what the tool finds and where, followed by what it returns and how that output feeds the rest of the toolset. No filler.

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

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

With no output schema, the description correctly covers returns (basic facts plus registration number) and the inputs. The only missing piece is behavior of the limit/paging mechanism, a minor gap for a 3-parameter search 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?

The description reinforces the query parameter by naming the two accepted forms (name or registration number) and enumerates the three valid country values, adding semantic clarity on top of the 67% schema coverage. The limit parameter remains undocumented in both the schema and the description.

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

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

Provides a specific verb (find), resource (companies), geographic scope (Slovakia, Czechia, Romania) and accepted lookup keys (name or registration number). It also signals the tool's role as the entry point that produces the registration number consumed by the other tools, which distinguishes it from get_company and get_financials.

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?

Implies the context clearly: use this when you have a name or registration number and need to resolve it before calling the other tools. No explicit exclusions or named alternatives (e.g., screen_name, check_vat) are stated, so the agent must infer when a sibling is more appropriate.

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 idempotentHint=true and destructiveHint=true, so the description's 'Idempotent' restates structured data rather than adding to it. The one genuinely new piece of information is 'free' (no credit cost), which is useful but is the only added behavioral context for a mutation tool; no mention of auth, what state is removed, or whether the company must currently be watched.

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 efficient fragments, front-loaded with the action and no filler. It is arguably slightly too terse given the surrounding behavioral questions, but no sentence 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?

For a simple two-parameter tool with full schema coverage and annotations covering idempotency, the description is minimally sufficient. It falls short on clarifying the destructive scope (what 'stop watching' actually removes) and on tying itself explicitly to watch_company/list_watched.

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 (regNo with IČO/CUI format notes, country enum SK/CZ/RO) are fully documented in the schema. The description adds nothing about parameters, 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?

Clear verb+resource ('Stop watching a company') that unambiguously reads as the inverse of the sibling watch_company. It doesn't explicitly name that sibling, but the operation is specific enough to be distinguished from watch/list/get tools at a glance.

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 — the agent must infer that this is the counterpart to watch_company and that callers should use it when they no longer want updates. No explicit when-to-use condition, prerequisites, or named alternative is given.

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

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

Discloses traits beyond the annotations: it consumes credits, persists a verification record (consistent with readOnlyHint=false), and returns a verdict in three named categories. This is substantive behavioral context an agent needs before invoking a credit-costing, record-creating call.

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 'KYB: verify a legal entity' and the coverage list is informative, though the single run-on sentence is dense. Every clause contributes, but it could be broken for readability.

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 2-parameter tool with no output schema and annotations already declaring safety hints, the description covers what the call produces, what it excludes, and its cost implications. Nothing essential for correct invocation 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?

With 100% schema coverage, both parameters (regNo, country) are already fully documented in the schema. The description adds no syntax, format, or edge-case guidance 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 (verify) and resource (legal entity) and enumerates exactly what one call covers: register card, register status, live VAT checks, and EU/OFAC sanctions. This makes it clearly distinguishable from siblings like check_vat or get_company, which cover narrower slices.

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?

Frames the use case ('as a customer or partner') and gives an explicit exclusion ('does not cover owners, representatives or persons'), which steers the agent toward screen_name for persons. It stops short of naming that sibling alternative by name.

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 idempotency, non-destructiveness, and non-read-only nature. The description adds useful context: it records status, debtor lists, VAT lists, insolvency; is limited by the plan's watched-company count; and is free. No contradictions.

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

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

The description is front-loaded with the core action and efficiently packs relevant behavioral details. It is three sentences with no obvious waste, though phrasing could be slightly tighter.

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

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

For a simple 2-parameter tool with full schema coverage and annotations covering safety, the description provides sufficient context: purpose, monitoring behavior, idempotency, plan limits, and cost. No output schema exists, so return values need not be described.

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

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

Schema coverage is 100%, so both parameters are fully documented in the schema. The description adds no additional parameter-level details beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific verb ('Start watching') and resource ('a company'), and explains what watching entails (compares with registers, lists hourly, records changes). It distinguishes from siblings like list_watched and unwatch_company, though not explicitly.

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

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

Usage is implied: use this to monitor a company for changes. There is no explicit guidance on when to choose this over alternatives like get_company or check_vat, nor any exclusions.

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