Companero – Romanian Company Data

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 richly: pricing tiers (anonymous teaser of 5 results vs authenticated 3 credits per search), the confirm:true gating that returns a quote without spending, the rule that phone numbers are never shown in chat but exposed via contact.phone.known/seeOn, and explicit dataGaps reporting for missing fields. It also warns that the score measures criteria match, not company quality.

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 Input/Output/When-to-use/pricing sections, but the opening 'Keywords:' blocks in Romanian and English consume several lines of near-duplicate terms before any actual purpose is stated. This is retrieval-style filler rather than task guidance and delays the front-loading of what the tool does.

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

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

Despite having no output schema, the description thoroughly describes the return shape (0-100 match score, per-criterion breakdown, natural-language motivation, profile link, webOrderUrl for CSV export, dataGaps) and covers the credit/spend model. It is complete enough to call correctly, with only minor omissions such as ordering/pagination nuances that pagination params partly cover.

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 already 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that seedCompanies switches to a lookalike/embeddings mode combined with deterministic scoring, that growthFilter defaults to a 10% threshold adjustable via minGrowthPercent, and the exact behavior of confirm. This meaningfully raises it above the schema-only 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 states a specific verb and resource: it finds Romanian companies matching a user-described ideal customer profile and returns them as a scored, justified prospect list from the 2.7M-company Companero database. It is clearly distinguishable from siblings like search_companies or screen_companies. The only weakness is that the purpose is buried beneath a large block of keyword aliases, so it is clear but not optimally front-loaded.

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 seven concrete example queries in Romanian and English plus an explicit LOOKALIKE mode with its own trigger phrases, so an agent knows when to invoke it. The credit-confirmation workflow (quote first, then re-issue with confirm: true) is spelled out. However, it never explicitly says which sibling tool to prefer for adjacent tasks (e.g. due_diligence or get_company), so alternatives are not contrasted.

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?

No annotations are provided, so the description carries the full burden and meets it: it discloses the two paid/free tiers and their credit costs, the confirm:true cost-confirmation flow, and interpretation caveats (contractValue excludes frameworkValue, association wins counted in full per member, coverage from 2018 with no direct purchases). These are exactly the behaviors an agent could not infer otherwise.

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 front-loaded with sections (tiers, interpretation caveats, when-to-use, alternatives, cost confirmation), but roughly seven lines of keyword stuffing ('autoritate contractantă, primărie achiziții...') occupy prime space and contribute little to an agent deciding or invoking the tool. Useful density is high, but a meaningful chunk of the text 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 no-annotation, no-output-schema tool this is complete: it covers both tiers and their costs, the confirmation protocol, coverage limits, and value-interpretation traps, leaving nothing an agent needs to call it correctly unstated.

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 real meaning beyond the schema: it tells the agent where to obtain taxId (search_companies or the /autoritati pages) and contrasts the two detail tiers by output size and cost. The added value is genuine but modest, since the schema already defines all three fields.

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

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

States a specific verb and resource: 'Profilul de CUMPĂRĂTOR al unei autorități contractante românești' from SEAP/SICAP data, with the exact scope (cât atribuie, cui, pe ce domenii CPV). It explicitly names what it is not by routing to get_cpv_market, get_company_contracts and get_company_competitors, so an agent can distinguish it from siblings without opening any 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?

A dedicated 'Când îl folosești' section lists concrete trigger queries ('Cine vinde la Primăria X?', offer preparation, journalism/due diligence) and closes with explicit alternatives and the condition selecting each. Nothing 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, 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, the description carries the full behavioral burden and does so extensively: free vs paid data, authentication requirements for `legalRepresentatives`, monthly caps, `capReached` semantics, `unlock` cost, phone-number handling, and the `confirm` estimate flow. It also warns not to misreport capped or procedural legal representatives.

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 purpose is buried after a long keyword list, and the description is very long. However, the cost, cap, and confirmation details are structured and relevant for a tool with this much conditional behavior, so the verbosity is mostly justified.

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 are no annotations and no output schema, but the description compensates by explaining return behavior, credit usage, legal-representative caps, phone-number visibility, and the confirmation flow. An agent has enough information to invoke it correctly.

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

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

Although the schema description coverage is 100%, the description adds substantial meaning beyond the schema: it explains `include` token and object forms, modifiers like `balanceSheets:last10` and year ranges, and the cost/auth/cap implications of `legalRepresentatives`, `unlock`, and `confirm`.

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 returns the profile of a Romanian company by CUI/tax ID. It also explicitly distinguishes itself from `search_companies`, which finds companies by criteria rather than by known tax ID.

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

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

It gives a clear when-to-use condition: use when you already have the CUI and want that company's profile. It names `search_companies` as the alternative and explains when to use each `include` sub-resource.

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?

With no annotations, the description carries the full burden and does so: it discloses tier pricing (free vs 10 credits), the DEVIZ/confirm protocol, edge-confidence rules, exclusion of insolvency practitioners, isHub handling, computed:false semantics, and what the tool deliberately does NOT expose (GDPR/DPIA pattern inference). This is unusually rich behavioral disclosure.

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

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

The body is well organized with tier, semantics and usage sections, but it opens with a very large bilingual keyword block that consumes a lot of space without telling an agent anything actionable about invoking the tool. The content is long enough that the genuinely important routing sentences are buried mid-description.

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?

No output schema exists, yet the description specifies the returned fields for both tiers (groupSize, connectorCount, connectors[], groupMembers[], etc.) and the computed flag, so an agent knows what to expect. Combined with the cost/confirm rules, nothing needed 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 baseline is 3, but the description adds real meaning: it enumerates the exact return payload of detail='summary' vs 'full', quantifies the cost of each, and explains that confirm without an explicit call returns a quote rather than consuming credits. That goes beyond the schema's terse enum note.

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

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

States a specific verb and resource ('Returnează GRUPUL DE FIRME al unei companii românești (după CUI)') and immediately scopes it to network/group connections via shared persons. It explicitly distinguishes itself from get_company, get_financial_health and get_balance_sheets, so an agent can route without opening any 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?

Includes an explicit 'Când îl folosești' section with four concrete trigger phrasings, names the sibling tools that cover the other dimensions, and spells out the free vs paid tier decision. The confirm/cost flow adds a further explicit procedural condition.

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, the description carries the full behavioral burden and does so: it discloses the pure-computation/no-LLM nature, the free cost on both tiers, that `detail: "full"` triggers an authorization flow for anonymous callers while `summary` stays anonymous, the `confirm: true` deviz-then-rerun mechanism, and that the confirm/cost paragraph is generic boilerplate. It also documents edge semantics beyond structured data: `null` means uncalculable (≠ 0), negative equity emits a `negativeEquity` flag, and industry positioning requires segments of ≥30 firms with the 1.1/2.6 Z″ zone boundaries.

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 bolded group headers and bullets, but the opening is a large SEO-style keyword dump in two languages that adds search-surface noise rather than selection value. The trailing cost/confirm paragraph is generic boilerplate that states the tool is free on both tiers, making its 'credits would be consumed' scenario largely non-applicable here.

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?

No output schema exists, so the description must explain returns — and it does, listing every indicator group, the tier-dependent payload, the Altman Z″ component breakdown, industry percentile basis, and the `null`/`negativeEquity` conventions. Slightly reduced because the priority-order and default behavior of `detail` are stated but the actual response shape per tier is described narratively rather than precisely.

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 substantially enriches the `detail` parameter beyond the schema's one-line gloss: `summary` is DEFAULT and FREE, returns netMargin + leverageRatio + turnoverGrowth for the latest year plus industry position, while `full` is multi-year and adds Altman Z″ components and duel-segment positioning. taxId is only glossed as 'Romanian CUI', but that identifier is well understood.

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

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

States a specific verb+resource: 'Calculează și returnează indicatori financiari determiniști pentru o firmă românească după CUI, din bilanțurile ANAF', and enumerates the exact indicator groups produced. The purpose is unambiguous, but it never explicitly contrasts itself with the sibling get_balance_sheets (raw statements) versus this computed-ratio tool, so the differentiation is implicit rather than stated.

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?

Includes a dedicated 'Când îl folosești' section with concrete trigger phrasings ('Care e lichiditatea / solvabilitatea firmei X?', Altman Z questions, margin evolution) plus named scenarios (due diligence pre-collaborare, credit/factoring analysis, B2B screening). It also gives the selection rule between the tool's own tiers: use `summary` for the competitive-position question, `full` for complete due diligence / credit analysis.

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 and does so well: it discloses data provenance (ANAF balance sheets + ONRC registry, precomputed), the ≥30-firms threshold for percentiles, the national-fallback behavior flagged via usedNationalFallback, the smallSegment signal, and that the tool is free.

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 organized into purpose, selection rules and disambiguation, but it opens with a large bilingual keyword dump that is largely SEO noise for an agent and inflates the size. The substantive content earns its place; the keyword block does not.

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 no-annotation, no-output-schema tool of this complexity, the definition covers return contents, edge-case fallbacks, segmentation constraints and routing to siblings thoroughly enough that an agent can call it correctly without guessing.

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 a 3 is the baseline, but the description adds real meaning beyond the schema: caenCode must be exactly 4 digits and 2–3 digit codes are rejected (with the reason), caenCode and industry are mutually exclusive, industry accepts name/slug/id, and year affects only counts while percentiles stay on the reference year.

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 precise verb+resource: aggregated statistics for a Romanian market segment (industry or 4-digit CAEN code, optionally narrowed to a county), and enumerates the returned metrics. It explicitly contrasts itself against search_companies, list_industries, get_cpv_market and get_financial_health.

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 'when to use' section with representative queries (median turnover in Cluj software, company formation/dissolution counts, market sizing) and a dedicated disambiguation block naming each sibling it should not be confused with, plus the reason. Nothing 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 and delivers: auth requirement, sync behaviour for ≤20 CUIs vs async job for 21–100 with jobId/status, per-company credit pricing with unused CUI not charged, the `confirm: true` quote-then-execute flow, flag lists with severity tiers, default sort order, and the caveat that outputs are facts not verdicts. It even documents the `status_event` / legacy `insolvency_history` naming change.

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?

Core content is well-structured and front-loaded with the operative behaviour, sync/async rules, and pricing. However, the twin RO/EN keyword blocks are long and largely duplicate content already conveyed by the body, which bloats the definition well past what an agent needs to select and invoke 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 non-annotated, no-output-schema tool, the description is essentially complete: it explains inputs, cost mechanics, confirmation gating, sync/async routing with the follow-up tool named, the flag vocabulary with severities, sort behaviour, and the semantic warning about state events not implying insolvency.

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 real meaning on top: the max of 100 CUIs and the error on overflow, the RO-prefix handling, the purpose of `label` as a job name, and crucially the behavioural consequence of list size (sync vs async). The `confirm` parameter's negotiation semantics (never send proactively, ask the human first) are reinforced beyond the schema text.

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 precise verb and resource: it verifies a LIST of Romanian companies by CUI and returns deterministic factual signals per company (inactive/deregistered, ONRC state events, ANAF debts, negative equity, financial pressure, etc.). It explicitly contrasts itself with the sibling `get_company` (single-profile lookup) and `get_screening` (async result retrieval), so an agent can route 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?

Has an explicit 'Când NU e potrivit' disambiguation block naming the alternative (`get_company` = individual profile, `screen_companies` = list signals), and names intended users (accountants, credit control, distributors with many clients). It also states the split between synchronous and asynchronous flows and the tool used to retrieve async results.

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 disclose a lot: diacritic-insensitive matching, the returned object shape, the closed set of locality types, and the ambiguity-disambiguation behavior. It does not mention auth/permission requirements, rate limits, or what happens on empty results, but for a read-only lookup the coverage is solid.

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-organized into purpose, return contract, and when-to-use sections, and it is front-loaded. However, the opening paragraph is a very long keyword dump ('localitate, localități, oraș...'), which is retrieval-oriented padding rather than description; it inflates the definition substantially without adding semantic guidance.

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 5-param, no-required, no-annotation, no-output-schema tool, the description supplies the return fields, the type vocabulary, the filters, and the sibling boundary, which is nearly everything needed to invoke it correctly. The only gaps are operational details (pagination behavior beyond schema, error/empty-result handling) that 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 already 100%, so the baseline is 3, but the description adds real meaning: 'name' is substring + diacritic-insensitive, and countyId filtering is tied to the disambiguation use case ('același nume apare în mai multe județe'). It does not restate the 'Mereu array' or pagination defaults, which is correct since the schema handles those.

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

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

States a specific verb and resource ('Nomenclatorul localităților României. Caută după nume parțial... filtrat pe județ') and lists the exact return shape and entity types. It explicitly distinguishes itself from siblings, especially search_companies and implicitly search_counties, so an agent can tell which tool to pick without opening any 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?

Provides four concrete when-to-use scenarios (counting Bucharest sectors, listing communes in Cluj, disambiguating a locality name across counties, resolving an internal id/type) plus an explicit boundary rule against search_companies. This is the strongest part of the definition.

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 and does disclose important behavior: the tool does NOT place orders ('Tool-ul NU inițiază comenzi'), results are capped at a sample (limit max 5) with a webOrderUrl escape hatch, and the most-recent balance-sheet year has partial coverage. It omits auth, rate limits, and what happens on huge result sets, so it is strong but not exhaustive.

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

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

The substantive paragraphs are well-ordered and earn their place, but the opening 'Keywords:' block is a long SEO-style term list that adds selection value for a human searcher, not for an agent choosing a tool. That block dilutes the front-loading; the actual purpose statement should come first.

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 35-parameter search tool with a fully documented schema but no output schema, the description adequately covers the return shape (totalCount, sample with CUI and profile URL, webOrderUrl) and the name-lookup workflow. A note about pagination interaction between offset/limit and the >5 cap would close the remaining gap.

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

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

Schema description coverage is 100%, so the schema already documents all 35 parameters including the {gte,lte,year} shape and the bsYear default warning. The description adds an overview of the filter set and the note that sorting matches the UI, but no syntax or semantics beyond what the schema provides. Baseline 3 applies.

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

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

The description names a specific verb+resource ('Caută firme românești sau identifică o firmă specifică') and states the scope precisely: the same filter set as /cauta-firme. It also differentiates itself from siblings by routing to get_company for the full profile and list_industries for industry IDs, so an agent can tell it apart from find_prospects or screen_companies.

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

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

It gives an explicit when-to-use path ('Pentru a găsi o firmă după denumire, apelează cu name... apoi folosește get_company cu CUI-ul ales') and a when-not-to-use path for full exports (present webOrderUrl instead). It does not, however, distinguish itself from the many overlapping siblings like find_prospects, screen_companies, or get_screening, leaving an agent to infer the boundary.

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 burden and does well: it discloses that matching is diacritic-insensitive and partial, that the dataset is fixed at 42 rows, the exact return fields, and that shortCode is the license-plate code. It does not mention auth requirements or rate limits, but for a pure read-only lookup these are minor 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 usage and boundary prose is tight and front-loaded, but the tool is preceded by a dense keyword-stuffing block of ~30 Romanian and English synonyms that consumes roughly the first third of the text. That block is search-SEO filler rather than instruction the agent needs, diluting structure.

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 small read-only lookup with no annotations, the description covers purpose, triggers, boundaries, and the returned fields (compensating for the absent output schema). Only auth/error behavior is unaddressed, which is a modest gap given the tool's simplicity.

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

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

Schema description coverage is 100%, so the schema already documents id, name, limit, and offset including defaults and the diacritic-insensitive matching. The description largely restates this ('Caută după nume parțial (insensibil la diacritice) sau după ID'), adding little beyond the schema. Baseline 3 applies.

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

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

States a specific verb (caută) and resource (nomenclatorul județelor României, 42 rows in `county`), and specifies the return shape `{id, name, slug, shortCode}`. It explicitly carves out its scope against the sibling `search_companies`, so an agent can distinguish the two 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?

Provides a dedicated 'Când îl folosești' block with concrete trigger questions ('Ce județ are codul CJ?', 'Listează județele care încep cu B'), plus a negative boundary: to filter companies by county, use `search_companies` instead. When, when-not, and the alternative are all explicit.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses anonymous vs authenticated result fields and limits, that full profiles cost 1 credit via get_person, the meaning of each confidence tier, the ONRC data source, and GDPR handling (no CNP returned). It also explains that common-name UNRESOLVED clusters are excluded before returning results. This is rich, transparent operational context.

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

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

The description is long and opens with a keyword list that does little to help an agent select the tool, which weakens front-loading. However, the remaining sections are well-structured with clear headings and dense, useful routing information. Minor verbosity aside, every substantive paragraph 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?

Given 9 optional parameters, no annotations, and no output schema, the description is exceptionally complete: it covers purpose, usage, disambiguation, access tiers, cost, confidence semantics, data source, and GDPR. It also explains what fields are returned in each access mode and directs agents to get_person for full profiles. Nothing critical 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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by stating the default sort order (descending by companyCount), the effect of minConfidence tiers, and how county and birthYearFrom/birthYearTo filters help disambiguate before spending credits. These operational semantics go beyond the schema's parameter definitions.

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: 'Caută o persoană fizică ... și află în câte firme românești apare.' It also differentiates from the sibling get_person by noting that full profiles require get_person and one credit. An agent can immediately tell this is a search tool for natural persons and how it differs 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 when-to-use scenarios with step-by-step guidance, including routing to get_person for full profiles and using county or birth-year filters for disambiguation. It also states that UNRESOLVED clusters are structurally excluded and no parameter can include them. This is comprehensive usage guidance with alternatives and exclusions.

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