HowToRomania

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

Annotations already declare readOnly/idempotent/openWorld=false, and the description still adds material behavior: local-only execution, no registry hit, rate limiting per IP, no API key required, and a specific accuracy caveat that the final digit of new-format registration numbers (J2020001234400) is not verified. The explicit existence-check limitation prevents an agent from mistaking a pass for a validity guarantee.

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

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

Three sentences, no filler, front-loaded with the capability list before the limitations and the sibling handoff. The density is high but every clause (free, local-only, rate limit, last-digit caveat, alternative) carries actionable 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 five-parameter, zero-required validation utility with no output schema, the description covers capabilities, limits, cost, and rate behavior well. The remaining gap is that it never indicates what a response looks like (per-field pass/fail results?) or whether supplying several parameters yields combined or separate verdicts, which matters since there is no output schema to consult.

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

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

Schema description coverage is 0%, so the description must carry the load; it partially does by mapping each check to a param (cui, iban, registrationNumber, name, invoice arithmetic with net/VAT/total/date/vatRates). However, it never states that all five parameters are optional and independently evaluable, which fields inside the nested invoice object are required, or the expected syntax for CUI/IBAN beyond the checksum concept.

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 exact resource class and enumerates the concrete checks performed: CUI checksum, IBAN checksum plus Romanian bank derivation, old/new trade register format, company name normalization, and invoice arithmetic (total = net + VAT, Romanian VAT rates, future-date rejection). It also draws a hard boundary — 'no registry lookup' — that separates it from lookup_company and validate_extracted_company_data, so an agent can pick it 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 states both the positive condition (offline format validation, works with no API key) and the exclusion ('Does not check that the company exists'), then routes the agent explicitly: 'For registry checks use validate_extracted_company_data.' That is a named alternative with a stated selection rule.

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

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

Goes well beyond the annotations by disclosing the external dependency (public ANAF service), the return encoding (base64 resource), the credit cost, and that errors are not billed. These are exactly the operational facts an agent needs before committing to the call.

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 carrying distinct information: purpose, output format, precondition, and cost/error policy. Front-loaded with the core action 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?

No output schema exists, and the description compensates by explaining the return (PDF as base64 resource). Combined with the stated cost and error behavior, nothing an agent needs to invoke this correctly is missing.

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

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

With one parameter at 100% schema description coverage, the schema already documents the UBL 2.1 Invoice/CreditNote format and length bounds. The description adds only the validity requirement, not format or syntax detail beyond the schema — baseline 3 applies.

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

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

States a specific verb+resource ('Renders a valid e-Factura XML as PDF') and names the mechanism (ANAF's public transformation service). It is clearly distinguishable from siblings like parse_efactura (extraction), validate_efactura (checking), and generate_efactura (creation).

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

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

Provides a clear precondition ('The XML must pass validation') and notes no ANAF account is required, which tells the agent when this tool is applicable. It stops short of explicitly routing to validate_efactura as the prerequisite step or naming alternatives, so it's clear context rather than full when/when-not guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: 2-credit cost, no billing on errors or when ANAF's validator is unreachable, XML still returned in that case, and the returned validation verdict. This is exactly the extra behavioral detail annotations cannot convey.

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

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

A single dense paragraph that front-loads the core action and standards, then layers defaults, return value, and cost. Every clause carries information, though the run-on structure makes it slightly harder to scan than a bulleted form.

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, and the description correctly explains the return (XML plus ANAF validation verdict) and the failure mode. For an 11-param nested tool this is nearly complete, with only minor optional fields left 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 only 45% schema coverage, the description compensates well: CUI-only autofill from ANAF, default VAT rate 21% with the S/Z/E/AE/K/G/O category list, and the vatToRonRate requirement when currency is not RON. A few params (dueDate, paymentTerms, note) remain unexplained, keeping it below 5.

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

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

States a specific verb (Builds) and resource (RO e-Factura invoice XML) with the exact standards (CIUS-RO 1.0.1, UBL 2.1), and the 'Does NOT submit to SPV' clause separates it from submission tools and from validate_efactura/parse_efactura siblings.

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

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

Gives clear context for when to use it (building XML from simple JSON, with ANAF autofill and validation) and an explicit exclusion (does not submit to SPV). It stops short of naming validate_efactura or parse_efactura as alternatives, so routing between siblings is only partly resolved.

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

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

Annotations already declare this as a safe, read-only, idempotent, closed-world operation, and the description adds genuinely non-redundant behavior: zero credit cost, keyless operation, per-IP rate limiting on keyless calls, and the important semantic that a date with no exact fixing resolves to the latest fixing on or before it. Values are explicitly unchanged from the BNR source, which tells the agent how much to trust the output.

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 modes, then cost/auth, then provenance — a sensible priority order with no filler. The first sentence is densely packed with nested parentheticals, which costs a bit of readability, but each clause carries real 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?

With no output schema, the description still conveys what comes back (all currencies or one for a date; a daily series over a range) and notes values are verbatim from BNR. Missing only the response field shape and pagination/format details, which are minor for a two-mode lookup 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 only 50% — `from` and `to` have patterns but no descriptions — and the description compensates by explaining that they define a daily series bounded at 366 days, plus that currency defaults to EUR for history and is optional for single-date (all currencies vs one). It does not clarify whether `currency` is mandatory for the series mode, leaving the from/to+currency interaction slightly underspecified.

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 (BNR reference exchange rates in RON) and immediately enumerates its two operating modes: single-date fixing lookup and daily series for one currency. The scope (from 2005-01-03) and the source (bnr.ro) make it unmistakably distinct from the sibling tools, none of which deal with FX rates.

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 effectively routes the caller: use `date` for a single fixing (latest on/before that date, all currencies or one) or `from`/`to` for a daily series in one currency, capped at 366 days. It gives clear conditions for each mode but names no alternative tool or exclusion, so it stops short of full when/when-not guidance.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world, but the description adds substantive behavior the annotations cannot: credit cost and the no-result billing exemption, GDPR masking of natural persons, and that criminal cases suppress detail with a criminalDetailsWithheld: true flag. These are exactly the operational traits an agent needs to interpret results and decide to call.

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

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

Front-loads the core definition, then adds GDPR, criminal-case withholding, and cost in descending priority with no filler. The first sentence is dense with a return-field enumeration, but that is justified because no output schema exists to carry it.

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 five parameters, the description discharges the full burden: it describes the summary composition, the per-case fields, masking behavior, criminal-case suppression, billing, and that the summary spans all cases. Nothing material for a correct call or result interpretation 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 schema already explains cui, role, category, limit (including that summary covers all) and since with its default. The description adds no parameter-level meaning beyond that — e.g. it never clarifies role/category value semantics or date-window interaction with the summary — 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 resource (court cases for a Romanian company, keyed by CUI) plus the source registry (portal.just.ro, Ministry of Justice) and enumerates the returned artifacts (summary plus case list). An agent can tell this apart from the single-case sibling get_court_case because the scope is explicitly 'a company by CUI is a party' rather than one case.

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 resource description, and the cost note ('Costs 15 credits; not billed if nothing is found') is genuinely useful for deciding whether to call. However, there is no explicit when-to-use vs. when-not guidance and no mention of siblings like get_court_case or get_company_risk_report that might cover overlapping legal data.

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

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

Adds real behavior beyond the readOnly/idempotent annotations: billing of 3 credits, no charge when nothing is found, output language (English), currency (RON), and the negative=loss sign convention. Missing only things like data lag or empty-result shape, which is minor given the annotations.

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 source and key, then lists fields. The long metric enumeration is informative but slightly list-heavy; the cost caveat at the end is well placed.

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 describing return values and units, and covers billing and sign conventions. It stops short of stating result shape (per-year records vs aggregate) or what happens with no filings, which for a 2-param read tool is a modest 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 are already documented including the CUI example format and the years default/max. The description only echoes 'by CUI' and adds no semantics for the years limit, 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+resource (annual financial statements filed with ANAF) plus the exact key input (CUI) and enumerates the returned metrics, which visually separates it from siblings like get_company_risk_report or lookup_company. An agent can tell what it gets 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?

Usage is implied by 'for a Romanian company (by CUI)' and the cost note, but there is no explicit when-to-use/when-not or named alternative such as get_company_risk_report for risk analysis. The agent must infer routing from sibling names.

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

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuinely useful context beyond them: the ONRC monthly snapshot as data source (implying possible staleness), a 5-credit cost, and the notable billing exception when the CUI is not found. It does not cover invalid-CUI handling or rate limits, but the cost and failure-billing disclosure is high-value.

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

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

A single dense sentence front-loads the resource and source before the field list and pricing. Parenthetical asides (decoded status, role examples) are informative rather than filler, though the sentence is long enough to strain readability.

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 compensates by enumerating returned fields, and it adds source, cost, and failure behavior. For a single-parameter read tool this is close to complete; only input-validation behavior is unstated.

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 with 100% schema description coverage, including an example format (14399840 or RO14399840). The description adds only the 'by CUI' framing, which the schema already conveys; baseline 3 applies when the schema does the work.

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 (trade-register data for a Romanian company by CUI) and enumerates the returned fields — registration number, EUID, legal form, status, CAEN codes, representatives — so the agent knows exactly what this retrieves. It is distinguishable from get_company_financials and get_company_court_cases by its field list, though it never explicitly names a sibling to contrast with.

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 'by CUI' input and the representative-focused field list, but there is no explicit when-to-use or when-not-to-use guidance, and no routing against lookup_company or the other company tools. An agent must infer the choice from the field contents 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description layers on genuinely non-obvious behavior: the one-time 30-credit charge, no charge for unknown CUI, full charge even when sections are missing, an unavailableSections field, and the direction of the 0-100 score (higher = fewer risk signals). These are exactly the economics and partial-failure semantics an agent cannot infer from structured fields.

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

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

Front-loaded with the capability, then the cost/partial-failure rules, then the disclaimer — a logical order with no filler. It is dense and slightly overpacked into one paragraph, but every clause (credits, unbilled unknowns, unavailableSections) carries decision-relevant 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?

No output schema exists, so the description must convey the return shape itself, and it does: the four data sections, the 0-100 score with its direction, explained flags, and the unavailableSections fallback field. Combined with the annotation coverage, 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?

With one parameter at 100% schema description coverage, the schema already documents CUI with examples ('14399840 or RO14399840'). The description only says 'by CUI' and adds no format, normalization, or prefix-handling 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+resource ('one-call due-diligence report for a Romanian company (by CUI)') and enumerates the exact sections returned: ANAF status, 3 years of financials, court cases, ONRC registry data. This clearly positions it as the aggregate report versus granular siblings like get_company_financials and get_company_court_cases.

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 'one-call' framing plus the credit disclosure (30 credits once, included sub-reads not billed again) implicitly tells the agent to prefer this over chaining the individual data tools, and 'Informational only, NOT credit advice' sets a scope boundary. It never names an explicit alternative or when-not-to-use condition, so it stops short of a 5.

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

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

Annotations already declare read-only, idempotent, open-world and non-destructive, so the bar is lower; the description still adds substantial non-obvious behavior: natural persons are masked, criminal cases are heavily truncated with a criminalDetailsWithheld: true flag, and billing is waived on not-found. Those are exactly the surprises an agent needs pre-call.

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 dense sentences, front-loaded with what is returned, followed by the criminal-case caveat and the cost note. No filler and nothing buried.

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-shape burden and does so by enumerating the returned fields (court, subject, stage, parties with roles, hearings with outcomes, appeals) plus the criminal-case exception and billing behavior. An agent knows what it will get and what it will be charged.

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 single parameter is fully described in the schema (100% coverage) with an identical example, so the description adds little beyond restating the format. Baseline 3 applies when the schema already 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?

States a specific verb+resource+scope ('full detail of a Romanian court case by its number'), names the upstream source (portal.just.ro), and the 'by its number' framing implicitly contrasts with the company-based sibling get_company_court_cases. It never names that sibling explicitly, so differentiation is inferable rather than 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?

The description gives practical usage context ('costs 1 credit; not billed if not found') and a case-number example, which helps an agent decide to call it. But it never says when to prefer this over get_company_court_cases or what to do when a lookup fails, so usage is only implied.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, and the description adds meaningful operational facts on top: free (0 credits), keyless calls work but are rate-limited per IP, values are unmodified from the BNR source, and output is informational only. This is exactly the kind of context annotations cannot convey.

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

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

One dense but well-ordered sentence: acronym expansion and unit first, then the returned values, then the history modes, then cost/auth/source caveats. Every clause carries information, though the compressed punctuation makes it slightly harder to scan than it could be.

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 4-param, zero-required, no-output-schema read tool, the description covers what is returned in each mode, the enum semantics, the cost model, keyless rate limits, and provenance. An agent has everything needed to choose a mode and call it correctly without further inference.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely does: it explains that 'date' yields the applicable quarterly value, that 'history' takes the daily or quarterly enum, and that daily history pairs with from/to. Only 'to' is left implicit as the endpoint of the from/to range rather than explicitly defined.

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

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

The description names a specific resource (the IRCC consumer-credit reference index, % p.a.) and spells out exactly what the tool returns: the quarterly value applicable on a date plus the next quarter's value if published, the latest daily value, or a history series. It is clearly distinguishable from siblings like get_robor or get_bnr_exchange_rate by resource, though it never explicitly contrasts itself 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?

It gives concrete mode selection guidance: use 'date' for the point-in-time value, or 'history' with type daily plus from/to, or type quarterly. That is clear operational context, but there is no explicit statement of when *not* to use it or which sibling tool to pick instead.

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 past the readOnly/idempotent/openWorld annotations: discloses a 1-credit cost, the default page size of 50 articles, the offline cache for core codes, and an authenticity caveat that consolidated forms are unofficial and only Monitorul Oficial is authoritative. These are exactly the operational and trust facts an agent needs.

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 return shape, then cost and sourcing caveats at the end. The single dense sentence carrying the field inventory is heavy, but essentially every clause adds decision-relevant 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?

With no output schema, the description carries the return-shape burden itself and does so by listing the fields of both the act header and each article. Combined with cost, paging, and provenance, nothing material is missing for correct invocation.

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

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

Schema coverage is 33%, so the description must compensate and largely does: it names the id as a legislatie.just.ro id sourced from search_legislation, and explains offset/limit as article-level paging with a default of 50. It stops short of noting the limit cap of 200 or offset semantics beyond paging.

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 (fetch current consolidated text of a Romanian act) keyed on a legislatie.just.ro id, and enumerates the returned structure (title, issuer, publication, consolidation date, versions, articles). The parenthetical '(from search_legislation)' anchors it against a sibling, and 'split by article' implicitly separates it from 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?

Explicitly routes the agent to search_legislation to obtain the id and flags that six core codes work offline, which is real selection guidance. It does not explicitly state when to prefer get_legal_article or get_legal_act_history instead, so no true exclusion 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 establish read-only, idempotent, open-world, non-destructive behavior. The description adds meaningful context beyond annotations: the 2-credit cost, no charge when not found, the legislatie.just.ro source, and the caveat that consolidated forms are unofficial while Monitorul Oficial text is authentic.

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 front-loaded with what is returned, then follows with a concrete use case, cost behavior, and source/authenticity caveat. Every sentence contributes useful information with no wasted text.

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 two-parameter read-only lookup with no output schema, the description explains the returned content well: consolidation dates, version ids, amendment dates, what changed, and by which act. It is nearly complete, though it could specify the id format more precisely.

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%, with article already described but id undocumented. The description compensates partially by explaining that id refers to a whole act while article limits the result to one article, but it does not specify the expected id format or further clarify the article parameter.

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

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

The description states a specific resource and scope: consolidation dates with version ids and a dated amendment list for a whole act or one article. It clearly distinguishes this historical lookup from current-text siblings such as get_legal_act and get_legal_article by focusing on amendments and in-force dates.

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

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

It gives a clear use case: 'what was the VAT rule on date X', which tells the agent this is for temporal/version-specific legal questions. It does not explicitly name when not to use it or route to alternatives like get_legal_act, so it stops short of full when/when-not guidance.

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

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

Goes well beyond the readOnly/idempotent annotations: it discloses billing behavior (1 credit, not charged on miss), data provenance (legislatie.just.ro, Ministry of Justice), and a substantive authenticity caveat that consolidated forms are unofficial and only Monitorul Oficial text is authoritative. These are exactly the operational and trust facts an agent can't infer from structured fields.

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

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

A single dense but well-ordered block: what you get first, then format edge cases, then cost and provenance. Every clause carries information, though the run-on pricing/source sentence could be split for scannability.

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

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

With no output schema, the description does the work of explaining return content (paragraph/letter structure, dated amendment notes), which is the key missing piece. It leaves the miss case underspecified — 'not billed if not found' implies an empty/error result but doesn't say what is actually returned.

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 with the same examples ('171282', '293^1'). The description restates the article-number format edge case and adds a semantic hint (VAT rates for art. 291) but contributes no new syntax or constraints, 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 resource at a precise granularity ('one article in its current consolidated form') with a concrete worked example (Codul fiscal 171282 art. 291) and the shape of the payload. It implicitly contrasts with get_legal_act and search_legislation by emphasizing a single article, but never names those siblings, so the differentiation is inferential rather than explicit.

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 through the example and the 'costs 1 credit' note; there is no statement of when to prefer this over get_legal_act (full act) or search_legislation (find the right id/article). An agent must guess its own routing rather than being told.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context: a 1-credit cost, the authoritative source, and the caveat that consolidated forms are unofficial while only Monitorul Oficial text is authentic — a meaningful trust signal for a legal-data tool.

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 scope and window come first, with cost, source and authenticity caveats trailing. Every clause carries information, though the single long sentence is slightly harder to scan than a split structure would be.

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

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

With no output schema, the description compensates by enumerating the act types returned and the source. Cost, window limits and authenticity caveats round out what an agent needs to call and trust the result; only the return shape (fields, pagination) is left implicit.

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

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

Schema coverage is 0% and the single `since` parameter has no schema description, so the description must carry the load — and it does, defining the filter as an in-force date on/after `since`, plus the default (7 days) and maximum (35) window. It does not state the expected date format, which the schema pattern covers but the description does not reinforce.

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 ('Acts newly indexed by legislatie.just.ro') and enumerates the act types returned (laws, ordinances, decisions, orders, court decisions). This clearly separates it from siblings like get_legal_act (single act) and search_legislation (query-based 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?

Gives a clear usage context: a recency window with a default of 7 days and a hard cap of 35, which tells the agent when this tool is appropriate. It does not explicitly name alternatives such as search_legislation for older or keyword-based lookups, so it stops short of full when/when-not guidance.

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

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

Goes well beyond the annotations (which only cover read-only/idempotent/non-destructive) by disclosing cost (0 credits), that calls work without an API key but are rate-limited per IP, data provenance (BNR, values unchanged from source), and the 366-day range ceiling. These are exactly the operational facts an agent cannot infer from structured fields.

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

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

One front-loaded sentence chains resource, units, tenors, query modes and limits without filler. It is dense — semicolon-separated clauses rather than bullets — but every clause carries information an agent needs.

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

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

There is no output schema, and the description does not state the return shape (e.g. date plus ROBOR/ROBID columns, or how a series is ordered), which is the main missing piece for a data-retrieval tool with zero required params. Coverage of range, cost, auth and provenance is otherwise strong.

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

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

Schema coverage is only 25% (only 'tenor' is documented), so the description must compensate, and it largely does: it enumerates the allowed tenors, explains that 'date' yields the latest fixing on/before, that from/to define a series, and that the window is capped at 366 days. It does not clarify whether both ROBOR and ROBID are returned together or how tenor interacts with the single-date mode, leaving a small gap.

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

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

Names the exact resource (ROBOR offered / ROBID bid fixings), units (% p.a.), coverage start (1995-08-01) and the two supported query shapes. It is clearly separable from get_bnr_exchange_rate and get_ircc by subject matter, though it never explicitly contrasts itself with those closely related Romanian-rate siblings.

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

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

Explicitly states the two usage modes and their conditions: a single 'date' returns the latest fixing on or before that date, while 'from'/'to' returns a series for one tenor capped at 366 days. It also flags the free/keyless path, giving the agent enough to choose a call shape, but gives no exclusions or guidance on when another tool (e.g. get_ircc) is preferable.

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

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

The annotations already declare this as a read-only, idempotent, non-destructive, open-world lookup. The description adds useful behavioral context by naming the ANAF public registry as the source, stating that results are in English, and disclosing that BNR EUR/RON data may be included. It does not address error or not-found behavior, but the annotation coverage lowers that burden.

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 a single front-loaded sentence that covers input, source, and returned data without waste. Every clause contributes to understanding what the tool does.

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

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

For a simple two-parameter read-only lookup with full schema coverage and rich annotations, the description is complete enough. Since there is no output schema, it helpfully enumerates the returned fields, and no critical calling information appears 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 both parameters are already documented in the schema. The description reinforces that CUI/CIF may be optionally prefixed with RO and that include_fx relates to the BNR EUR/RON rate, but adds no syntax or edge-case detail beyond the schema.

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

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

The description states a specific verb and resource: look up a Romanian company by CUI/CIF and return ANAF registry data. It clearly enumerates the returned fields, though it does not explicitly distinguish itself from sibling tools such as get_company_financials or get_company_representatives.

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 input format and returned data: use this when you have a Romanian CUI/CIF and need core company registry information. However, it gives no explicit exclusions, prerequisites, or directions to alternatives like check_identifier_format or get_company_financials.

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

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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world, so the safety profile needs no repetition. The description adds real value beyond them by disclosing cost ('Costs 1 credit; not billed on errors'), which an agent cannot infer from structured fields. It stops short of noting size limits (300k chars) or parse-failure behavior, but that is a minor 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?

Front-loaded with the core transformation, then a compact enumeration of extracted fields, then cost. The enumerated field list is long but earns its place because there is no output schema; still, it is a single dense run-on sentence rather than clearly segmented.

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

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

With no output schema, the description compensates by enumerating the returned JSON structure (header, parties, payment, lines, VAT breakdown, totals). Combined with the single well-documented parameter and full annotation coverage, an agent has everything 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 100% and the single 'xml' parameter is documented as UBL 2.1 Invoice or CreditNote (RO e-Factura / CIUS-RO). The description reinforces that accepted document scope (invoice or credit note) and names the authoritative source, adding a little meaning beyond the schema, though not format/syntax guidance.

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), a specific input format (UBL 2.1 e-Factura invoice or credit note XML, CIUS-RO/ANAF SPV) and a specific output (clean English JSON). This clearly separates it from siblings like validate_efactura, generate_efactura, and efactura_to_pdf, which operate on the same artifact type.

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 example '(e.g. downloaded from ANAF SPV)' implies the intended source of input, but there is no explicit statement of when to choose this over validate_efactura or efactura_to_pdf, nor any preconditions (e.g. validate first if unsure). 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: cost of 1 credit, no billing on empty results, ranking behavior (codes/laws before decrees/orders), and an authority caveat about consolidated vs Monitorul Oficial text.

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

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

Dense and front-loaded: purpose and query forms first, then ranking, then return value, then cost and source caveat. Every sentence carries distinct information with no filler.

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

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

No output schema exists, but the description explains what is returned (act ids) and the cost model, plus source authority. The main gap is the undocumented filter parameters (type/year/number/limit), which an agent would need to use the tool fully.

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

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

Schema coverage is only 40%, so the description should compensate more than it does. It richly illustrates the 'q' parameter with citation formats, but says nothing about 'type', 'year', 'number', or 'limit' semantics beyond what the schema already 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 (Finds) and resource (Romanian normative acts on legislatie.just.ro), with concrete citation examples ('Legea 31/1990', 'Codul fiscal'). It clearly distinguishes itself from siblings get_legal_act and get_legal_article by positioning itself as the discovery step that returns act 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?

Explicitly routes the agent downstream: 'Returns act ids for get_legal_act / get_legal_article', which tells the agent this is the entry point before fetching content. It also gives query-form examples, though it doesn't state when NOT to use it (e.g., when you already have an act id).

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/idempotent annotations: discloses the external ANAF dependency, local fallback checks, cost (1 credit, waived if ANAF is unreachable), and the exact response shape (valid boolean plus BR-xx/BR-RO-xx codes with bilingual messages). These are precisely the traits an agent needs before spending credits or relying on an open-world call.

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 rule sets, then validation layers, then return and cost details. No filler, every clause carries operational 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 single-parameter, no-output-schema tool, the description covers what the tool does, what it returns, what it costs, and what external dependency it relies on. Nothing material is missing for correct invocation.

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

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

Only one parameter and schema coverage is 100%, so the schema already documents the xml field including length bounds and accepted document types. The description restates UBL 2.1 invoice/credit note scope without adding format, encoding, or size guidance beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (validates) and resource (UBL 2.1 invoice/credit note against RO e-Factura CIUS-RO rules), and names the rule sets used (XSD + Schematron). Clearly distinct from siblings like parse_efactura or generate_efactura.

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

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

Gives clear context for use (validating an already-built e-Factura XML, no ANAF account required) and implies it is the check step before submission. It does not explicitly name alternatives such as parse_efactura or when not to use it, so it stops short of a 5.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the credit cost model (2 base, +5 for legalRepresentative, +1 for invoice), the billing exemptions (errors, ANAF unreachable), determinism of the confidence score, and the fact that legalRepresentative is never stored. These are exactly the operational facts an agent can't get from annotations.

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 and information-dense, but the sentence "Checked against public sources (ANAF, ONRC) and checksums" repeats the opening claim almost verbatim, and the pay/review warning appears twice ("Use before saving to an ERP or paying" and "Always review before paying"). Trimming would gain readability without losing content.

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

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

No output schema exists, and the description fully covers the return shape: a verdict, the registered value per field, optional invoice arithmetic results, and a deterministic confidence score with pass/review/reject. Combined with the cost and caveat disclosures, an agent has everything needed to call it and interpret results 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?

With schema coverage at only 33% across three nested-parameter top-level keys, the description compensates by naming what each payload area is checked for (CUI, name, registration number, VAT status, company status, address, IBAN, legal representative) and flagging invoice arithmetic checks and the +5 credit cost of legalRepresentative. asOfDate semantics and the invoice sub-fields are left to the schema, keeping this short of a 5.

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

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

Names a specific verb (checks/validates) and a specific resource (extracted Romanian company data) against named authoritative sources (ANAF, ONRC) plus checksums. It also enumerates the returned fields and verdict categories, so an agent can distinguish it from lookup_company (raw lookup) without opening the schema.

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

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

Gives explicit usage context ("Use before saving to an ERP or paying") and explicit exclusions ("Not a KYC/AML check", structurally valid IBAN does not prove ownership, always review before paying). The only gap is that it never names the sibling alternative (e.g. lookup_company) that an agent should use instead when starting from scratch rather than from extracted data.

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