DateBPI

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds that results include meeting metadata and outcomes, but the trailing exclusion is ambiguous and nothing is said about volume, ordering, or what happens when a company has no meetings.

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 its returned fields. The closing clause is imprecise and costs a bit of clarity, but overall there is little waste.

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, read-only lookup with no output schema and full annotation coverage, the description is nearly complete because it lists the fields returned. Only the unexplained exclusion clause and the absence of any result-shape hint keep it from a 5.

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

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

Schema description coverage is 100% with a single required 'cui' parameter already documented in the schema, so the baseline is 4. The description adds no parameter-level detail, but none is needed.

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 (creditors' meetings and committees of a company) and enumerates what it exposes: date, time, agenda, practitioner, and decisions taken. It lacks an explicit verb (list/retrieve) and never names a sibling such as tabel_creditori to disambiguate the closely related creditor-table tool.

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 statement of when to call this tool versus tabel_creditori or profil_firma, which are the obvious alternatives for creditor and company data. The final clause ('fara functia in plan: doar numaratori') gestures at an exclusion but is too cryptic to function as usable 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?

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the description's mentions of "Idempotent" and "Nu sterge nimic" restate structured data. However, it adds real behavioral context beyond annotations: the firm remains in Radar with its history intact but stops emitting alerts, which tells the agent exactly what state change occurs and what is preserved.

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 passage with zero waste. The core action and its effect are front-loaded, followed by the non-deletion clarification and the alternative pointer.

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 one-parameter mutation with full annotations, full schema coverage, and no output schema, the description covers what the agent needs: the state change, what is preserved, that it's idempotent, and where deletion lives instead. 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?

Only one parameter exists and schema description coverage is 100%, so the schema already documents cui fully. Baseline of 4 is appropriate; the description adds no syntax or format detail beyond the schema, but none is needed.

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 ("opreste" = stop) and resource (alerte for a firm in Radar) with a precise scope: the firm stays with its history but sends no alerts. It explicitly distinguishes itself from the sibling radar_elimina, so an agent can tell deletion from muting 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 explicitly ("pentru stergere exista radar_elimina") and clarifies the boundary between stopping alerts and deleting a firm. It gives a clear condition but doesn't spell out when to prefer this over alerte_porneste, leaving that to the natural complementary naming.

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 that this is a mutation, non-destructive, idempotent, and closed-world. The description adds useful behavioral detail beyond that: it reactivates existing alerts and conditionally adds the company to Radar if it is not already present.

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

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

The description is three short sentences, front-loaded with the primary action, then the fallback behavior, then a key property. Every sentence contributes useful 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 one-parameter mutation tool with rich annotations and no output schema, the description covers the main side effects and idempotency. It could mention permissions or error behavior, but those are not essential given the structured metadata.

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% and the single parameter (cui) is documented in the schema. The description does not add further meaning about the CUI format or validation, so the schema carries the parameter semantics.

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

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

The description states a specific action (starting alerts) for a specific resource (a company in Radar) and explains the fallback behavior of adding the company if absent. This clearly distinguishes it from the opposite sibling alerte_opreste.

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 implies when to use the tool by describing its effect (reactivating alerts or adding a missing company), but it does not compare it with alternatives such as alerte_opreste or radar_adauga. No explicit exclusions or prerequisites are given.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: default window of 7 days with a hard 90-day ceiling, newest-first ordering, and a maximum of 50 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?

A single dense sentence front-loads the resource and time window, then appends the optional filter, returned fields, ordering and cap. No filler, and the result-shape list compensates for the absent 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 and no annotations covering data shape, the description usefully enumerates returned fields plus ordering and the 50-item cap. It stops short of saying what happens when more than 50 alerts match (truncation vs pagination), which is the one operational ambiguity left.

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 both parameters are already documented, including the maximum of 90 and default of 7. The description restates the same window facts and only clarifies that CUI narrows to a single company, adding little beyond structured fields. 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 states a specific verb+resource: alerts received from Radar within the last N days, with an optional CUI filter, and enumerates the returned fields (type, title, summary, date, company, publication). This is clear enough to distinguish it from a write/monitoring sibling, but it never contrasts itself with adjacent tools like radar_lista or alerte_surse, which an agent must choose between.

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 by the phrasing (retrieve recent alerts in a time window), and the optional CUI is framed as 'doar pentru o firma'. However there is no explicit statement of when to prefer this over radar_lista or alerte_surse, nor any exclusion criteria, so the agent must infer 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 mutation (readOnlyHint=false), idempotence, and non-destructiveness, so the bar is lower; the description still adds the important behavioral fact that the supplied list is the complete desired set, meaning unlisted sources are dropped and the empty case fails. It does not describe the response, which is the remaining gap.

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: the action and replacement semantics come first, then the enum payload, then the edge-case routing. Every clause is load-bearing; the long value list is necessary data, not 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?

For a 2-parameter, no-output-schema mutation tool this covers the action, valid values, and the empty-list failure mode. It is slightly silent on prerequisites (e.g. whether the firm must already be on the Radar list via radar_adauga) and on the call's result.

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

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

Schema coverage is 100% but the schema descriptions are thin ("Sursele dorite, separate prin virgula") and carry no enums. The description supplies the entire valid source vocabulary plus the comma-separated convention, which is meaning the schema does not provide at all.

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 ("Seteaza") and resource ("sursele urmarite pentru o firma din Radar") and makes clear the operation is a full replacement ("lista completa dorita"), not an append. The enumerated vocabulary and the pointer to alerte_opreste distinguish it from every sibling 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?

States a hard constraint (empty list is rejected) and routes the agent to the correct alternative for the empty case ("pentru «nimic» foloseste alerte_opreste"). That is explicit when-not guidance, not mere implied context.

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, non-destructive, closed-world behavior. The description adds meaningful return-shape context (CUI, judet, stare, numar publicatii), which is valuable since no output schema exists, though it omits pagination/limit behavior or result ordering.

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 waste, front-loading the core purpose before the return details and workflow hint.

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, the description adequately explains what is returned and how to use it downstream. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so both q and limita are already documented in the schema. The description restates the searchable criteria but adds no format or syntax nuance beyond what the schema provides, 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?

States a specific verb (cauta) and resource (firma) with search criteria (denumire or CUI). It further clarifies scope by noting it returns both BPI-publication firms and registry firms, distinguishing it from siblings like publicatii_bpi.

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 agent with 'Foloseste CUI-ul returnat in celelalte unelte,' giving a clear workflow context. It lacks an explicit when-not or a named alternative sibling, but the intended usage is unambiguous.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful context beyond them – the subscription requirement, which is a real call-blocking constraint, and the shape of returned records (number, court, subject, stage, last ruling, next hearing, party role). It does not mention pagination limits, result caps, or rate behavior, which are left to the schema or omitted.

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, both earning their place: the first front-loads what can be searched and how to filter, the second states the return fields and the subscription prerequisite. The enumeration is dense but not padded; nothing is repeated.

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 13-parameter, zero-required, read-only search tool with no output schema, the description covers search modes, filter dimensions, return fields, and an access prerequisite – enough for an agent to call it correctly. The main omission is guidance on how filters interact with the free-text query and what an empty result implies.

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 every one of the 13 parameters is already documented with examples and defaults. The description only restates the same categories (materie, stadiu, judet, instanta, insolventa, calitate, date interval) without adding syntax, interaction rules such as how q and ce combine, or guidance on combining multiple filters – 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 opens with a specific verb+resource ('Cauta dosare in instanta') and enumerates every search axis: CUI, party name, docket number with a concrete example, and free-text in the subject or ruling. It is not explicit about how it differs from the singular sibling dosar_instanta, so an agent must infer plural-search vs. single-case lookup from the names 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?

It clearly states the conditions under which the tool is used (searching a portfolio of cases by identifier, party, text, or filters) and surfaces a hard prerequisite: 'Cere un abonament care include Dosare Instanta.' It stops short of naming alternatives or exclusions, e.g. when to prefer dosar_instanta for a known docket number.

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 read-only, non-destructive, closed-world behavior, so the safety profile is covered; the description adds genuinely new behavioral context by stating the required subscription ('Cere un abonament care include Dosare Instanta'). It does not describe failure modes for a bad or missing id, which keeps it below 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?

A single front-loaded sentence: resource and lookup key first, then the content enumeration, then the subscription caveat. The content list is long but each item conveys what the agent will receive, so the density is justified rather than 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?

There is no output schema, so the enumeration of returned sections (hearings, solutions, parties, key facts, associated files, court route, BPI publications) usefully substitutes for it, and the subscription requirement is covered. A note on behavior for an unknown id would make it fully complete.

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 parameter is fully documented in the schema, including that the id originates from dosare_instanta, so the description adds no meaning beyond the structured field. 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?

It states a specific verb-and-resource ('Detaliul unui dosar de instanta dupa id') and then enumerates the returned content (hearings, solutions, parties, key facts, associated files, court route, BPI publications), so the agent can distinguish it from the list-style sibling dosare_instanta 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 signals the use condition by tying the id to 'din dosare_instanta', which tells the agent to obtain the identifier from the sibling tool first, and it flags the subscription prerequisite. It does not state explicit exclusions or alternatives beyond that, 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, so safety is covered. The description adds content-scope detail beyond that — statuses per company and that persons appear by name only, without role — which helps an agent interpret results, though the final sentence ('Fara functia in plan: doar numaratori') is cryptic and hard to act on.

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 no padding. The core scope (which companies are returned) is front-loaded, though the trailing clarity-reducing sentence slightly undercuts the efficiency.

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 and no annotations about result shape, the description must carry the return-value burden. It does describe statuses and the name-only treatment of persons, but leaves the response structure and the meaning of the final 'doar numaratori' clause unexplained.

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% for the single required parameter 'cui', which the schema already documents as 'CUI-ul firmei'. The description never mentions the CUI input or any format expectations, so it adds nothing 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?

The description names the resource precisely: the other companies belonging to a firm's administrators and associates, each with its status (active, insolvent, bankrupt, dissolved). That is distinguishable from siblings like profil_firma or cauta_firma. It lacks a leading verb (it reads as a noun phrase) but the content is specific.

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 statement of when to use this tool, no prerequisites, and no reference to any alternative sibling. The only guidance-like sentence ('Fara functia in plan: doar numaratori') is about output content, not about when to invoke.

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=false and destructiveHint=false, so safety is covered. The description usefully adds what fields come back and that results are limited to outcome states (no bids / adjudicated), but says nothing about pagination, empty results, or whether a company not in insolvency returns nothing.

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 first sentence is front-loaded and dense with useful facts with no waste. The second sentence ('Fara functia in plan: doar numaratori') is opaque and consumes space without conveying a usable constraint, hurting structure.

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

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

For a single-parameter read-only tool with no output schema, enumerating returned fields is the right compensation and partly delivers. Missing is any indication of result ordering, volume, or behavior for firms without an insolvency proceeding, leaving the agent with gaps before 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?

Only one parameter (cui) exists and the schema documents it at 100% coverage ('CUI-ul firmei'), so the schema does the work. The description adds no format hints, validation rules, or acceptance of non-insolvency CUIs, which is the one thing an agent might get wrong here.

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 concrete resource (auctions and asset sales of a company in insolvency) and enumerates the returned content: what is sold, starting price, date/place, liquidator, result. That is more specific than the bare name 'Licitatii'. It does not name a sibling to contrast with, even though dosare_instanta and publicatii_bpi are nearby candidates, so it stops short of a 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?

There is no statement of when to pick this tool over dosare_instanta or publicatii_bpi, and no prerequisites beyond the implicit CUI. The only guidance-like clause, 'Fara functia in plan: doar numaratori', is cryptic and reads as an internal scope note rather than actionable instruction.

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/non-destructive/closed-world, so the bar is lower; the description still adds genuinely useful behavior: it draws down the subscription's daily company quota, same as the web UI, and notes that the insolvency filing is returned only 'daca exista'. It does not say what happens on an unknown CUI or whether results are cached/fresh.

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 payload inventory, with the cost caveat second — exactly the right order. The payload list is dense but each item carries information an agent needs to decide if this tool answers the question.

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 describe the return value — and it does so item by item, including a conditional field and the quota cost. For a single-parameter, closed-world read tool, an agent has everything needed to call it correctly and anticipate the cost.

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 stating 'CUI-ul firmei, doar cifre'. The description confirms the lookup key is the CUI but adds no format or validation detail beyond the schema, so baseline 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 and key (the company profile by CUI) and enumerates exactly what the profile contains: ONRC/ANAF status, arrears, insolvency filing, risk score and factors, early warning signals, BPI publication count. That enumeration distinguishes it from siblings like cauta_firma (search) or publicatii_bpi (single data slice), though it never explicitly contrasts with them.

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 breadth of the payload and the note that it consumes the daily company budget signal this is the heavyweight composite lookup, not a cheap search. No explicit when-to-use, when-not-to-use, or named alternative (e.g. cauta_firma for lookup-only, dosare_instanta for court detail) is given.

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 readOnly/openWorld annotations: it discloses subscription gating, chunked delivery of 12,000 characters, the continuation mechanism, and — importantly — that the call consumes the subscription's daily document quota. That quota cost is exactly the kind of side effect an agent needs before calling.

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

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

A single dense sentence, front-loaded with the resource and id source, then access conditions, chunking, and budget cost in order of decision importance. Slightly heavy as one sentence but no wasted clauses.

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 return-value burden and does so reasonably (metadata plus conditionally full text). Remaining gaps — behavior without subscription and how to detect the final chunk — are minor but real for a paged retrieval 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?

Schema coverage is already 100%, but the description adds conceptual meaning the schema lacks: that de_la is a chunk cursor tied to 12,000-character segments rather than an arbitrary offset. It doesn't cover alternative id format risk/validation beyond what the schema example shows.

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 (retrieve) and resource (a BPI publication) and anchors the identifier source to the sibling tool publicatii_bpi, so an agent can tell it apart from the listing tool. It also distinguishes the payload clearly: metadata always, full text conditionally.

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 that the id comes from publicatii_bpi and that full text requires an active subscription or paid firm access, and describes the continuation pattern via de_la. It does not state what happens when access is absent (metadata-only versus error), which is the main missing 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds behavior beyond that: results are ordered newest-first, pagination is fixed at 20 per page, and the exact result columns are disclosed — all useful context an annotation 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 resource, then the returned fields, ordering, filters and pagination, ending with the sibling redirect. No filler sentences and nothing that could be dropped without losing 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?

There is no output schema, but the description compensates by naming the returned columns, the sort order and the page size, which is everything an agent needs to interpret results and paginate. Combined with annotations covering the read-only profile, nothing material is missing for a 4-parameter list 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?

Schema coverage is 75%, with 'pagina' carrying no schema description; the description compensates by stating 'paginare (20 pe pagina)', giving the page size needed to use that parameter. It also confirms that 'text' matches title words and 'an' filters by year, matching the schema examples rather than merely repeating them.

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 (list BPI publications of a company) and enumerates the returned fields (numar, data, titlu, dosar, instanta). It explicitly distinguishes itself from the sibling publicatie_bpi, which is named as the tool for full text, so an agent can pick correctly 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 closing sentence routes the agent: this tool lists and filters, while 'Textul integral se citeste cu publicatie_bpi' names the alternative for full text. Usage is clear from context (search publications for a CUI with year/title filters), though it doesn't state explicit exclusions such as when a plain company profile would suffice.

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 the write, non-destructive, idempotent profile; the description adds real behavior beyond them: an ambiguous denumire adds nothing and returns candidates, and a repeat call for the same CUI returns the existing entry rather than erroring. Missing are any permission/quota or 'what monitoring costs you' notes, and it never confirms the write is reversible (radar_elimina exists but is not cross-referenced).

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 front-loaded sentences covering purpose, name-resolution semantics, source list, and idempotent re-call; nothing is filler. The long parenthetical source list is bulky but is the tool's only documentation of allowed values, so it 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?

With no output schema, the description does the work of explaining return behavior for both the ambiguous-name and duplicate-CUI cases, and it fully covers all three optional parameters. What remains unsaid is the shape of a successful response (entry id, confirmed sources) and any prerequisites such as the firm needing to exist in the registry.

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

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

Schema coverage is 100%, so baseline would be 3, but the description enumerates the accepted surse tokens (bpi, dosare, onrc, monitorul_oficial, ...) that the schema does not list as an enum — a genuine value add for a free-form comma-separated string. It also restates the preference for cui over denumire, which the schema only hints at via '(preferat)'.

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 ('Adauga o firma in Radar') plus the effect (monitorizare cu alerte), and the two accepted lookup keys. It is unmistakably distinct from siblings radar_lista and radar_elimina without needing their 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?

Gives clear selection logic between the two input modes — CUI is 'preferat', denumire is for when 'nu stii CUI-ul' — and explains what happens with an ambiguous name. It does not explicitly route the agent away from cauta_firma when the goal is only to look up a company, so it stops short of full when-not guidance.

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

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

Annotations already declare destructiveHint=true, and the description goes further by naming exactly what is destroyed (the company plus its alert history) and that the deletion is definitive. It also discloses the dry-run behavior and the human-confirmation requirement, which 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?

Three short sentences, front-loaded with the destructive action and its scope, then the confirmation protocol, then the alternative. Nothing extraneous.

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 two parameters, no output schema, and full annotation coverage, the description supplies the remaining essentials: what gets destroyed, what a non-confirmed call returns, and which sibling to use instead. Nothing an agent needs to call it safely 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 real meaning for 'confirm': without it the call is a non-destructive preview that also solicits user confirmation. The 'cui' parameter is left entirely to the schema, which is acceptable.

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 ('Sterge definitiv o firma din Radar') plus the scope of the deletion ('cu istoricul ei de alerte'), which distinguishes it from alert-only tools. An agent can tell it apart from alerte_opreste and radar_lista 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?

Explicitly names the alternative for the adjacent use case ('Pentru a opri doar alertele foloseste alerte_opreste') and states the workflow gate: without confirm=true it returns a preview and asks the user for confirmation. Both when-to-use and when-to-use-something-else are covered.

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/openWorldHint=false/destructiveHint=false, so safety is covered, and the description adds genuinely new behavioral facts: results span the user AND their team, the per-company alert window is 30 days, and pages are capped at 50 items. It stops short of stating sort order or how to enumerate all pages.

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-loads the resource, then the returned fields, then the filter, then the page cap, with no filler. The field enumeration runs long but every item is information the agent would otherwise have to guess (there is 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 carries the return-value burden and does so by listing the per-company fields, the team-wide scope, and the 50-item page limit; two optional params and a read-only annotation set mean nothing else is needed 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 coverage is 50%: 'filtru' is documented in the schema and the description largely repeats its accepted values, while 'pagina' has no schema description. The phrase 'Maxim 50 pe pagina' partially compensates by telling the agent the page size, but nothing explains numbering or total-page behavior, so it is baseline-level.

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?

Enumerates a specific resource (firmele din Radarul utilizatorului/echipei) and the exact fields returned (CUI, denumire, stare alerte, surse, vechime, numar alerte 30 zile, banda semnale timpurii). An agent can tell it is the read/list counterpart of radar_adauga and radar_elimina, though no sibling is named explicitly.

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 optional filter is described ('activ', 'inactiv', sau fragment din denumire/CUI), which implies when to narrow the listing, but the description never states when to use this tool instead of cauta_firma or profil_firma, nor any prerequisite or exclusion.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the description needn't repeat it. The description does add useful content scope: it lists the returned elements and clarifies that the 'functia in plan' field is omitted and that only table/creditor counts are given. It stops short of describing what happens for a firm that is not in insolvency, or the shape of the 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?

Two compact sentences: the first establishes the resource and its contents, the second establishes the exclusion. Nothing is wasted, though the second sentence is terse enough that its reference to counts is slightly ambiguous.

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 one-parameter, read-only tool with no output schema, the description covers the essential content and the notable exclusion. It is less complete on edge cases (firm with no insolvency proceedings) and on how the table/creditor counts relate to the listed creditor details, leaving the agent to infer the response structure.

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 schema already documents it fully. The description adds no information about the identifier (e.g. format, whether numeric or with prefix), 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 identifies a specific resource (creditor tables of an insolvent firm) and enumerates the variants covered: preliminary, definitive, supplementary. It also states what data is included (creditors, category, guarantees, declared/admitted amounts) and what is excluded ('fara functia in plan'), which lets an agent distinguish it from siblings such as adunari_creditori. It does not, however, explicitly name a sibling alternative.

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 this applies to firms in insolvency, but there is no explicit statement of when to call it versus adunari_creditori or profil_firma. The one exclusion ('fara functia in plan') concerns a field rather than a tool choice, so it does not route the agent between siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and the description adds meaningful context beyond them: the exact result contents (notification, deadline, days remaining) and the negative behavior (no drafting, no invoice requests). It does not say what happens for a firm not in insolvency, which keeps it below 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?

Two tight sentences with zero filler; the scope and returned fields come first, the exclusion and alternative second. 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 one-parameter read-only lookup with full schema coverage and no output schema, the description covers what an agent needs to select and call it, including what the response contains. Only the non-insolvency / not-found path is unaddressed.

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?

Single parameter 'cui' is already documented at 100% schema coverage, so the schema carries the semantics. The description implies the firm identity is the lookup key but adds no format, validation, or accepted-variant guidance 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 resource (an insolvency company) and precisely enumerates what the call returns: the opening notification, the creditors-list filing deadline, and days remaining. It also explicitly distinguishes itself from declaration generation, so an agent knows this is a deadline lookup, not a document builder.

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 scopes usage to 'o firma intrata in insolventa', states what the tool does NOT do ('Nu redacteaza declaratia si nu cere facturi'), and redirects generation to DateBPI, fila Declaratie de creanta. When-to-use, when-not, and alternative are all present.

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