Companero – Romanian Company Data

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

With no annotations, the description carries full weight and is unusually transparent: it states the report is AI-generated, indicative rather than a verdict, subject to human review for critical severity, cached per data version, and requires explicit user confirmation before consuming credits. It also spells out the deviz behavior and cache charging semantics.

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

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

The body is well-structured with bullet lists and front-loaded purpose, but it opens with a long keyword dump (due diligence, raport, audit, KYC, ...) that adds noise. It is verbose overall, though most sentences carry useful behavioral or usage 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?

Despite no output schema, the description documents the JSON report shape (`oneLineSummary`, `executiveSummary`, `riskFlags[]`, `confidence`), the `report`/`_meta` envelope, cost, caching, human-review queue, and confirmation flow. An agent has everything needed to decide, invoke, and handle the response 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%, so the schema already explains `taxId`, `confirm`, and `refresh`; the description reinforces the confirmation policy but adds little per-parameter semantics beyond it. Cost, cache, and `_meta` fields are behavioral context rather than new parameter meaning.

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

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

The description opens with a specific verb and resource: it generates a company analysis report for a Romanian firm given a CUI, and explicitly states what it is not ('NU un verdict, o recomandare sau un raport de bonitate'). It enumerates the report dimensions and excludes Monitorul Oficial, which separates it from data-retrieval siblings like get_company or get_anaf_debts.

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 provides an explicit 'Când îl folosești' section with concrete user phrasings ('Vreau un raport de due diligence...', 'Verifică bonitatea...') and describes the cost/confirmation protocol. It does not name sibling tools as alternatives for narrower data needs, though it notes the financial-health indicators are the same as `get_financial_health`.

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?

With no annotations provided, the description must fully disclose behavior. It explains the scoring is not a quality verdict, phone numbers are not shown directly, missing data is reported exhaustively, and cost confirmation requirements. It also details the output structure, including scoring breakdown and data gaps.

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

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

The description is long but well-structured, front-loading the purpose with keywords, then details. It could be more concise, but each section serves a purpose: input, output, examples, lookalike mode, pricing, and phone handling. The length is justified by the tool's complexity.

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

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

Despite no output schema, the description thoroughly explains the output format, including score breakdown, motivations, and links. It also covers edge cases like missing data and cost confirmation. The complexity of 19 parameters is well-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?

While the schema has 100% coverage, the description adds context: explains how industry expands to CAEN codes, clarifies growth filter default, and details the lookalike seedCompanies behavior. One minor flag: it misidentifies integer CUI as string, but that's a schema issue.

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 clearly states it finds Romanian companies matching an ideal customer profile and returns a scored list. It distinguishes itself from sibling search tools like search_companies by focusing on matching/scoring and from screen_companies by emphasizing the prospect list output.

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?

Provides explicit usage guidance: when to use (query examples in both Romanian and English), including the lookalike mode. Does not explicitly state when NOT to use it, but the examples and context make it clear.

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

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

With no annotations, the description fully carries the behavioral burden and does so comprehensively. It discloses publication thresholds, the semantic meaning of hasDebt values (true/false/null), the distinction between 'no public debt' and 'no debt', the cost and caching rules, the confirm requirement, and update frequency. 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 well-structured with clear sections (keywords, tiers, thresholds, semantics, usage, cost), but it is quite long and includes a large keyword block at the start that is unnecessary for an agent's understanding. The essential information is front-loaded and organized, but could be trimmed without losing clarity.

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 the tool's complexity (tiers, costs, thresholds, confirm flow, semantic nuances), the description covers every aspect an agent needs: how to interpret hasDebt, the publication thresholds, the cost implications, the need for user confirmation, and update timing. It also describes return fields for summary, compensating for the lack of an output 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 coverage is 100%, so the baseline is 3, but the description adds substantial value beyond the schema. It explains the default of detail ('summary'), the credit cost for 'full' (100 credits), the exact return fields for summary, and the crucial confirm flow (never send confirm without user approval, otherwise get a quote). This is essential for correct invocation.

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 explicitly states the tool retrieves Romanian companies' tax debt status from the public ANAF list by CUI, with a clear verb-resource pair. It further differentiates between summary and full detail tiers, making it distinct from sibling tools like get_company or get_financial_health, which focus on other 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 includes a dedicated 'Când îl folosești' section with concrete example queries (e.g., 'Are firma X datorii la ANAF?') and use cases (pre-screening, KYC, factoring). It also implies when not to use it by explaining that absence from the list doesn't mean no debt, preventing misinterpretation.

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?

With no annotations, the description carries the behavioral burden itself. It adds useful behavioral context such as returning histories beyond the current ANAF window and listing the indicator categories. However, it omits response shape, pagination, limits, or error behavior, which remains a gap for a tool with no output 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?

The core instruction is concise and meaningful, but the large opening keyword block adds significant noise and delays the actual description. Several keywords repeat what the tool name already makes obvious. The structure is not front-loaded for an agent trying to decide when to use the 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?

For a simple two-parameter read tool with fully described parameters, the description is adequate: it states what is returned, the optional filter, the input identifier, and the relevant sibling for a broader request. Missing output-format details are minor here.

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 baseline is 3. The description restates that year is an optional filter and taxId is the Romanian CUI, but adds little 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 uses a specific verb ('Returnează') and identifies the exact resource: financial indicators by fiscal year for a company identified by CUI. It enumerates the specific indicators returned and distinguishes itself from the sibling get_company by noting when get_company is preferable.

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 clearly implies its primary use case: retrieving financial indicators. It explicitly advises using get_company with include balanceSheets when the company profile is also needed, providing a concrete alternative and a condition for choosing it. It does not spell out exclusions for other siblings, but the guidance is clear enough.

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?

With no annotations provided, the description carries the full behavioral burden, and it is exceptionally thorough. It discloses cap behavior (`capReached`, empty lists, meaning of cap message), distinguishes `governance from `procedural` legal representatives, warns about radiated companies, explains phone-number handling (`phone.known`, `phone.seeOn`), and details the quote-vs-confirm flow. This goes well beyond a minimal description.

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 long, but the length is justified by the tool's complexity: costs, caps, free alternatives, and a confirmation flow all need explanation. It is organized into clear paragraphs and uses clear warnings. The leading keyword block is somewhat redundant and could be trimmed, but the rest is dense and purposeful 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 a tool with no output schema and no annotations, the description covers the full operational contract: required CUI, available sub-resources, credit costs, cap semantics, confirmation flow, and even how to phrase results to users regarding radiated companies and capped legal representatives. An agent has enough context to call the tool correctly and to handle 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?

The schema already documents `taxId`, `unlock`, `confirm`, and `include` well, giving a baseline of 3; the description enriches this substantially by enumerating accepted modifiers like `balanceSheets:last10`, `balanceSheets:2020-2024`, `"*"`, and object-form examples. However, there is a conflict: the description claims the `include` parameter can be an object, while the input schema declares `include` as `array` or `null` only. This inconsistency slightly muddies what an agent can safely send.

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: 'Returnează profilul unei companii românești după CUI' and explicitly contrasts it with `search_companies`, which finds companies by criteria. This clearly distinguishes the tool and disambiguates it from its closest sibling. The additional `include` options further specify what is possible 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?

The description gives explicit when-to-use guidance: use it when you already have the CUI and want a profile, naming `search_companies` as the alternative. It also gives prescriptive usage rules: prefer a single `include` call over multiple tool-calls, requires `confirm: true` for credit-consuming calls, and instructs when to use `unlock` only after explicit user consent. This is actionable and prevents misuse.

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?

With no annotations, the description carries the full behavioral burden, and it does so thoroughly: it discloses the paid cost, the confirm-before-consumption mechanism, the frameworkValue caveat, the joint-contract value rule, and the important semantic caveat that 'competitor' means shared CPV activity, not necessarily bidding in the same procedures. This goes well beyond what the schema or annotations provide.

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

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

The description is well-structured with clear sections, but it opens with a long keyword list that delays the actual purpose statement, and the confirmation behavior is partly repeated from the parameter schema. Once past the keyword block, most content earns its place by explaining output fields, interpretation rules, and alternatives.

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 paid, data-rich tool with no output schema, the description is complete: it enumerates returned fields (firmClasses, competitors), explains enrichment with fiscal/registry data, warns about interpretation pitfalls, gives cost confirmation behavior, and points to sibling tools for other use cases. An agent has enough to decide when to call it and how to handle 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?

Although schema coverage is 100%, the description adds essential meaning beyond the schema, especially for confirm: it explains that without confirm the call returns a DEVIZUL (cost, balance, free alternative) and consumes nothing, and that the exact same call must be retried with confirm true. It also frames taxId as the Romanian CUI, which matches the schema but is reinforced contextually.

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 clearly states the verb, resource, and exact scope: it identifies competitors of a Romanian company by CUI, based on shared 4-digit CPV classes in the last 2 covered years, excluding the company itself. It also names sibling alternatives (get_cpv_market, get_company_contracts), which makes it easy to distinguish from related tools.

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 'Când îl folosești' section gives explicit query examples, and the final paragraph tells the agent which sibling to use for market-level CPV analysis and for company contracts. It additionally explains the paid-call confirmation flow, which is crucial for correct invocation.

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?

No annotations are provided, so the description carries the full burden, and it delivers: tier behavior (summary vs full), credit consumption and confirm semantics, acord-cadru vs contract separation, interpretation caveats, and the non-guarantee meaning of hasPublicContracts:false. It even warns against drawing conclusions beyond facts.

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 text is long but well organized with headings and bullet-like separations, and each section earns its place. The keyword block at the top and license/source sentence add some redundancy and delay the core action, so it is not maximally concise.

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 paid metered tool with no output schema, the description is unusually complete: it enumerates summary fields, full-mode additions, stateShare semantics, field-by-field facts, data source/licensing, and the confirm flow. An agent has enough context 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?

Although the schema already covers all three parameters, the description adds material meaning: detail defaults to free summary vs paid full with 2 credits, confirm triggers a non-consuming 'deviz' unless true, and taxId means Romanian CUI. This goes well beyond the baseline for 100% schema coverage.

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

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

The description states a specific action and object: returning a Romanian company's involvement in public procurement as supplier (by CUI) from SEAP/SICAP. It clearly distinguishes this from sibling tools by limiting scope to awarded-supplier contracts rather than market stats, debts, or general company 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?

Provides an explicit 'Când îl folosești' section with five concrete query types and due-diligence/KYC use cases. It does not name sibling alternatives or state when not to use it, so it stops short of full exclusion 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?

No annotations are provided, so the description carries the full burden. It discloses key behaviors: edge construction uses only high/medium confidence identity links, excludes ambiguous common names, insolvency practitioners don't create edges, hubs (>50 firms) don't expand, data are public ONRC facts, no pattern inference is exposed (DPIA), and computed:false indicates network rebuild pending. It also explains cost tiers and confirmation flow, plus data refresh after monthly ONRC import. This is exemplary 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?

The description is long and comprehensive but structured with clear sections (keywords, main purpose, differentiation, tiers, semantics, usage, cost). It is not concise – there is a large keyword block that adds little value for an AI agent (keywords are likely for internal search). The key information is front-loaded after keywords, but the keyword list is noise. Some redundancy exists (cost mentioned in two places). However, the structure is logical and every major behavioral aspect is covered, though the length could 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 complex tool with no output schema and no annotations, the description is remarkably complete. It covers purpose, usage scenarios, tier details, behavioral semantics, cost confirmation, data freshness, and limitations (no pattern inference). The output structure for both tiers is described with field names. Even though there's no output schema, the description provides enough for an agent to understand what will be returned. Nothing critical 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% – all three parameters (taxId, detail, confirm) have descriptions in the schema. The description adds semantic detail: detail toggles between summary and full with different response shapes and costs, confirm is required for credit-consuming calls and returns a quote otherwise. While the schema already provides basic descriptions, the description enriches meaning with tier definitions and confirmation semantics, but much of this could be inferred from the schema. Baseline 3 is appropriate.

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

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

The description explicitly states the tool returns the company group of a Romanian company by CUI, including connected firms and factual history of connecting persons. It clearly distinguishes itself from due_diligence by focusing strictly on network/group dimension. The verb 'Returnează' plus resource 'GRUPUL DE FIRME' and scope (after CUI) is specific and 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?

The description provides explicit when-to-use examples ('Ce alte firme are administratorul firmei X?', 'Face parte firma X dintr-un grup de firme?') and explicit exclusions (does not cover financial profile – use get_financial_health and get_balance_sheets). It also distinguishes from due_diligence with cost and scope. The 'Când îl folosești' section gives concrete trigger scenarios, and the cost confirmation behavior is clearly explained.

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?

With no annotations present, the description carries the full burden and does it thoroughly: it discloses data sources, coverage limitations, the separated reporting of framework values, consortium award handling, and the credit-confirmation behavior. It even warns against summing contractValue and frameworkValue.

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 long and includes a redundant keyword block, so it is not maximally concise. However, it is well-structured into clear sections (interpretation, usage, cost confirmation) and front-loads the core purpose before diving into parameter detail.

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

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

Given the tool's complexity, four parameters, no output schema, and no annotations, the description is remarkably complete. It covers what the tool does, how to invoke it, what outputs to expect at each tier, data caveats, and the credit-confirmation protocol. Nothing critical is missing for correct usage.

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

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

Schema coverage is already 100%, but the description adds substantial meaning: cpvPrefix gets concrete examples and format rules, year gets a default explanation, detail gets tier semantics, and confirm gets a full behavioral explanation about returning a quote instead of executing. This goes well 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 names a specific verb and resource: analyze the CPV market in Romanian public procurement. It clearly differentiates itself from sibling tools by stating that for a single company's contracts one should use get_company_contracts and for competitors get_company_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?

Provides explicit when-to-use examples (e.g., 'Cine câștigă licitațiile de construcții?', 'Cât de concentrată e piața?') and explicitly names alternatives for related but different tasks. Also clearly explains the paid/free tier behavior and the confirm flow.

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?

With no annotations provided, the description carries the full burden and does it thoroughly. It discloses null semantics (null ≠ 0), the academic nature of Altman Z (not a verdict), the negativeEquity flag, the free vs paid tiers, and the confirm flow for paid calls (DEVIZ first, then replay with confirm:true). It also mentions data limitations (microentities may lack fields).

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

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

The description begins with a large keyword block that is redundant and does not help an agent select the tool. The rest is structured with sections, bold titles, and clear indicator groupings, but the overall length is inflated. Valuable information is present, but some sentences are repetitive (e.g., cost details are repeated), so it does not fully earn its length.

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 tool with no output schema and complex behavior (two detail tiers, paid confirmation), the description compensates well by listing indicator groups, explicating the Altman Z zones, and clarifying the confirmation flow. It does not give an exact response JSON shape, but an agent can infer what to expect. Slightly more explicit response structure would make it 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 description coverage is 100% for all parameters, so the baseline is 3. The description adds value beyond the schema by explaining what each detail level returns (indicator groups, multi-year series) and by elaborating the confirm behavior (returns a quote without consuming credits). It does not substantially expand on taxId beyond the schema's 'Romanian CUI', but the added detail/confirm context justifies a 4.

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 clearly states the tool computes and returns deterministic financial indicators for a Romanian company by CUI from ANAF balance sheets. This distinguishes it from sibling tools like get_balance_sheets, which would provide raw data. The two detail tiers are also clearly explained, so an agent can understand what the tool does 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?

The description includes a concrete 'Când îl folosești' section listing example questions and use cases (due diligence, credit analysis, B2B screening). It also explains when to choose 'summary' vs 'full' and notes the cost difference. However, it does not explicitly mention alternative tools or when not to use this one, stopping short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does so thoroughly: it discloses data sources (ANAF + ONRC), precomputation, the ≥30-firm threshold for percentiles, fallback behavior via `usedNationalFallback`, the `smallSegment` flag, the exact-one-of-two segment rule, and that the tool is free ('Gratuit'). The agent knows what will happen, including edge cases, before calling.

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 well-structured with clear sections: keyword block, main definition, parameter constraints, usage examples, and disambiguation. It is longer than average, and the opening keyword list is somewhat repetitive with the body, but every section adds operational value. The main behavior and exclusions are front-loaded early.

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 4-parameter, no-output-schema tool with no annotations, this description is exceptionally complete. It explains what is returned, how the segment is uniquely selected, what optional filters do, when fallbacks occur, and which sibling tools to use instead. An agent has enough information to invoke it correctly and interpret the important edge cases without any missing context.

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?

Although input schema coverage is 100%, the description adds meaning the schema does not: `caenCode` must be a 4-digit class code and 2–3 digit codes are explicitly unsupported, `industry` must come from the 34 Companero industries with `list_industries` as a fallback, and the two are mutually exclusive. It also clarifies that `year` affects only counts while percentiles remain on the reference year. This is substantive semantic guidance beyond the schema descriptions.

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 definition: 'Statistici AGREGATE pentru un segment de piață din România' and lists exact return values (active/new/dissolved firms, P25/median/P75 percentiles, multi-year trend). It distinguishes itself from siblings in the 'Disambiguare' section, explicitly contrasting with search_companies, list_industries, get_cpv_market, and get_financial_health. This is far beyond a vague restatement of the tool name.

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 'Când îl folosești' section provides concrete natural-language queries that map directly to this tool, such as 'Care e cifra de afaceri mediană a firmelor de software din Cluj?' and 'Câte firme s-au înființat / radiat în construcții anul acesta?'. The 'NU confunda cu' section explicitly says when to prefer alternative sibling tools, e.g., search_companies for individual companies. No usage context is left 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?

With no annotations provided, the description carries the full burden. It thoroughly discloses key behaviors: it is read-only (returns data, no modifications), requires authentication (401 for anonymous), implies cost via credits ('1 credit per apel' and the confirm flow), and describes pagination, data source (ONRC), and privacy (no CNP). The description also explains the confidence levels, which is critical for interpreting results. It only lacks explicit rate-limit disclaimers, but the cost/auth/privacy coverage is exceptional for a tool with zero annotation support.

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 well-structured with clear headers and bullet points, front-loading the purpose and key usage scenarios. It is longer than strictly necessary, but every sentence earns its place by adding functional detail. The inclusion of the `linkConfidence` legend and the confirmation flow are particularly valuable. It could trim some repetition (e.g., the cost is mentioned twice), but this does not detract significantly.

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?

This is a complex tool with 7 parameters, no output schema, and no annotations, yet the description covers everything needed to invoke it correctly: the required ID's origin, the default behavior, the pagination options, the cost model (credits, EUR/RON, confirm), the data-source legality, the absence of CNP, and the interpretation of confidence levels. It even provides the exact `companyTaxId` field for checking membership. Although an output schema is absent, the description volunteers the response structure in detail, so agents have a complete mental model. Nothing critical 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%, but the description elevates each parameter with critical context. It explains that `limit` and `offset` control pagination, that `onlyActive` defaults to true and can be set to false for historical roles, and that `confirm` is a cost-consent gate. It also clarifies the deprecated aliases (`page` and `pageSize`) encouraging use of `offset` and `limit`. This goes well beyond the schema's basic type hints, making parameter semantics exceptionally clear.

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 is precise: it names the specific verb ('Returnează profilul complet al unei persoane fizice'), the resource (person identified by ID), and its scope (roles, companies, confidence levels). It clearly distinguishes from siblings like search_persons by stating it takes an ID and returns a full profile, and from get_company by focusing on person-centric data. It also provides concrete use-case examples, eliminating any ambiguity about its role.

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

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

The description explicitly states when to use the tool ('CÂND îl folosești' section) with four concrete scenarios, each mapping to specific fields like `roleCategory: procedural` and `isActive`. It also explains when NOT to use it implicitly by noting that direct calls follow `search_persons`, and it provides explicit instructions on using the `confirm` parameter as a prerequisite for paid calls. This is a model of usage 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?

With no annotations, the description carries full behavioral disclosure. It covers authentication requirements, job ownership, status lifecycle, progress fields, truncation behavior, and the sync alternative, going far beyond the schema.

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

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

The structure is organized into purpose, input, output, and usage note. The keyword blocks at the top are redundant and add noise, but the rest is efficient and information-dense without being bloated.

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

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

There is no output schema, so the description must explain return values; it does so thoroughly with statuses, the progress object shape, and the summary aggregates. Nothing essential for correct invocation seems 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?

Although schema coverage is 100%, the description adds meaningful parameter meaning: jobId is defined as the id returned by screen_companies, and includeItems is explained with its default value, item limit, sorting rule, and truncation signal.

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: 'Ia starea și rezultatul unui job de verificare portofoliu creat cu screen_companies.' It is clearly distinguished from the sibling screen_companies by framing get_screening as the polling/result tool for asynchronous jobs.

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

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

It explicitly states when to use it: after an async call for more than 20 companies, and when not to use it: for ≤20 companies screen_companies already returns the full report synchronously. This gives the agent actionable routing between 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?

There are no annotations and no output schema, so the description carries the full behavioral burden. It communicates that this is a read-only listing and names the returned fields, but it does not disclose ordering, exhaustiveness, pagination, or failure behavior; this is acceptable for a simple list but not fully transparent.

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 structured in short functional segments: purpose, return fields, and usage. The keyword block is somewhat redundant but serves multilingual matching, and the actionable guidance is front-loaded.

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

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

For a zero-parameter taxonomy list, the description covers purpose, output fields, and integration with search_companies. It is complete enough to invoke correctly; a small gap is the lack of explicit statement about whether the list is exhaustive or localized.

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

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

The tool has zero parameters, so there is no schema semantics for the description to supplement. The description adds contextual meaning by explaining how the tool's output (id/name/slug) is meant to feed into search_companies, which is more than the empty 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 opens with a precise verb and object: 'Listează industriile... disponibile pe Companero' and specifies the returned fields (id, nume, slug). It clearly distinguishes this from the sibling search tools by framing it as a CAEN/NACE taxonomy lookup rather than a company search.

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

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

It explicitly states when to use it: when the user wants companies from a sector, and gives concrete examples ('firme din IT', 'construcții'). It also names the downstream alternative, search_companies, explains how to pass the id into the `industry` parameter, and notes the id step is optional because search_companies accepts names directly.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It explains that results are facts, not risk scores or recommendations, that status_event was formerly insolvency_history, that sync vs async behavior depends on list size, and that companies not found are not charged. It also documents the quote/confirm flow and authentication requirement.

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 well-organized into labeled sections and nearly every substantive section earns its place. However, it opens with two long keyword-stuffing lists and repeats the 'facts, not verdicts' point twice. It is comprehensive but not tightly edited or 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?

There is no output schema or annotations, yet the description covers the returned flags and severities, default sorting, not-found and error cases, async polling via get_screening, authentication, and credit costs. An agent has enough detail to call the tool correctly 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?

Although schema coverage is already 100%, the description adds significant meaning: taxIds accepts numbers or strings, ignores 'RO', and is capped at 100; label is purely a user-facing job name; confirm enables quote-only behavior and must be sent only after user approval. This goes well beyond the schema's field descriptions.

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 verifies a list of Romanian companies by CUI and returns deterministic factual signals per company. It also explicitly distinguishes screen_companies from due_diligence and get_company by defining what each alternative does. The opening keyword block is noisy, but the core purpose is unmistakable.

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

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

There is an explicit disambiguation section ('Când NU e potrivit') that names due_diligence and get_company as alternatives and clarifies that screen_companies handles deterministic list screening. It also gives concrete usage context: accountants, credit control, bulk partner lists, and the sync/async threshold.

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?

No annotations are present, so the description carries the behavioral burden. It discloses search semantics (substring, diacritic-insensitive), the return shape, allowed locality types, and the fuzzy-resolution boundary vs. `search_companies`. It does not explicitly say 'read-only/no side effects', but the registry and return-wording make the lack of mutation clear enough.

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

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

The core content is well-structured with bullets and a clear boundary section, but the long keyword block at the top is largely redundant and delays the actual definition. The description is informative but not tight; every element does not earn 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 tool with no output schema and no annotations, this description is unusually complete: it gives return fields, type enumeration, concrete use cases, disambiguation behavior, pagination-related parameters via the schema, and sibling boundaries. An agent has everything needed to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful context for `name` (partial, diacritic-insensitive) and county filtering, and it points to `search_counties` for county IDs, but it does not systematically enrich every parameter beyond what the schema already 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: it is the Romanian localities registry, searches by partial name and/or county filter, and returns a defined shape. It also explicitly distinguishes itself from `search_companies`, so an agent can tell it apart from siblings 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?

A dedicated 'Când îl folosești' section lists concrete use cases (count sectors, list communes, disambiguate counties, validate names) and a 'Graniță față de search_companies' section explains when not to use it and which alternative to use instead. This is explicit when/when-not guidance.

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

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

With no annotations provided, the description carries full responsibility. It discloses return format (totalCount, sample, webOrderUrl), the max limit of 5, the partial coverage issue with bsYear (with a warning), and explicitly states that the tool does NOT initiate orders. This is thorough 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?

The description is lengthy but dense with necessary information. It is structured into clear sections: an introductory keyword block, a definition of what the tool does, return values, usage for name lookup, and an important note about webOrderUrl. While verbose, every sentence contributes useful content, though it could be slightly more streamlined.

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 the high complexity (35 parameters, no output schema), the description is remarkably complete. It covers the return values, the workflow for name-based lookup, the purpose of webOrderUrl for full data/export, and important caveats like the partial balance-sheet-year coverage. It addresses all essential aspects an agent would need to use this tool 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?

Despite 100% schema coverage, the description adds substantial value beyond schema descriptions. It explains the name parameter's role in identifying a specific company, the default behavior and partial coverage of bsYear, the object format for orderBy, the meaning of growthFilter and minGrowthPercent, the default for stateRegistration, and provides equivalent UI parameter names (f[...]) for many filters.

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 explicitly states the tool searches Romanian companies and can identify a specific company by name. It clearly defines the action ('Caută firme românești sau identifică o firmă specifică după denumire') and distinguishes itself by mentioning the get_company tool for full profiles, which separates it from related tools.

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 provides explicit when-to-use instructions: it explains that for identifying a specific company, call with 'name' and then use get_company with the CUI for full profile. It also tells when to use webOrderUrl for full lists/exports, and notes the tool does not initiate orders. This is clear and 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?

No annotations are present, so the description carries the full burden. It discloses that name matching is diacritic-insensitive, that id is always an array and combines with name via AND, and that the return fields include shortCode (license plate code). It does not explicitly state the operation is read-only, but as a search tool this is implied and not misleading. The description adds meaningful behavioral details beyond the schema.

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

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

The description is front-loaded with a keyword block that is redundant for an AI agent but not harmful. The core description is well-structured with 'Când îl folosești' and 'Graniță' sections, making it easy to scan. It is longer than necessary due to the keyword list, but every sentence in the main body 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 search tool with four parameters and no output schema, the description is exceptionally complete. It explains what it returns, when to use it, the boundary with a sibling tool, and provides usage examples. Nothing an agent needs 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% (all parameters described). The description adds context beyond the schema by explaining the meaning of shortCode (license plate code) and clarifying how id and name interact (combinat cu name aplică și name). It also gives example values like 'clu' and 'bistrița', which help the agent understand the fuzzy matching. While it doesn't detail limit/offset beyond schema, the added value is sufficient to raise the baseline from 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?

The description explicitly states the tool's function: it searches the Romanian county nomenclator (41 counties + Bucharest) by partial name or ID and returns {id, name, slug, shortCode}. It clearly distinguishes itself from siblings by naming search_companies as the alternative for filtering companies, making its purpose 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?

The description provides concrete use cases (e.g., 'Ce județ are codul CJ?', validating misspelled county names) and explicitly states when NOT to use it: for filtering companies, search_companies handles county resolution directly. This gives the agent clear decision criteria.

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?

With no annotations provided, the description carries the full burden and does so extensively. It discloses the data source (ONRC Open Data), aggregation logic by name and birth data, structural exclusion of UNRESOLVED clusters, anonymous vs authenticated access limits, confidence tier semantics, credit cost for get_person, and the GDPR constraint that no CNP is returned. This goes far beyond a basic operation description.

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 long but well-organized with clear headers, bullet lists, and bolded keywords. Almost every section earns its place given the complexity of auth tiers, confidence levels, and disambiguation rules. The opening keyword block is somewhat repetitive, but the overall structure makes the detail navigable rather than overwhelming.

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

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

There is no output schema, so the description must explain return values and behavior, and it does. It lists anonymous result fields (name, companyCount, profileUrl) and authenticated fields (birthYear, knownCounties, occurrenceCount, confidence), explains default sort behavior, and covers cost, access, disambiguation caveats, and follow-up via get_person. 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful context by explaining how filters like county and birthYearFrom/To are used for disambiguation and by clarifying that minConfidence filters out lower tiers. It also maps anonymous vs authenticated limits to the limit parameter and directs users away from legacy page/pageSize aliases.

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 clear verb-and-resource statement: 'Caută o persoană fizică ... și află în câte firme românești apare.' It also distinguishes itself from get_person, which is the follow-up for full profiles, and from related search tools like search_companies and search_cities. The keyword block and role enumeration (administrator, asociat, lichidator) further specify the exact domain.

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 'CÂND îl folosești' section provides explicit, concrete use cases with complete workflows, such as 'În câte firme apare X?' followed by 'get_person', and conflict-of-interest checks via company taxId. It also explains when to filter by county or birth year to reduce candidates before spending credits, effectively giving both when-to-use and when-to-defer guidance.

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