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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description goes further by disclosing cache-vs-live behavior ('refresh=true crawls now instead of answering from the cache') and that outputs carry confidence and source labels. It stops short of covering crawl cost, latency, or failure/partial-result behavior, 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?

Front-loads the value proposition and the sibling routing rule, then compresses all four parameters into one dense clause each. No sentence is redundant or padded.

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

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

An output schema exists, so return values need not be explained; the description still notes the confidence/source annotation on discovered contacts. With schema and annotations covering the rest, an agent has everything needed to call this 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 all four parameters are already documented with types, defaults and constraints (1-20 pages, RO-prefix acceptance). The description restates 'cui is its tax code', the website override, the crawl bound and refresh semantics without adding syntax or examples beyond the schema.

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

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

States a specific composite verb/resource ('whole-firm profile in one call: the ONRC registry record plus the contacts discovered on that firm's website') and explicitly names the two siblings it replaces. An agent can distinguish it from lookup_business and extract_contacts 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?

Gives an explicit when-to-use rule and names the alternatives: 'Prefer this over lookup_business followed by extract_contacts when you want everything about one company.' Both the condition and the competing tools are stated, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds that this is a bounded crawl (max_pages controls scope), which usefully implies runtime/cost characteristics, but says nothing about latency, rate limits, or whether results are cached.

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

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

Two tight sentences with the capability front-loaded and the input constraints trailing. The second sentence is largely a paraphrase of the schema, which is the only minor redundancy.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description is nearly complete for this tool; only crawl-dynamics details (scope of crawling, subdomain behavior, expected duration) are absent.

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

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

Schema description coverage is 100% and both parameters already document the domain/URL format and the 1-20 default-5 range. The description simply restates that same information, adding no syntax, format, or edge-case guidance beyond the schema, so the baseline of 3 applies.

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

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

The description states a concrete verb+resource ('Crawl a company website') plus the extracted artifacts (emails, phone numbers, social profiles), so an agent knows exactly what it produces. It is clearly distinct from the lookup_* siblings in mechanism, but it never clarifies its relationship to overlapping tools like enrich_company, which could also surface contact 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?

Usage is only implied: the agent can infer 'use this when you need contact details from a live site.' There is no explicit when-to-use trigger, no when-not, and no routing to or from alternatives such as enrich_company or lookup_domain.

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?

Goes well beyond the annotations: it discloses the two lookup paths (registry website field vs. reading home/legal/contact pages), the matchedOn values, that name candidates are capped at 0.7 confidence and are 'never a match', and that it is a single lookup. This is exactly the behavioral detail annotations cannot convey.

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?

Dense and front-loaded with the core purpose first, then method, then fallback behavior. The middle sentence is packed but not redundant; a slightly shorter phrasing would improve scannability.

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

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

With an output schema present and annotations covering the safety profile, the description supplies everything remaining an agent needs: input shape, resolution strategy, confidence semantics, and the fact that a non-match is reported rather than fabricated.

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 domain, fields, and compact parameters are already fully documented in the schema. The description adds no parameter syntax or format detail of its own, so the baseline 3 applies.

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

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

States a specific verb and resource ('Find the Romanian firm behind a website domain') with a concrete example (dedeman.ro) and names the matching method used. It is clearly distinguishable in substance from lookup/enrich siblings, though it never names an alternative tool to contrast against.

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

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

Usage context is implied (you have a domain, you want the company) and the fallback chain tells the agent what will happen, but there is no explicit 'use this when X, use lookup_domain/lookup_business when Y' guidance despite many closely named siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds real behavioral context beyond them: it is free, never counted against the quota, reports both anonymous (5/day) and keyed (25/day) ceilings, and points to the key signup. Auth requirements and rate limits are disclosed, which is exactly what the annotations cannot convey.

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

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

Two sentences, output contents front-loaded before the quota/auth caveats, with no filler. The trailing signup URL and parenthetical are slightly dense but genuinely actionable, so the trade-off is acceptable.

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

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

An output schema exists, so return-value detail is optional; the description going further and enumerating the fields is a bonus. Auth needs, quota tiers, reset timing, and cost are all covered, leaving no gap an agent would need to guess at for this parameterless read tool.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing further for the description to disambiguate. The statement that it costs no lookup is a useful semantic note about invocation but is not a parameter concern.

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

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

Specific verb+resource ('Show your own allowance') followed by an enumerated list of what is returned: plan, daily limit, lookups used today, remaining, reset time, credit balance. It is unmistakably distinct from the lookup/enrich siblings, which all consume allowance rather than report it.

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

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

Gives clear context for when to call it (checking your allowance) and states the free/unmetered condition plus the anonymous-vs-key limits that shape usage. It does not explicitly name an alternative tool or a 'do not use when' case, but the sibling set contains no near-equivalent, so routing risk is low.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-derivable behavior: diacritic-insensitive matching, CUI exact-match semantics, live-before-closed ranking with county lift, and the empty-result hint. It stops short of stating result limits or pagination, but that is minor against the annotation coverage.

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

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

Front-loaded with the core purpose, then ranking rules, then the sibling redirect. Dense but every clause carries information; the parenthetical examples are compact. Slightly packed with semicolon-separated ranking detail, but nothing is wasted.

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

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

With an output schema present, return values need no explanation, and the description covers matching rules, ranking order and the alternative path. A complex, highly-ranked lookup tool is adequately described; only the max_results/truncation boundary behavior is left implicit.

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

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

Schema description coverage is 100% and the parameter descriptions already cover diacritic-insensitivity, the county-as-hint-not-filter nuance, fields/compact behavior and the 1-100 bounds. The description largely restates the query semantics, so baseline 3 is correct – it adds little the schema does not already say.

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 ('Look up a Romanian company by name or CUI') and pins the data source ('official ONRC registry of 4.2M firms'). It also positions itself among siblings with 'The first call for a named Romanian company', so an agent can separate it from lookup_companies, lookup_by_category and match_companies without opening a 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?

Explicitly routes the disambiguating case: 'For firms that do X in Y, use lookup_by_category', and even explains the redirect an empty result may carry. Combined with the 'first call for a named Romanian company' framing, both when-to-use and when-to-use-something-else are stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds real behavioral context beyond that: the default active_only filter meaningfully changes result sets by dropping struck-off, dissolving, insolvent, suspended and ANAF-inactive firms, and it discloses that codes match ANY authorised activity unless main_activity_only narrows it. Return shape is left to the output schema, which is fine.

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

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

Front-loaded with the core differentiator ('not by name') before the accepted input formats and filters; dense but every clause carries information. Minor waste and ambiguity in fragments like 'see matched' and the parenthetical CAEN examples.

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 15-parameter tool with a full output schema, the description covers the essential decision points: what 'topic' accepts, the scoping/qualifying filters, and the default filtering behavior. It is slightly thin on how this tool relates to its closest siblings, but nothing needed 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 description coverage is 100%, so the schema already documents all 15 parameters, and the baseline is 3. The description mostly restates the filter categories rather than extending them, though the cross-revision note ('6201 also finds Rev.3 6210') and the 'a CAEN class title; see matched' hint add a little semantics the schema states only for the topic param.

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?

A concrete verb+resource ('Find companies by what they do') with an explicit negative qualifier ('not by name') that separates it from name/domain lookups. However, it never names the close siblings (lookup_companies, match_companies) that an agent must choose between, so differentiation is by implication rather than by reference.

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

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

Usage context is implied through the accepted topic formats and the filter list ('narrow by county; qualify by revenue, headcount, VAT, main activity'), which tells the agent when the tool fits. But there are no explicit when-not conditions, prerequisites, or named alternatives among the many lookup_* siblings, and the fragment 'a CAEN class title; see matched' is puzzling rather than instructive.

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

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

Annotations already cover readOnly/idempotent/non-destructive, so the description's added value is the quota accounting ('each row counts as one lookup'), the atomic whole-batch refusal, the per-row found flag, and the input-order guarantee — real operational context beyond the schema. It doesn't say whether refused batches surface as an error vs a partial result.

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?

Dense but front-loaded: batch scope, per-row semantics, quota rule, and trimming flags in order of importance, with no filler sentences.

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

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

An output schema exists so return shapes need no explanation, and the description covers ordering, the found flag, and quota failure. The one gap is what happens on invalid or unknown CUIs within the batch, and how the whole-batch refusal is reported.

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 cuis, fields, and compact are already fully documented, including accepted CUI formats and dotted paths. The description only echoes that fields/compact trim each record, adding no syntax 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 (look up), resource (Romanian companies by CUI), and batch scope (up to 100, one result per input) that clearly separates it from the singular lookup_business sibling it references.

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 'many ... in one call' framing and the pointer to lookup_business for CUI formatting imply the batch-vs-single choice, and the quota/refusal rule tells the agent when a call will fail. It stops short of explicitly naming when to prefer this over match_companies or other siblings.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description usefully adds matching semantics (diacritic-insensitive, whole-word, prefix option) plus the key ambiguity that one name can map to several people due to no personal ID. It does not mention pagination or result-count behavior beyond the schema's max_results.

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

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

Front-loaded with the core purpose and matching rules, and nearly every sentence carries distinct information. The dangling reference to 'byCounty' as a signal for homonyms is slightly confusing since no such parameter appears in the schema, costing a point.

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

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

With an output schema present, return-value details are rightly omitted, and the description covers the tricky parts an agent needs: matching semantics, diacritics, prefix behavior, and the one-name-to-many-people caveat. 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 description coverage is 100%, so the schema already carries parameter meaning and the baseline would be 3. The description earns a point by reinforcing matching behavior with a concrete example ('pop maria' finds POP MARIA, not POPA MARIANA) and explaining the homonym ambiguity that no schema field conveys.

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 with its scope: 'Find Romanian companies by the name of a director or legal representative (ONRC).' This clearly separates it from sibling firm-oriented tools such as find_company_by_domain, lookup_companies, and match_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?

'Use this when you know a person rather than a firm' gives a clear selection condition and implicitly excludes firm/domain-based siblings. It does not name a specific alternative tool to switch to, so it stops short of full when/when-not routing.

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

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

Annotations already declare this a read-only, idempotent, open-world, non-destructive operation, so the safety profile is covered. The description adds that the lookup is split into DNS and email-security halves, but discloses nothing about rate limits, failures on non-existent domains, or external source variability that an agent would find useful.

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

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

Three tight sentences with the payload list front-loaded and the toggles noted last. Nothing is padded, though the final toggle sentence is largely redundant with the schema.

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

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

An output schema exists, so return values need no explanation here, and the description covers scope, toggles, and intended use. A note on behavior for non-existent or malformed domains would complete it, but it is otherwise sufficient for correct invocation.

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

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

Schema coverage is 100%, so all three parameters are fully documented in the schema, including defaults and the URL-to-host normalization. The description's note that include_dns/include_security toggle the two halves restates what the schema already conveys, so the baseline 3 applies.

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

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

States a specific verb (lookup) and resource (domain) and enumerates the concrete payloads: WHOIS, DNS records, and an SPF/DMARC email audit. This distinguishes it from the sibling company-lookup tools, which fetch entity data rather than domain infrastructure.

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

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

"Use it to profile a company's web estate or check its email posture" gives clear context for when to reach for this tool. It stops short of naming an alternative or exclusion (e.g., when to prefer find_company_by_domain or enrich_company instead), so it is not a full when/when-not statement.

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

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

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, so safety is covered. The description adds real behavioral value beyond that: the discrete verdict enum ('growing'/'stable'/'distressed'), the presence of a rule-by-rule health-score breakdown, red flags and peer-percentile benchmarking. It omits any note on data freshness or what happens for companies with sparse filings.

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

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

Front-loaded: the payload of the tool is stated first, with the sibling routing instruction last. The opening sentence is a long comma-separated enumeration, but each item is a distinct returned artifact rather than filler, so it stays efficient.

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

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

An output schema exists so return values need not be restated, yet the description still gives the agent the semantic shape (verdict enum, health-score breakdown, peer grouping by CAEN and county) plus scope and the alternative tool. Nothing needed to select or call this 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?

Only one parameter and schema coverage is 100%, with the schema itself documenting the CUI format and the 'RO'/leading-zero tolerance. The description adds no further meaning about the identifier, so the baseline 3 for schema-covered params 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 precise verb+resource and enumerates exactly what 'derived financial intelligence' means: YoY/3-5-10y CAGR, margins, headcount, solvency/liquidity ratios, a 0-100 health score, red flags, peer percentiles. It explicitly distinguishes itself from the sibling lookup_financials ('raw figures'), so an agent can separate 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?

Names the alternative (lookup_financials) and the condition that selects it ('for the raw figures'), and scopes the tool to Romanian companies via the CUI input. It does not state prerequisites, failure modes (e.g. company with no filed statements), or exclusions beyond that one routing sentence, so it stops short of a full when/when-not map.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds genuine value beyond that: the data source (Ministry of Finance filings), historical depth (every fiscal year since 2008), currency (RON), and the name-resolution prerequisite. Rate limits, auth, and coverage gaps (e.g. missing years, firms never filing) are unmentioned.

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 payload is front-loaded into one dense sentence and the routing rule is a short second sentence, so nothing is buried. The enumerated field list is long but each item is informative rather than filler.

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

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

With an output schema present, the return format need not be explained, and annotations cover the safety profile; the description still supplies source, currency, and historical coverage. The remaining gap is the unresolved overlap with lookup_financial_ratios, which an agent facing both tools would need to disambiguate.

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

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

There is a single parameter and the schema description coverage is 100%, with the schema itself documenting the CUI format, examples, and acceptance of 'RO' and leading zeros. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb+resource with unusually concrete scope: annual statements for a Romanian company sourced from Ministry of Finance filings, every fiscal year since 2008, including named line items in RON. It stops short of drawing the boundary against the sibling lookup_financial_ratios, whose territory (ratios) this description also claims, so an agent must guess which to call for ratio-only needs.

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

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

Explicitly gives the prerequisite path: resolve the firm with lookup_business first when only a name is available, which is real routing guidance. It offers no when-to-use versus lookup_financial_ratios or the other lookup_* siblings, so selection among overlapping tools 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?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description adds real operational context: each row consumes one lookup, an over-quota batch is refused atomically, and a valid CUI forces confidence 1.0. It stops short of covering rate limits or partial-failure behavior in detail.

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

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

Three dense sentences, front-loaded with the core action and the 500-row cap. The inline {cui, companyName, confidence, matchedOn} output spec is slightly heavy but each sentence carries information.

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

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

Given a 3-parameter tool with a full schema and an output schema, the description covers the matching rules, quota cost, and all-or-nothing batch refusal. The main gap is sibling routing, which contextual completeness does not fully resolve.

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 rows, fields, and compact fully. The description's field list and CUI rule largely restate schema content, earning the baseline 3 rather than adding 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?

States a specific verb (match) and resource (a list of up to 500 records) against Romanian firms, and makes the batch nature explicit. It is clearly distinguishable from single-record siblings like find_company_by_domain or lookup_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?

The batch use case is implied and the row-quota mechanics are explained, but the description never states when to choose this tool over siblings such as lookup_companies or enrich_company. Usage is inferable rather than guided.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, and the description explains exactly why: 'drain the changeset' discloses that collection consumes/mutates the pending changeset state, and 'since the last poll (200 a poll, the rest next)' discloses the non-idempotent pagination cap. It also describes ordering ('most severe first') and the differing output shapes for company vs CAEN/county watches, which is well beyond what the annotations convey.

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

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

Two sentences, tightly front-loaded with what the tool does and why, followed by the output and pagination details. Every clause earns its place with no filler or repetition of the title.

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

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

An output schema exists so return values need not be explained, yet the description still summarizes the two result shapes ('updated' entries with fields and risk, 'new' firms for CAEN/county) and the 200-per-poll limit. For a zero-parameter polling tool, nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so per the baseline the description carries no parameter burden beyond baseline 4. Schema coverage is 100% (empty object), and there is nothing in the parameter surface for the description to compensate for.

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 ('Collect... drain the changeset') and resource ('every watch owned by your API key'), and it explicitly frames itself against the sibling watch tools that create the watches. An agent can distinguish this from watch_company/watch_caen/unwatch 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?

It clearly establishes the context of use: call this to drain what the watch tools have found for your API key. It implies the setup/consume relationship with the watch_* siblings, but it never states when not to call it or names an explicit alternative (e.g., unwatch to stop collection).

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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by disclosing cost (free, not counted as a lookup), notification behavior ('nothing is mailed to it automatically'), and downstream latency/workflow ('Registry records are corrected at the source (ONRC) and arrive with the next snapshot'). These are exactly the side-effect and expectation-setting details an agent cannot infer from structured fields.

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

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

Front-loads the core action, then compresses the kind taxonomy, the cost guarantee, the contact caveat and the correction cadence into minimal prose. Every clause earns its place with no redundancy.

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

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

An output schema exists, so return values need no explanation. For a free-text report submission tool the description covers what to send, how to classify it, what it costs and what happens afterward, leaving no material gap for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents cui, kind, contact and message. The description restates the kind taxonomy and cui usage and adds only the 'nothing is mailed automatically' clause, which is behavioral rather than semantic. Baseline 3 is appropriate when the schema carries the parameter burden.

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 ('Tell the Leadgen founder what is missing or wrong') and immediately enumerates the report categories, making it unmistakable against the sibling lookup/enrichment tools. An agent can tell this is a feedback channel, not a data-retrieval call, without opening the 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?

Gives clear per-case routing: 'gap' for missing field/firm/source, 'wrong_record' plus its cui for a bad company record, plus bug and idea. It also supplies the incentive condition ('Free, never counted as a lookup'), which steers an agent away from treating it as a billable lookup. No explicit when-not-to-use or named alternative, so it falls 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?

The description contradicts the destructiveHint: false annotation by stating that "the watch and its baseline are removed." Removing state is not an additive update, so the annotation and description are inconsistent. It also adds useful idempotence context ("removed: 0"), but the contradiction forces a 1 under the rules.

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?

It is front-loaded with the core action, packs relevant scope and behavior into three short sentences, and none of the text is wasted.

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

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

Given an output schema exists, the description need not explain return values. It covers the key inputs, removal semantics, idempotence, API key scope, and the related poll_watchlist alternative, so an agent has enough context to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds only a light mapping (cui=company, code=CAEN activity code, county conditional), which does not go meaningfully 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 states a specific verb ("Stop watching") and resources ("a company (cui) or a CAEN activity code (code, plus the county...)"), and distinguishes itself from the opposite watch_* siblings and from poll_watchlist. An agent can identify the tool's scope without opening the 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?

It gives clear context: stop watching a company or activity, on your API key, with a no-op if not watched, and points to poll_watchlist for active watches. It does not explicitly state when to use this versus watch_company/watch_caen, so it stops 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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower. The description still adds real behavior beyond them: the registration-date baseline cutoff, the dedup guarantee that each firm surfaces once, and the retired Rev.2 → Rev.3 alias with a warning. It doesn't cover watch lifetime or how to remove the watch, hence not a 5.

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

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

Three tight sentences: purpose first, then the cutoff/polling mechanics, then the edge case alias. No filler and the most important information 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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description covers scope, cutoff semantics, dedup, and the alias edge case; only watch lifecycle/auth requirements are unaddressed, which is a minor 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% — both 'code' and 'county' are documented, including diacritic-insensitivity and nationwide default. The description's note about retired Rev.2 codes restates what the schema already says, adding no new parameter semantics, so the baseline 3 applies.

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

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

States a specific verb and resource ('Watch a CAEN activity code') plus the scope ('for newly registered firms'), which cleanly separates it from watch_company (single firm) and unwatch. An agent can identify what is being created without opening the schema.

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

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

The description explains the workflow relationship to poll_watchlist ('slides the cutoff forward so each new firm surfaces once'), which tells the agent when this tool's output will be consumed. It stops short of an explicit when-not/exclusion rule against the sibling watch tools, so it lands at clear context without routing guidance.

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

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

Adds substantial behavior beyond the annotations: it stores a fingerprint of the current registry record as a baseline, changes are computed between monthly ONRC snapshots, and it enumerates the change classes detected (director, CAEN activity, address, status, ANAF fiscal-inactivity, VAT flip). It also reinforces idempotency ('watching a firm you already watch changes nothing'), consistent with idempotentHint=true.

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

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

A single dense sentence, front-loaded with the action, then the baseline mechanism, then the reported outcomes and cadence. No filler sentences and nothing repeated from the schema.

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

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

With one required parameter, full schema coverage, an output schema, and annotations covering the safety profile, the description supplies everything else an agent needs: what registration stores, when results appear (monthly snapshots), and via which sibling.

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

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

Schema description coverage is 100% and the schema already defines CUI with an example plus the idempotency note. The description only restates 'by CUI', adding no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

States a concrete verb+resource ('Register a company ... to monitor') and immediately names the downstream consumer (poll_watchlist), which separates it from siblings like watch_caen and unwatch. An agent can pick it without opening the 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?

Explains the workflow context clearly: register here, then poll_watchlist reports changes. It does not state exclusions or explicitly contrast with watch_caen (CAEN-specific watching) or unwatch, so it stops short of full 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.