HowToRomania

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

With no annotations, the description carries the full burden and does so well: it discloses the external dependency (ANAF public service), the prerequisite (XML must pass validation), the return shape (base64 PDF resource), and the billing model (1 credit, not billed on errors). It omits rate limits and the practical size ceiling that the schema's maxLength implies.

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 short sentences, each load-bearing (mechanism, return format, prerequisite, cost), with the core action front-loaded and 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?

For a one-parameter stateless transform with no output schema, the description covers what goes in, what comes back, and the cost model. Remaining gaps (size limits, latency, failure modes beyond billing) are minor.

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% for the single parameter, so the schema already explains it is UBL 2.1 Invoice/CreditNote CIUS-RO XML. The description only loosely reinforces this via 'must pass validation', 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?

States a specific verb+resource ('Renders a valid e-Factura XML as PDF') and names the backing service, which clearly separates it from parse_efactura, validate_efactura and generate_efactura. An agent can identify the transform direction without opening any schema.

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

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

Gives clear context — the XML must be valid and the public ANAF service means no account is required — which implies validate_efactura should run first. It does not explicitly name an alternative or state when not to use it, so it stops short of full routing guidance.

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

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

No annotations exist, so the description carries the full burden and does well: it discloses the computed outputs (line, VAT and grand totals plus ANAF's validation verdict), the critical side-effect boundary (does not submit to SPV), and the billing profile (2 credits, free on errors). Rate limits and idempotency are unstated, but the mutation/cost/return behavior is unusually well covered.

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

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

Dense but front-loaded: the core verb+artifact leads, followed by input shape, computed outputs, side-effect boundary, and cost. Every sentence carries distinct information; the single-block paragraph form makes it slightly harder to scan than a bulleted alternative.

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 an 11-parameter nested tool with no output schema and no annotations, the description covers the essentials an agent needs: required inputs (number, seller, buyer, lines), autofill behavior, defaults, return payload, and non-submission. It is nearly complete, though a few auxiliary parameters and any failure modes remain undocumented.

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?

With schema coverage at only 45%, the description compensates substantially: it explains that supplying just the CUI triggers ANAF autofill of name, address, county code and VAT status, and it documents the VAT rate default (21%) and the full set of VAT categories including reverse-charge AE. The many untouched parameters (note, dueDate, paymentTerms, bank) keep it from a 5, since a low-coverage schema leaves gaps the prose does not close.

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 artifact ('Builds a valid RO e-Factura (CIUS-RO 1.0.1, UBL 2.1) invoice XML from simple JSON'), pinning down both the spec version and the output format. It explicitly declares what it does NOT do ('Does NOT submit to SPV'), which cleanly separates it from validate_efactura, parse_efactura and efactura_to_pdf.

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 operational context — generation only, no SPV submission, credit cost, no billing on errors — which frames when this tool is the right call. It stops short of explicitly routing to a sibling (e.g. 'use validate_efactura to re-check an existing XML'), so the when-not side is implied rather than named.

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

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

With no annotations, the description carries the full burden and does well: it discloses the billing model ('Costs 3 credits; not billed if nothing is found') and a privacy behavior ('Natural persons are masked (GDPR)') that the agent could not otherwise know. It omits auth/permission requirements and any pagination caveat beyond the limit param.

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 resource and source are front-loaded in the first clause, followed by the returned summary/list fields and then the cost/privacy notes. It is dense but every clause carries information; the enumerated return-field list is slightly long but justified given 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?

For a 5-param, no-annotation, no-output-schema tool, the description compensates by enumerating the return payload (summary breakdowns plus case list fields) and noting cost and GDPR masking. Only auth/permission expectations and any rate-limit behavior are missing.

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

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

Schema description coverage is 100%, so every parameter (cui, role, limit, since, category) is already documented in the schema, including the 'summary covers all' nuance for limit. The description adds no syntax, format, or filter semantics beyond that, 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 resource (Romanian court cases), the data source (portal.just.ro, Ministry of Justice), and the exact scoping key (a company by CUI). This is clearly distinguishable from the sibling get_court_case, which retrieves an individual case rather than a company's case portfolio.

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 the usage context (fetch all litigation for a company identified by CUI) but never states when to prefer it over get_court_case or how it relates to sibling legal tools. No explicit alternatives or prerequisites are named, leaving the agent to infer the distinction from the name alone.

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

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

With no annotations present, the description carries the full burden and does well: it discloses the cost model and the no-result refund behavior, the source (ANAF filings), the language of the output (English), the currency (RON), and the sign convention (negative = loss). It stops short of stating read-only semantics explicitly, pagination, or any freshness/recency limits on the filings.

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

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

Front-loaded with the resource and scope, then a dense but purposeful field list, then a short billing sentence. The field enumeration is long but each item is information the agent may need; only minor trimming is possible.

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?

Absent an output schema, the description appropriately enumerates the returned metrics (turnover, revenue, expenses, profit, employees, assets, cash, debts, equity, plus derived ratios), which is exactly what the agent needs. It does not describe the response shape (per-year records) or how the derived ratios are reported, leaving a small gap.

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

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

Schema coverage is 100%, so both parameters (cui, years) are already documented with format examples and defaults in the schema. The description reinforces 'by CUI' but adds no format, range, or interaction detail beyond what the schema provides, 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?

States a specific verb+resource (annual financial statements filed with ANAF for a Romanian company by CUI) and enumerates exactly what data comes back. It is clearly distinguishable from siblings like get_company_risk_report, get_company_court_cases, or lookup_company, which cover different data domains.

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 usage (you call it to get financials for a company identified by CUI) and adds useful billing context ('costs 5 credits; not billed if nothing is found'), which influences whether an agent should call it. However, it never names alternatives (e.g., risk report vs. financials) or states when NOT to use it, so selection guidance is inferred 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?

With no annotations, the description carries the full burden and does well: it names the data source and cadence ('ONRC monthly open-data snapshot', implying possible staleness), discloses the per-call cost (2 credits) and the no-charge condition when the CUI is not found, and notes that registry status is decoded. It omits any auth/permission requirements, but cost and freshness disclosure are the operationally important traits here.

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?

One dense sentence front-loads the resource and source, followed by a short cost sentence; nothing is boilerplate. It is somewhat list-heavy, but every enumerated field maps to real return content in the absence of an output schema, so the length is largely earned.

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 and no annotations, so the description must cover both returns and behavior — it enumerates the returned fields and discloses cost/source, which is close to sufficient for a single-parameter read tool. It leaves open whether data is stale between monthly snapshots and what happens on partial matches, minor gaps.

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 fully documented in the schema with an example format. The description adds only the phrase 'by CUI', which is already implied by the parameter; by the stated rubric this is the 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?

States a specific resource (Romanian company trade-register data by CUI) and enumerates the returned content (registration number, EUID, legal form, registry status, CAEN codes, legal representatives), which distinguishes it from get_company_financials, get_company_court_cases and get_company_risk_report. It never explicitly contrasts itself with lookup_company, which likely also keys on CUI, so the boundary is inferable but not stated.

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

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

Usage is only implied: the cost note ('Costs 2 credits; not billed if the CUI is not found') gives the agent a spend decision, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many company-oriented siblings. An agent must infer that this is the tool for ONRC registry details rather than the general 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?

With no annotations, the description carries the full burden and does well: it discloses the cost and its refund condition, the meaning and direction of the 0-100 score, that ONRC data is only "when available" (partial results possible), and an informational-only caveat. It omits any note on auth/prerequisites or response latency/rate limits, so a small gap remains.

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?

One front-loaded sentence covers the resource, the data composition, and the score semantics, followed by two short caveats (informational only; cost behavior). No filler and no repetition of the title or 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?

There is no output schema and no annotations, so the description must convey the return shape — it does so by listing covered sections plus the score range and direction and the presence of explained flags. 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% and the schema already documents the single parameter including both accepted formats (14399840 or RO14399840). The description only restates "by CUI" and adds the unknown-CUI billing behavior, so the standard 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 names a specific verb and resource (one-call due-diligence report for a Romanian company by CUI) and enumerates exactly what it aggregates: ANAF status, 3 years of financials, court cases from portal.just.ro, and ONRC data. This lets an agent distinguish it from narrower siblings like get_company_financials, get_company_court_cases, and lookup_company without opening any schema.

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

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

It clearly frames the use case (consolidated due diligence in one call) and supplies the decision-relevant constraint that it costs 8 credits, with no charge for an unknown CUI — useful for choosing it over cheaper single-purpose siblings. It stops short of explicitly naming those alternatives or stating when not to use the aggregate.

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

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

With no annotations, the description carries the full burden and does well: it names the data source (portal.just.ro), discloses credit cost with a no-charge-on-miss policy, and notes privacy handling ('natural persons masked'). It omits auth requirements and rate limits, which is a minor 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?

A single front-loaded sentence enumerates the return scope, followed by a short cost sentence. No filler, no redundancy, and the essential 'what you get' 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?

With no output schema and no annotations, the description enumerates returned fields (court, subject, stage, parties/roles, hearings with outcomes, appeals), the source, and billing behavior. It is nearly sufficient for an agent to call correctly, missing only auth/rate-limit context.

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 description coverage is already 100%, so the schema fully documents case_number. The description repeats the same example format the schema gives, adding no syntax guidance beyond it; 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+scope: 'Full detail of a Romanian court case by its number (e.g. 9430/271/2025)'. Implicitly distinguishes itself from the sibling get_company_court_cases by keying on case number rather than company, though it never names that 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 implied by the name and the by-number key, but there is no explicit when-to-use vs when-not guidance and no pointer to get_company_court_cases for company-based lookups. The credit-cost note hints at a usage consideration but does not route between alternatives.

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

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

With no annotations, the description carries the full burden and does well: it discloses pagination behavior and the default page size (50), a credit cost ('Costs 1 credit'), an offline-capability subset, and an authenticity caveat that consolidated forms are unofficial and only Monitorul Oficial text is authoritative. It omits rate limits and error behavior, so it is not exhaustive.

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

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

One dense but well front-loaded paragraph that leads with what is returned, then paging, then cost and caveats. The inline list of core code ids is long but functional; nothing is padding, though the sentence is heavy enough to be slightly hard to scan.

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

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

No output schema exists, so the description must describe the return shape, and it does: it enumerates top-level fields and article sub-fields including amendment counts. Combined with paging defaults, credit cost, source attribution, and the authenticity disclaimer, an agent has everything needed to call and interpret the 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 description coverage is only 33% (limit and offset have no descriptions), but the description compensates: it defines the id as a legislatie.just.ro DetaliiDocument id sourced from search_legislation with an example, and explains that offset/limit page through articles with a default of 50. This adds meaning beyond the schema's numeric bounds.

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

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

States a specific verb+resource with scope: 'Current consolidated text of a Romanian act by legislatie.just.ro id ... split by article'. It also enumerates the returned fields (title, issuer, publication, consolidation date, version list, articles), which distinguishes it from get_legal_article (single article) and get_legal_act_history (version history).

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 tells the agent where the id comes from ('from search_legislation') and that core codes can be fetched offline, which is real routing help. However, it never explicitly says when to choose this tool over get_legal_article or get_legal_act_history, so the guidance is implied rather than stated.

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

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

With no annotations, the description carries the full burden and delivers real behavioral context: 2-credit cost, no charge when nothing is found, upstream source (legislatie.just.ro / Ministry of Justice), and a caveat that consolidated forms are unofficial while only Monitorul Oficial text is authentic. It omits pagination, auth requirements, and result-size behavior, so not a 5.

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

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

Front-loaded with what is returned, then use case, then cost, then source/disclaimer. Every clause carries distinct information with no filler; the dense final sentence still earns its place by covering provenance and data-authenticity caveats.

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

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

No output schema exists, so the description must describe returns, and it does so in detail (version ids, amendment entries, dates). Cost, billing, and data-quality caveats cover the missing annotations. The remaining gap is the origin/format of the required 'id' parameter.

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?

At 50% schema coverage, the description partially compensates by explaining that the request can target a whole act or a single article, matching the id/article pair. However, it never says what 'id' is or where to obtain it (e.g., from search_legislation), leaving the required parameter semantically opaque.

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 ('amendment history') plus concrete return content: consolidation dates with version ids and a dated amendment list with date-in-force, what changed, and by which act. The temporal-query framing ('what was the VAT rule on date X') inherently separates it from the current-text siblings get_legal_act and get_legal_article.

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 a concrete usage scenario plus scope ('a whole act or one article'), which tells the agent when to reach for it. It never names the alternatives (get_legal_act, get_legal_article for current text) or states exclusions, so it stops short of explicit 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?

No annotations are provided, so the description carries the full burden, and it does well: it discloses billing behavior (1 credit, not billed on miss), the data source (legislatie.just.ro / Ministry of Justice), and an accuracy caveat that consolidated forms are unofficial vs the authentic Monitorul Oficial text. It omits auth requirements and rate limits, hence 4 rather than 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?

Front-loaded with the core operation, then layered with structure, edge-case notation, cost, and provenance; every sentence carries information. It reads as a dense run-on rather than cleanly separated clauses, which costs it the top score.

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 2 fully-documented required params and no output schema, the description usefully compensates by describing what the response contains (paragraph/letter structure, dated amendment notes). Cost, source, and authenticity caveats are covered; error/empty-result behavior and auth needs are not spelled out, so not 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% and the schema already supplies the same examples (171282, 291/293^1) that the description repeats, so the description adds little beyond the schema. The one marginally new detail is the caret-notation support note, but it is mirrored in the schema, keeping this at the 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?

States a precise verb+resource ('One article in its current consolidated form') and disambiguates scope by giving a concrete example (Codul fiscal 171282 art. 291) plus the richness of the return (paragraph/letter structure, dated amendment notes). Scope 'article' vs the sibling get_legal_act is only implied by the singular noun, not stated explicitly, so it stops short of full sibling differentiation.

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?

No explicit when-to-use guidance versus siblings such as get_legal_act (whole act), get_legal_act_history, or search_legislation. The cost note ('Costs 1 credit; not billed if not found') is useful context, and the singular 'one article' implies a narrow fetch, but the routing decision is left to inference.

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

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

No annotations exist, so the description carries full burden. It discloses the cost (1 credit), the data source, that consolidated forms are unofficial and only Monitorul Oficial text is authentic, and that it's informational. This goes beyond typical disclosure, but it doesn't mention return format, pagination, or rate limits.

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

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

Single, dense sentence that front-loads the core purpose and then adds operational details. It's appropriately concise and front-loaded, though the parenthetical enumeration makes it slightly long but still efficient.

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

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

Given 1 parameter, no output schema, and no annotations, the description provides sufficient context: what acts are included, date filtering rules, cost, source, and authenticity caveat. It could be improved with a note on return structure or pagination, but overall it's complete for this simple tool.

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

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

The schema has 0% description coverage for the `since` parameter, so the description must compensate. It clearly explains: `since` is an in-force date, defaults to last 7 days, max range 35 days. This fully clarifies the parameter's semantics beyond what the bare schema provides.

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

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

The description names the specific resource (newly indexed legal acts from legislatie.just.ro), enumerates act types (laws, ordinances, ministerial orders, court decisions), and scopes it to those with an in-force date on/after `since`. This clearly differentiates it from siblings like get_legal_act (specific act) and search_legislation (search).

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

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

It creates a clear context: this is for recently indexed acts, with a default of last 7 days and max 35. However, it doesn't explicitly state when to use this over search_legislation or get_legal_act, though the temporal and 'newly indexed' framing provides strong implicit 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?

No annotations are provided, so the description carries the full burden. It states the data source (ANAF) and output language (English), but says nothing about rate limits, error behavior for invalid CUIs, or whether the lookup is cached/live. For an external-API lookup with zero annotation coverage, this is a notable 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?

A single sentence that front-loads the input requirement and then the returned fields. No waste, 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?

Returns are enumerated and params are fully covered by the schema, but with no annotations and no output schema, the description omits the behavioral and error-handling context an agent needs. Adequate for invocation, thin for edge cases.

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%, with the CUI format and include_fx default already documented in the schema. The description mentions the BNR rate (mapping to include_fx) but adds no syntax or format detail beyond the schema, 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 (look up) and resource (Romanian company by CUI/CIF), and enumerates the exact fields returned, letting an agent distinguish it from siblings like get_company_financials or get_company_risk_report.

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 the input is a CUI/CIF lookup but gives no explicit when-to-use guidance or naming of alternatives among the many company/legal siblings. It is adequate but leaves sibling selection to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses accepted input standards (UBL 2.1, CIUS-RO), the source system, and a pricing model with a failure caveat ('Costs 1 credit; not billed on errors'). It does not cover auth requirements, size limits, or what errors look like beyond the billing note.

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 input then output then cost, with no filler. It is long due to legitimate enumeration of returned fields, but every clause carries information an agent would otherwise have to guess.

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 correctly enumerates the returned structure (header fields, parties, payment means/IBAN, lines, VAT breakdown and totals). Combined with a fully documented input parameter and the cost caveat, an agent has everything needed to call and interpret this 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 100% and there is a single parameter whose schema description already states the UBL 2.1 / RO e-Factura / CIUS-RO constraint. The description largely restates that format in prose, adding little syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (turns/parses) on a specific resource (UBL 2.1 e-Factura invoice or credit note XML) and names the concrete output (clean English JSON). It is clearly distinguishable from siblings like validate_efactura, efactura_to_pdf, and generate_efactura without opening any schema.

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

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

It supplies the input context ('e.g. downloaded from ANAF SPV'), which implicitly tells the agent what kind of document fits, but there is no explicit when-to-use versus validate_efactura or efactura_to_pdf, nor any stated prerequisites or exclusions. Usage is implied rather than directed.

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

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

With no annotations, the description carries the full behavioral burden and does substantial work: it discloses ranking behavior (codes and laws before decrees/orders), credit cost and the no-match refund rule, the data source, and an authority disclaimer. It stops short of describing pagination or how the limit parameter interacts with result count.

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

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

Front-loaded with purpose and examples, then ranking, return handoff, cost, and provenance. Dense but every clause adds usable information; the closing legal disclaimer is slightly tangential but relevant to trusting the results.

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

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

No output schema exists, yet the description explains what comes back (act ids for downstream tools) and how results are ordered. The main gap is the absence of any guidance on limit/pagination and the year/number filters, which an agent with 5 params would benefit from.

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 40%, so the description must compensate. It richly documents what 'q' accepts (citations, title words, multiple format examples) and implies the act-type filter via the ranking note, but leaves year, limit, and number entirely undocumented in both schema and description.

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 (Finds) and resource (Romanian normative acts on legislatie.just.ro) and gives concrete query examples like 'Legea 31/1990' and 'Codul fiscal'. It also differentiates itself from siblings by naming get_legal_act / get_legal_article as the tools that consume its returned ids.

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?

Clearly frames when to use it: by citation or title words, with examples of accepted forms. It also routes the agent to the follow-up tools via the returned act ids. It lacks an explicit when-not-to-use condition, but the selection context 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?

With no annotations present, the description carries the full burden and does so well: it discloses the external dependency (ANAF's official public validator via XSD + Schematron), the auth situation (no ANAF account needed), the cost model (1 credit, not billed if ANAF is unreachable, avoiding surprise charges on failure), and the return shape (valid boolean plus exact BR-xx/BR-RO-xx rule codes with bilingual messages). This is materially richer than any structured field provides.

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

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

Three dense sentences, front-loaded with the core action and validator engine before moving to output and billing. No filler, no repetition of the title, and each clause adds a distinct fact an agent would otherwise have to guess.

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, the description does the heavy lifting by describing both the validation engine stack and the return values, so an agent knows what it gets back. Minor gaps remain: no mention of latency/timeouts for the remote ANAF call or behavior on malformed input, but nothing critical to 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?

There is a single parameter and schema description coverage is 100%, so the schema already documents that it expects UBL 2.1 Invoice or CreditNote XML for RO e-Factura/CIUS-RO. The description restates the same format constraint but adds no syntax, encoding, or size guidance beyond the schema's maxLength, so the baseline of 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?

States a specific verb (validates), a specific resource (UBL 2.1 invoice/credit note), and a specific standard/rule set (RO e-Factura CIUS-RO), which cleanly separates it from the sibling generate_efactura, parse_efactura, and efactura_to_pdf. An agent can pick this tool without opening any schema.

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

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

The description implies the use case (checking an e-Factura before submission) and notes that no ANAF account is required, which is useful selection context. However, it never explicitly says when to use this versus generate_efactura or parse_efactura, nor when validation is unnecessary, leaving the routing to inference.

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