DateBPI

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

Annotations declare readOnlyHint=true, so the safety profile is already covered and the bar is lower. The description adds that the payload is historical/decision data rather than a plan-role listing, which is useful, but says nothing about empty results, pagination, or authentication.

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 field enumeration is front-loaded and efficient, but the trailing clause ('Fara functia in plan: doar numaratori') is ambiguous and reads as noise an agent cannot act on. Trimming or clarifying it would tighten the definition.

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 read-only lookup keyed on a single CUI, the description usefully enumerates what comes back (date, time, agenda, practitioner, decisions), compensating for the absent output schema. It is largely complete, missing only edge-case behavior such as no-meeting 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?

Schema description coverage is 100% and there is a single parameter (cui) already documented as 'CUI-ul firmei'. The description adds no format, validation, or lookup semantics beyond what the schema provides, so the baseline 3 applies.

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

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

The description names the resource (creditors' meetings and committees for a company) and enumerates the data returned (date, time, agenda, practitioner, decisions). However, it never states an action verb and does not differentiate itself from close siblings such as tabel_creditori or termen_declaratie_creanta, so an agent must infer the distinction.

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

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

There is no guidance on when to use this tool versus the many related insolvency siblings (tabel_creditori, termen_declaratie_creanta, profil_firma). The closing clause is a scoping caveat about what is excluded, but it is cryptic and does not name an alternative tool.

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

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

The idempotentHint annotation already covers idempotency, but the description adds real behavioral context beyond it: the firm stays in Radar with its history and nothing is deleted. It does not discuss auth or rate limits, but for this operation the state guarantee is the meaningful 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?

Three tight clauses, front-loaded with the effect, followed by the non-deletion guarantee and the alternative. Every clause carries information; the trailing 'Idempotent' merely restates the annotation.

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 and annotations covering idempotency, the description states what changes and what is preserved, which is enough to call it correctly. Only marginal gaps remain (e.g., error behavior for unknown CUI).

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 string parameter (cui) at 100% schema coverage, so the schema already documents it fully. The description adds no format or syntax detail for cui, so baseline 3 is appropriate.

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

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

Specific verb (opreste) plus resource (alerte) plus scope (pentru o firma din Radar). It explicitly distinguishes itself from the sibling radar_elimina by stating it does not delete anything, so an agent can tell the two apart without opening schemas.

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

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

States the effect (stop alerts, keep the company) and names the alternative for a different need: 'pentru stergere exista radar_elimina'. The routing condition is explicit and leaves 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?

Beyond the idempotentHint annotation, the description discloses real side effects: reactivating an existing alert and silently adding the company to Radar if it is not present. That auto-add behavior is important context an agent would not get from the schema or annotations alone. The word 'Idempotent' merely repeats the annotation, but the rest genuinely adds value.

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 short sentences with the primary action front-loaded and side effects following. Efficient overall, with only minor redundancy in the trailing 'Idempotent.' restating the annotation.

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 full schema coverage and an idempotency annotation, the description covers what the tool does and the key side effect. Nothing an agent needs to call it correctly appears to be 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% (the single cui parameter is documented as 'CUI-ul firmei'), so the structured field already carries the semantics. The description adds nothing about the cui format or validation, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: start alerts for a company in Radar, with the additional behavior that it reactivates an existing entry or adds the company if absent. It is clearly separable from the sibling alerte_opreste, though it stops short of explicitly naming that counterpart.

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 statement that the tool works on a company in Radar and reactivates it, but there is no explicit when-to-use or when-not-to-use guidance. It never routes the agent to the obvious alternative alerte_opreste for stopping alerts, nor clarifies how it relates to radar_adauga.

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 readOnlyHint already declaring the safety profile, the description still adds real behavioural context: the default 7-day window, the 90-day ceiling, the 50-result cap, and newest-first ordering. These constraints materially affect how an agent calls and interprets the tool, though pagination/truncation behaviour at the 50 cap is not spelled out.

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 tight sentence that leads with the resource and window, then the optional filter, the returned fields, and the ordering/limit. Nothing is padded and the most important constraint comes 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?

There is no output schema, so the description correctly compensates by listing the returned fields, and it covers defaults, caps, and sort order. It is essentially complete for a simple read tool; only behaviour at the result cap and the meaning of the CUI filter for non-matching firms is left open.

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 the 1-90 range and default 7 for 'zile' and reiterates the CUI filter, adding no format, matching, or semantic detail beyond what the schema properties 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+resource: alerts received from Radar within a bounded time window, and enumerates the returned fields (type, title, summary, date, company, publication). It is unambiguous on its own, but it never names or contrasts the near neighbours (alerte_surse, radar_lista, alerte_opreste/alerte_porneste), so the agent must infer the boundary from the name alone.

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 description tells you the tool works for a CUI-filtered or unfiltered recent window, which hints at when it fits, but there is no explicit when-to-use/when-not statement and no routing to a sibling for a different view of alerts.

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 only annotation is idempotentHint=true. The description adds important behavior beyond that: it defines the input as a 'complete desired list' implying replacement semantics, and explicitly states that an empty list is rejected. It does not mention permissions or rate limits, but none are expected for this operation.

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. The core action and scope are front-loaded, followed by the value enumeration and the validation/alternative rule. No redundant or filler content.

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 mutation tool with no output schema, the description provides everything needed: what it does, the exact allowed values, the replacement semantics, and the rejection rule with an alternative tool. Nothing material is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by enumerating all valid source values for 'surse' and clarifying that the list is complete rather than incremental, which meaningfully supplements the schema's generic 'comma-separated desired sources'.

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 ('Seteaza') and resource ('sursele urmarite'), scopes it to a firm in Radar, and enumerates the exact allowed values. It also differentiates from the sibling tool alerte_opreste by explaining that empty lists should be routed there.

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 describes when to use the tool (to set the complete desired list of tracked sources), specifies a when-not condition (empty list is rejected), and names the alternative tool for that case ('alerte_opreste').

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, so safety is covered. The description usefully discloses that results span two sources (BPI-published and registry-only firms), but omits pagination behavior, result ordering, or what happens when no match is found.

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 short sentences, front-loaded with the action and search keys, followed by return contents and routing advice. No filler, though the return-field list is somewhat dense.

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

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

With no output schema, the description compensates by listing the returned fields, and for a simple two-parameter read tool that is largely sufficient. Minor gaps remain around result limits/ordering, but nothing essential to invoking it 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 both 'q' and 'limita' are already documented in the schema. The description restates the q semantics ('denumire sau CUI') but adds nothing about limita or input format beyond what the schema provides — baseline 3.

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

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

Uses a specific verb and resource ('Cauta o firma dupa denumire sau CUI') and enumerates exactly what is returned (CUI, judet, stare, numar de publicatii). It also distinguishes its scope from registry-only siblings by noting both BPI-published and registry-only companies are covered.

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 trigger (search by name or CUI) and routes the agent onward: 'Foloseste CUI-ul returnat in celelalte unelte.' It does not name a specific alternative tool or a when-not condition, but the usage context is clear.

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

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

readOnlyHint=true already tells the agent this is a safe read, and the description usefully adds the enumerated status values, the 'persons appear by name only' limitation, and a further restriction. However the closing phrase ('Fara functia in plan: doar numaratori') is opaque and could mean several things, so the added behavioral value is real but partly unreadable.

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 short sentences with the resource definition front-loaded, which is good. But the final sentence is cryptic and doesn't clearly earn its place, and the enumeration of statuses could be tighter.

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

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

With no output schema, the description carries the burden of describing what comes back, and it does partially cover that (statuses, names only). But the ambiguous 'doar numaratori' clause and the absence of any indication of result size, hierarchy between administrators/associates, or response shape leave real gaps for a single-parameter 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?

There is only one parameter and schema description coverage is 100% ('CUI-ul firmei'), so the schema already carries the semantics. The body adds no format, validation, or expected-value detail for the CUI, so baseline 3 applies.

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

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

The description names a specific resource — the other companies belonging to a firm's administrators and associates — plus the status dimension it returns (active, insolvent, bankrupt, dissolved). That is enough to distinguish it from profil_firma or cauta_firma, though it never names a sibling as an alternative the way a 5 would.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling is named. The agent must infer from the resource description alone that this is the cross-ownership lookup rather than the firm-detail lookup.

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, so the safe-read profile is established structurally. The description adds value by disclosing what is excluded (no offers, no adjudication detail) and the 'doar numaratori' limitation, but it does not explain permission requirements or result volume/paging.

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 compact sentences that front-load the resource and the returned fields, with exclusions placed after. The final clause ('Fara functia in plan: doar numaratori') is opaque enough to waste some of the available space.

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 only one parameter, no output schema, and annotations covering safety, the field enumeration effectively substitutes for a return-value description. What is missing is only the routing information (when this beats the other insolvency-related siblings).

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 (cui) with 100% schema description coverage, so the baseline is 3. The description adds nothing about the CUI format or which firm scope is expected, leaving the schema to carry the parameter entirely.

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 identifies the resource precisely (insolvency-procedure auctions and asset sales for a firm) and enumerates the exposed fields — what is sold, starting price, date/place, liquidator, result. It is clearly a read/list operation for one firm, but it never contrasts itself with siblings like publicatie_bpi or tabel_creditori, which also surface insolvency 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?

There is no explicit when-to-use guidance, no prerequisites, and no pointer to an alternative tool. The trailing clause about 'fara oferte, adjudecat' and 'doar numaratori' hints at scope limits but is cryptic rather than directing the agent to a different tool.

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

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

Annotation already covers read-only safety, but the description adds a genuinely useful behavioral fact: it consumes the subscription's daily company budget, warning the agent of a cost/quota side effect. It stops short of describing return shape or pagination, but the cost disclosure is meaningful context beyond the annotation.

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, but purpose and payload are front-loaded and every clause enumerates a distinct returned section. Slightly heavy but efficient with no redundant filler.

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

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

With no output schema, the description usefully enumerates the sections the profile returns and notes the quota cost. This covers what an agent needs to decide and call it, though it could be richer on the response structure or failure modes.

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

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

Schema description coverage is 100% and the single cui parameter is already fully documented ('doar cifre'). The description adds no format or validation 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 specific verb+resource ('Profilul unei firme dupa CUI') and enumerates exactly what the profile contains (ONRC/ANAF status, arrears, insolvency filing, risk score, early signals, BPI count). This clearly distinguishes it from search-oriented siblings like cauta_firma or the BPI-publication 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?

Keying on CUI implies the caller must already know the company's tax ID, which implicitly routes away from search tools. However, no sibling (e.g. cauta_firma) is named and no explicit when-to-use/when-not guidance is given, so usage is only implied.

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?

Beyond readOnlyHint=true, the description discloses the chunk size (12.000 de caractere), the pagination mechanism (de_la cerand urmatoarea bucata), the entitlement gate (abonament/acces platit), and a quota cost ('Consuma din bugetul zilnic de documente'). These are exactly the behavioral details annotations cannot express.

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 that front-loads the core action before the entitlement and pagination caveats. Efficient, though the parenthetical packing makes it somewhat heavy to parse.

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, but the description explains what is returned (metadata always, full text conditionally) and how to page through it, so an agent has enough to invoke correctly. Return format specifics are only loosely covered.

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, and the description adds meaning: de_la is framed as the way to request the next 12,000-character chunk, and id is tied to publicatii_bpi plus the CUI_numar_an format.

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 ('O publicatie BPI dupa id'), names the source of the id (publicatii_bpi), and specifies the returned content (metadatele plus textul integral). An agent can distinguish it from the listing tool publicatii_bpi 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?

Implies the id comes from publicatii_bpi and states the precondition for full text (abonament activ sau acces platit la firma). It gives clear usage context but does not explicitly name alternatives or say 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: results are ordered newest-first and paginated at 20 per page, plus which fields come back. It stops short of detailing pagination edge behavior or total counts.

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 that front-loads the resource, then the return fields, ordering, filters, and pagination, and closes with the sibling routing. No filler.

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

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

With no output schema, the description compensates by naming the returned fields, the sort order, and the page size, which is enough for correct invocation. Minor gaps remain (no mention of pagination exhaustion or link to the sibling's identifier relationship), but 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?

Schema coverage is 75% and the one undocumented parameter (pagina) gains meaning from the description's 'paginare (20 pe pagina)'. The description also clarifies that 'an' and 'text' act as filters on year and title words, adding substance beyond the schema's brief field notes.

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 ('Lista publicatiilor BPI ale unei firme'), enumerates the returned fields (numar, data, titlu, dosar, instanta), and explicitly distinguishes itself from the sibling publicatie_bpi, which serves the full text. 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?

The description clearly routes the agent: use this tool to list publications, use publicatie_bpi when full text is needed. That is an explicit alternative, though it does not state exclusions or prerequisites (e.g. CUI must exist) beyond that single routing hint.

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 only carry idempotentHint; the description concretely reinforces it ('a second call for the same CUI returns the existing entry') and adds a non-obvious behavior — an ambiguous name is a no-op that returns candidates. This is real value beyond the annotation, though it does not cover auth or full return shape.

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 tightly packed sentences that front-load purpose before the ambiguity rule and the surse default. Dense but every clause carries information; 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?

No output schema, yet the description explains the two meaningful outcomes (candidate list on ambiguity, existing entry on repeat) and the source default. Useful enough for an agent to invoke correctly, with only permission/response-detail gaps remaining.

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%, so baseline is 3, but the description adds meaning not in the schema: CUI is preferred over denumire, the full enumerated set of valid surse values is inlined in the description (the schema itself does not enumerate them), and omit = all sources.

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 (adauga) and resource (o firma in Radar / monitorizare cu alerte), and the two input modes (CUI sau denumire). It is clearly distinguishable from radar_elimina and radar_lista by naming the add-and-monitor semantics.

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 when a name resolves to CUI-based monitoring, what happens when it is ambiguous (nothing added, candidates returned), and that omitting surse means all sources. It stops short of explicitly routing to sibling tools like radar_lista or cauta_firma, but the selection context is otherwise clear.

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

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

Annotations already flag destructiveHint=true, but the description adds substantial context beyond them: that deletion is permanent ('definitiv'), that the alert history is destroyed too, and that omitting confirm produces a non-destructive dry-run listing what would be deleted. The confirm-gated two-step flow is precisely the behavioral detail an agent needs before an irreversible mutation.

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 short sentences, front-loaded with the destructive action, then the confirm semantics, then the alternative. Every sentence 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?

Although there is no output schema, the description explains the return behavior (it returns what would be deleted when confirm is absent), covers the destructive scope, and routes to the alternative tool. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by describing the actual effect of omitting confirm (returns the would-be-deleted set) rather than just the parameter's type. The cui parameter's meaning is carried entirely by the schema, so it is not a full 5.

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: definitively deletes a company from Radar together with its alert history. It also distinguishes itself from the sibling alerte_opreste by naming that tool explicitly for the alert-only case, so an agent can tell the two apart without opening schemas.

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

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

Explicitly names the alternative ('Pentru a opri doar alertele foloseste alerte_opreste') and specifies the condition that governs the correct invocation, namely that confirm=true only after explicit user confirmation, while calling without it is a preview. Both the when and the when-not are present.

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?

readOnlyHint is already declared, and the description adds real context beyond it: the scope covers both the user's and the team's Radar, a hard page cap of 50, and the 30-day window for the alert count. It does not discuss total counts or ordering, but this is solid supplementary 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?

A single dense paragraph with the resource and scope front-loaded, followed by the field list and then the filter and pagination constraints. Every clause carries information; the long field enumeration is the only thing that makes it feel packed, but it is useful given no output 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 no output schema, the description usefully enumerates the returned fields, and the readOnly annotation plus the page cap and filter semantics cover the main calling concerns. Missing only enumeration of what determines ordering or total result size.

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 only 50%: pagina has no schema description, and the description compensates by stating the 50-per-page limit, while the filtru values (activ/inactiv/fragment) are restated and clarified. It adds meaning over the schema for the under-documented parameter, though it does not explain pagina's default or how pages are bounded.

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 resource (firmele din Radarul utilizatorului/echipei) and enumerates the returned fields (CUI, denumire, alert status, surse urmarite, alert count, signal band), so an agent can distinguish it from mutation siblings radar_adauga/radar_elimina and from cauta_firma. It does not explicitly name a sibling to differentiate against, keeping it at 4 rather than 5.

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

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

The description mentions an optional filter and the values it accepts, and implies this is the read/list counterpart to radar_adauga and radar_elimina, but it never states when to use it versus siblings like cauta_firma or profil_firma, nor any exclusion condition. Usage is implied rather than 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description adds content categories (creditor, category, guarantees, declared/admitted amounts) but says nothing about response structure or pagination, so it adds only moderate 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?

Two sentences with no filler, front-loading what the tables are and what they contain. The trailing scope note is short, though its phrasing ('doar cate tabele si cati creditori sunt') is slightly opaque.

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 should clarify the return shape, but it is internally ambiguous: it claims to include creditors with category, guarantees and amounts, yet the closing sentence says it shows 'only how many tables and how many creditors'. This tension leaves the agent unsure of the return content.

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 (cui) and schema description coverage is 100%, so the schema fully documents the input. The description adds no syntax or format detail beyond identifying the firm context; 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 resource (creditor tables of a firm in insolvency) and enumerates the subtypes (preliminary, definitive, supplementary) plus the data included (creditors, category, guarantees, amounts). It is clear what the tool returns, though it never names or contrasts with the closest sibling, adunari_creditori.

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 tool is for querying creditor tables of an insolvent firm, and the scope note 'Fara functia in plan' marks a limitation. There is no explicit when-to-use versus alternatives such as adunari_creditori or profil_firma, so the agent must infer selection.

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 readOnlyHint=true already covering the safety profile, the description still adds real behavioral context: it clarifies that no invoices are required as input and that the tool does not author the declaration itself. It stops short of describing pagination or exactly how the deadline is computed.

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: the first front-loads what is returned, the second handles the scope boundary. No filler, and each clause carries information the agent needs.

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 convey return content, and it does: notification, filing deadline, and remaining days. Combined with the input-exclusion notes, an agent has everything needed 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?

There is a single parameter (cui) at 100% schema description coverage, so the schema already carries the meaning. The description adds nothing parameter-specific, which is the expected baseline of 3 when the schema does the heavy lifting.

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

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

The description states a specific resource and scope: for an insolvent firm it returns the opening notification, the deadline for registering the claim with the creditors' mass, and the days remaining. This is clearly distinct from siblings like tabel_creditori or adunari_creditori, which deal with creditor tables and meetings rather than the registration deadline.

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 names the triggering condition (a firm that has entered insolvency) and explicitly excludes adjacent work: it does not draft the declaration and does not need invoices, redirecting that generation to 'DateBPI, fila Declaratie de creanta.' That is clear when/when-not guidance, though no sibling tool is named as the alternative endpoint.

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