Leadgen ONRC Romania

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

With no annotations, the description carries the behavioral burden and does well: it discloses that the call aggregates two sources, that results are labelled with confidence and source, and that a crawl bounded by max_pages occurs. It omits cost/latency implications and any auth or rate-limit notes, which keeps it short of a 5.

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

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

Three tight sentences: output summary first, routing guidance second, parameter semantics third. Every clause carries information and nothing is 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?

For a 3-parameter aggregation tool with no output schema and no annotations, the description supplies the return shape (registry record + sourced, confidence-labelled contacts), the selection rule versus siblings, and all parameter semantics. 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?

Schema description coverage is 0%, so the description must compensate, and it does for all three parameters: cui is identified as the tax code, website is described as overriding the registered one (a semantic not visible in the schema), and max_pages is described as bounding the crawl. Each parameter gains meaning beyond its bare type and default.

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 operation (whole-firm profile in one call) and enumerates exactly what it returns: the ONRC registry record plus contacts from the firm's website, each with confidence and source. It explicitly distinguishes itself from the sibling pair lookup_business + extract_contacts, 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?

It states the exact condition for choosing this tool: use it over lookup_business followed by extract_contacts when you want everything about one company. That is an explicit alternative and trigger, not an implied one.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the key operational trait — the crawl is bounded by max_pages (1-20, default 5) — which tells the agent about cost/latency. However it does not state authentication needs, rate limits, behavior on failure (e.g., no contacts found), or whether the crawl follows subpages/sitemaps.

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, no waste, with the extraction scope front-loaded and the parameter constraint delivered last. Every clause earns its place.

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

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

For a 2-parameter extraction tool with no output schema and no annotations, the description covers purpose, input format flexibility, and the crawl bound — enough to invoke correctly. Gaps remain around auth requirements and failure/empty-result behavior, but the essentials are present.

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 0%, so the description must compensate, and it does: it clarifies that 'website' accepts a bare domain OR a full URL, and that max_pages ranges 1-20 with default 5. These are real semantics not present in the schema. It omits only edge cases like invalid domains.

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 ('Crawl a company website and extract emails, phone numbers and social profiles') that is impossible to confuse with siblings like enrich_company or lookup_domain. The output entities are enumerated, so the agent knows exactly what it gets back.

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

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

Usage is implied by the purpose (use this when you need contact data from a website), but there is no explicit when-to-use/when-not guidance and no differentiation from siblings such as lookup_domain or lookup_business that might also yield company contact info. No alternatives are named.

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. It discloses the official ONRC source, registry size, diacritic-insensitive matching, all-digit-CUI behavior, and that max_results caps returned rows. It does not cover permissions, rate limits, or return structure, but adds substantial context for a read-only lookup.

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

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

Four tight sentences, front-loaded with purpose and search semantics. The usage note and max_results note each add value without padding.

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 no output schema and no annotations, the description is nearly complete for calling the tool: it covers registry, query format, and row cap. It stops short of describing returned fields or access requirements, leaving 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 0%, so the description must document parameters. It explains that query accepts either a company name or CUI, gives actionable diacritic/ASCII guidance, notes all-digit queries match CUI, and clarifies that max_results caps rows returned.

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 in the official ONRC registry. It also positions itself as the natural first call, which helps separate it from enrichment, category, director, and domain siblings.

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 clear context with 'The natural first call for a Romanian company question,' so the agent knows when this tool is appropriate. However, it does not name alternatives such as enrich_company or lookup_by_category, nor does it state when-not to use it.

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 does disclose the non-obvious transformation (curated topic to CAEN codes). But it omits operational traits: it does not state the default result count, how results are ordered or paginated, or what happens with an unrecognized topic.

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

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

Two sentences, front-loaded with the core purpose and followed by the optional-narrowing detail. The parenthetical topic examples are a bit list-heavy but earn their place by defining valid input. No wasted framing.

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 three-parameter, no-annotation, no-output-schema tool, the definition covers purpose, mechanism, and two of the parameters adequately. Since no output schema exists, return values need not be described, though the silent max_results default leaves 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 0%, so the description must compensate. It adds real meaning for 'topic' (a curated term with five examples) and 'county' (single-county narrowing), but 'max_results' is never mentioned, leaving one of three parameters entirely undocumented.

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 companies') and immediately differentiates from the sibling lookup_business by framing it as 'by what they do rather than by name.' It also explains the underlying mechanism (topic expands to CAEN activity codes), so an agent understands both what the tool returns and how it works.

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 'rather than by name' phrasing gives clear comparative context against the name-based lookups, and 'Optionally narrow the result to a single county' clarifies the county parameter's role. However, there is no explicit when-not-to-use guidance and no statement of which topics are valid beyond the five examples, leaving the boundary of acceptable input 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?

No annotations are provided, so the description carries the burden. It does disclose real behavior: the ONRC representatives source table and diacritic-insensitive matching ('popescu' matches 'POPESCU'). However it never states that the operation is read-only, whether results are paginated, or how permissions/quota apply.

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 zero padding; the core purpose and source lead, then matching behavior, then the routing hint. Every sentence carries distinct 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?

For a read-only lookup with no output schema, the description should hint at what comes back, but it never says whether results are company records, director entries, or match counts. The purpose and matching semantics are complete enough to call it, but the return shape is left entirely to inference.

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 0%, so the description should compensate, but it only implies that 'name' is a person's name and says nothing about 'max_results'. The max_results default of 10 is at least captured structurally in the schema, and the name parameter is inferable from the stated purpose, so this is adequate rather than rich.

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 Romanian companies by the name of a director') plus the data source (the ONRC representatives table), which is more precise than a generic search. The closing clause 'when you know a person rather than a firm' cleanly separates it from sibling firm-oriented tools like lookup_business.

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 states the condition for use: 'when you know a person rather than a firm', which implies the alternative (a company-name lookup) exists. It never names the sibling to switch to, and gives no exclusion cases (e.g. partial names, multiple directors), 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?

With no annotations, the description carries the full disclosure burden. It does reveal what is fetched (WHOIS, several DNS record types, an SPF/DMARC audit), which is useful behavioral context, but says nothing about read-only safety, rate limits, latency, caching, or how a nonexistent or malformed domain is handled.

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

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

Three sentences, zero filler: what it returns, when to use it, then the parameter toggles. The information is front-loaded with the payload contents before the usage advice.

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 three-parameter lookup with no output schema and no annotations, the description covers the essentials an agent needs to decide and invoke: contents, purpose, and toggle semantics. It would be fully complete with a note on failure behavior for unresolvable domains or the response's structure, but nothing critical is missing.

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

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

Schema description coverage is 0%, so the description has to compensate, and it does: it explains that include_dns and include_security 'toggle the two halves' of the output, mapping each boolean to a distinct result section. The remaining 'domain' parameter is self-evident from its name, though defaults (true/true) are not restated in prose.

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 operation (WHOIS + DNS + SPF/DMARC audit) against a specific resource (a domain), and even enumerates the record types returned (A, MX, NS, TXT). It is immediately distinguishable from siblings like lookup_company, lookup_financials, or extract_contacts, which operate on other entity types.

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 two concrete use cases — profiling a company's web estate and checking email posture — which tell the agent when this tool is the right pick among the company-oriented siblings. It stops short of naming an explicit alternative or stating when not to use it, so it does not reach the top of the scale.

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 burden. It does disclose that the output is pre-computed derived intelligence summarized into a single verdict with an enumerated vocabulary ('growing', 'stable', 'distressed'), which is real behavioral context beyond the schema. It stops short of stating read-only/non-mutating behavior, freshness of the underlying data, or rate limits.

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, zero filler. The content of the tool is front-loaded in the first sentence and the disambiguation follows immediately.

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 correctly enumerates the returned metrics and the verdict vocabulary. The remaining gap is the undocumented cui input, a single missing detail in an otherwise complete definition.

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 0% and the description never mentions the single required parameter. 'A Romanian company' is the only hint that cui is a Romanian company identifier; format, validity, or what happens on an unknown CUI is unspecified, so the description does not compensate for the coverage gap.

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 and enumerates exactly what is derived: YoY revenue trend, headcount trajectory, net margin, liquidity/distress signals. It explicitly names the sibling it differs from ('use lookup_financials for the raw figures'), 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?

Explicit when-to-use routing: 'Use it for interpretation; use lookup_financials for the raw figures.' The alternative and the condition that selects it are both named, 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?

With no annotations, the description carries the full burden and does disclose materially useful traits: source (Ministry of Finance filings), currency (RON), and time scope (latest fiscal year on record only, not historical). It does not state auth requirements, rate limits, or behavior when no filings exist for a CUI.

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, zero filler, and the returned-data scope is front-loaded before the prerequisite caveat. Every clause 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?

No output schema or annotations exist, so the description is what defines the response (fields, currency, single fiscal year) — which it does adequately. The remaining gap is edge-case behavior (no filings found, invalid CUI) for a lone-parameter lookup.

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 0% for the single required 'cui' parameter, so the description must compensate; it only implies the parameter identifies a company and that a name is insufficient. It adds no format, validation, or example for the CUI value itself.

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

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

Names a specific verb and resource (annual financial statements for a Romanian company) and enumerates the returned content (revenue, profit, headcount, balance-sheet lines, in RON, latest fiscal year). An agent can separate it from lookup_financial_ratios (ratios) and lookup_business (firm resolution) 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?

Gives explicit routing: 'Resolve the firm with lookup_business first if you only have a name.' That is a clear prerequisite and names the alternative. It stops short of stating when-not to use it (e.g. vs lookup_financial_ratios) or what to do when filings are absent.

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 burden and does well: it discloses that the operation drains/consumes the accumulated changeset for all watches under the API key, and specifies the differing return shapes per watch type (company 'updated' entry with changed fields vs. CAEN/county 'new' firms). It does not state whether drained data is permanently lost or repeated polling behavior.

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

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

Two tightly written sentences, front-loaded with the core action and scope, then the per-watch-type result shape. No filler.

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

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

Given no output schema and no annotations, the description supplies exactly what an agent needs: what the call returns and how it differs by watch type, plus the fact that it aggregates across all watches for the key. Nothing essential 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 (schema coverage 100%), so there is nothing for the description to clarify; the baseline for a no-parameter tool is 4.

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

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

States a specific verb and resource ('collect everything the watch tools have found', 'drain the changeset for every watch') and clearly distinguishes itself from the watch_* siblings that create watches rather than read their results.

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 says 'call it to drain the changeset', which implies usage after watches exist, but it never states explicitly when to poll versus when to inspect a watch directly, nor any prerequisite (e.g., that watches must already be registered). Usage is implied rather than 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?

With no annotations to lean on, the description carries the behavioral burden well: it discloses the registration-date cutoff baseline, that only firms registered after the cutoff are reported, and that poll_watchlist advances the cutoff so each firm surfaces exactly once. It still omits auth/permission needs and how often the watch is evaluated.

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 with no filler, front-loaded on what is watched before explaining the cutoff mechanism. The second sentence is dense but every clause carries information about the polling contract.

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

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

For a 2-parameter tool with no output schema and no annotations, the description explains the watch/cutoff contract but omits what an invocation actually returns or registers and how results are surfaced. It is adequate to start but leaves the operational picture (state, frequency, retrieval) partly inferred.

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 0%, so the description must compensate, and it does give shape to both parameters: 'code' is a CAEN activity code and 'county' is an optional scope. It adds no format guidance for the code (e.g., CAEN notation) and mentions a registration-date cutoff that is not actually a parameter, which could mislead about what can be passed in.

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 ... for newly registered firms') plus an optional scope ('optionally scoped to one county'), so the agent immediately knows it is a registration-monitoring tool keyed on an activity code rather than a lookup. It does not explicitly contrast itself with the similarly named watch_company sibling, leaving that differentiation implicit.

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 references poll_watchlist in explaining that the cutoff slides forward, which implicitly tells the agent that poll_watchlist is the retrieval counterpart. However, it never states when this tool should be chosen over watch_company or the lookup_* siblings, nor what prerequisites exist before registering a watch.

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 meaningful work: it discloses that a fingerprint of the current registry record is persisted as a baseline and that change detection is driven by monthly ONRC snapshots, naming the kinds of changes (director, CAEN activity, address, status). It omits whether repeat calls overwrite the baseline, how to unwatch, or any permission requirements.

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, zero filler, and the core action is front-loaded before the downstream behavior. Every clause earns its place.

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

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

For a single-parameter tool with no output schema, the description adequately covers the side effect, the storage mechanism, the refresh cadence, and the consuming tool. Only the absence of lifecycle details (re-registration, cancellation) keeps it from full completeness.

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?

One parameter at 0% schema description coverage, so the description must compensate. It clarifies that the CUI identifies the company to register, which is the essential semantic, but adds no format, validation, or example detail beyond that.

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 ('Register a company ... to monitor') with the keying identifier (CUI), and contrasts itself with the sibling poll_watchlist. An agent can distinguish it from watch_caen and poll_watchlist 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?

Explains the workflow position: register here, then poll_watchlist reports changes between monthly snapshots. It gives clear context for when this tool is used, but does not explicitly state when-not to use it or how it differs from watch_caen beyond the one-off registration framing.

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