date-firme

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 non-obvious behavior: pay-per-call pricing ($0.01 via x402/USDC on Base, no account needed), newest-first ordering, RON currency, and the empty-list case when no filings exist. Return detail is left to the output schema, which exists.

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

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

Two sentences, front-loaded with cost and an explicit use-case trigger, followed by the field inventory. Dense but every clause carries information; the long field enumeration risks being a read-out of the output schema, though it does usefully signal scope.

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 paid, single-parameter, read-only lookup with a documented output schema, the description covers cost and payment mechanics, trigger condition, unit/currency, ordering, and the empty-result case. Nothing an agent needs to call it correctly is missing.

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

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

Single parameter with 100% schema coverage, and the schema description already explains the CUI/CIF format and the RO-prefix variant. The description adds only the 'per year, newest first' framing, which is about output ordering rather than parameter meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific resource (Romanian company financial statements / bilanț ANAF), keyed by CUI and broken out per year, and enumerates the actual fields returned (turnover, profit, employees, debts, equity, Altman Z', ratios). An agent can distinguish it from romania_company_full_report or romania_company_risk_kyb without opening a schema.

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

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

Gives an explicit trigger condition ('Use when you need revenue, profit, debt or headcount trends or a solvency view over several years') and routes the agent to romania_company_search for obtaining the CUI. It does not explicitly say when to prefer this over sibling tools like romania_company_full_report or risk_kyb, so it stops short of full when-not guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely new behavioral context: per-call pricing ($0.03), the payment mechanism (x402, USDC on Base, no account required), and a breakdown of what the response contains. It stops short of stating failure modes or latency/rate behavior, so it is not a full 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-loads the cost and payment model, then the usage condition, then the content breakdown — a sensible ordering with no filler. It is densely packed into long clauses, which slightly hurts scannability but every sentence carries 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, paid, read-only endpoint with an output schema present, the description supplies everything the agent needs: cost, when to choose it, what sections it returns, and a sibling-relative value claim. Return-value details are correctly left to the output schema.

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 with 100% schema description coverage, and the schema already documents the format (digits with optional RO prefix) and how to obtain the value via romania_company_search. The description adds nothing about cui 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 and resource ('Romanian company full due-diligence report by CUI') and explicitly positions it as the aggregate of three sibling capabilities (profile, financials, KYB risk). An agent can immediately distinguish it from romania_company_profile, romania_company_financials, and romania_company_risk_kyb 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 concrete triggering scenarios (onboarding, credit, M&A screening) and names the alternative it replaces: 'would otherwise call profile, financials and risk'. The 'cheaper than three' note adds an explicit cost-based selection rule, so the routing decision is fully specified.

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 establish read-only, idempotent, non-destructive, open-world behavior, and the description adds substantial operational context beyond that: per-row pricing with a call minimum, x402/USDC payment mechanics with no account, 402 sample-row and match-count behavior, sort order, and an explicit exclusion of personal contact data. This is well beyond what the annotations provide.

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 paragraph is dense but front-loads pricing and the usage condition before data-source and row details. Every sentence carries useful information, though the prose is less scannable than a labeled 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?

An output schema exists and all 13 parameters are fully documented, so the description only needs to add behavioral and usage context. It covers price, payment flow, data provenance, filter scope, row fields, and privacy limits, which is sufficient for correct invocation. No material gap remains.

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

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

Schema description coverage is 100%, so the schema already documents each of the 13 parameters, including examples and the caen-or-judet requirement. The description echoes the filter categories (CAEN, county, city, turnover, employees, net profit, founding year) and sort order but adds no syntax, defaults, or format details beyond the schema. 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?

The description names the specific resource (Romanian companies) and the operation (filtered lead/prospect list) and lists supported filters, so an agent knows this is a list-building tool rather than a single-company lookup. It does not explicitly name or contrast with siblings such as romania_company_search or romania_company_profile, leaving the boundary to inference.

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 clear use cases (sales prospecting, market sizing, supplier sourcing) and a condition ('Use when you need a list of Romanian companies matching criteria'). However, it gives no exclusions or alternatives among the seven sibling tools, so the agent must infer when a different tool 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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description goes beyond them by disclosing the pricing model and access method ('$0.005 per call (x402, USDC on Base, no account)'), which is material for calling the tool at all. It does not add rate limits or error/edge behavior, keeping it short of a 5.

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

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

Front-loads cost, then the when-to-use clause, then the returned-field inventory in a single tight paragraph with no filler. The field list is dense but each item is a distinct queryable attribute, so little text is wasted.

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 an output schema present, return values need not be explained, and the description correctly covers cost, input source, and scope for a read-only lookup. The only gap is sibling routing, since it never says how this profile differs from the full-report or KYB variants.

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 the schema description already covers it fully at 100% coverage, including the CUI format and the pointer to romania_company_search. The description only echoes the identifier ('by CUI/CIF') without adding format or validation detail, so the baseline 3 for schema-carried semantics is correct.

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 ('Romanian company profile and VAT check by CUI/CIF') and enumerates the exact fields returned: legal name, ONRC status, legal form, CAEN, ANAF VAT payer flags, administrators. It clearly differs from a search tool, but does not distinguish itself from near-siblings such as romania_company_full_report or romania_company_risk_kyb, which likely overlap.

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?

'Use when you need invoicing data, VAT status, legal form or who runs a known Romanian company' gives clear activation context and implies the company must be known (CUI in hand). However, it names no exclusions or alternatives among the seven siblings, so an agent cannot tell why to pick this over romania_company_full_report.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description only needs to add context — and it does, disclosing the pricing/payment model ($0.02 per call, x402 USDC on Base, no account) and the shape of the risk output. It stops short of stating rate limits or error behavior, but that is a minor omission against strong 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 with cost and usage triggers, then the CUI prerequisite, then the output contents — a sensible priority order. The final risk-enumeration sentence is dense and long, but every clause names a genuinely distinct risk category rather than padding.

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

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

For a single-parameter read tool with full annotations and an output schema, the description supplies everything an agent needs: cost, when to call it, the prerequisite tool, and a preview of the returned risk dimensions. Nothing material is left to inference.

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

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

Schema description coverage is 100% and the single required parameter 'cui' is fully documented in the schema, including the RO-prefix format example. The description adds only the acquisition hint (get it via romania_company_search), so the baseline 3 applies — the schema is doing the semantic 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 verb+resource ('KYB ... for a Romanian company by CUI') and enumerates exactly what is checked: ONRC insolvency, ANAF status, balance-sheet red flags, Altman Z'. This clearly separates it from sibling tools like romania_company_financials or romania_company_profile, which do not produce a composite 0-100 risk score with reasons.

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 trigger conditions ('onboarding a supplier/customer, extending credit or before paying an invoice') and a prerequisite workflow ('Get the CUI with romania_company_search'). It does not, however, say when to prefer this over romania_company_full_report, which likely overlaps on risk content.

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 annotations: pricing ($0.002/call via x402 USDC on Base, no account), a free tier of 3 calls per IP per UTC day with the MCP/HTTP flag distinction, and result-set behavior (up to 30 matches, active companies sorted first). Those are exactly the operational facts an agent needs and cannot get from readOnlyHint/idempotentHint.

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 with no filler, and the free-tier detail is actionable. It loses a point only for front-loading pricing/access before the actual purpose, so the core identity is in the second sentence rather than the 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?

For a read-only lookup with a 100%-covered one-param schema and an output schema present, nothing essential is missing. It even over-delivers by summarizing the returned fields and ordering, which the output schema would not tell the agent about ranking.

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 param, so the schema already documents the accepted formats, the RO-prefix optionality and the J40/123/2020 example. The description restates the same facts without adding syntax, normalization or matching behavior beyond them; 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 ('Romanian company lookup / search in the Romania trade register (ONRC)') and enumerates the accepted key types (nume, CUI/CIF, J-number). It also distinguishes itself from siblings by naming the downstream use ('need its CUI for the other tools'), so an agent can place it relative to romania_company_profile or romania_company_risk_kyb.

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 an explicit trigger: 'Use when you have a Romanian company name and need its CUI... or to verify a CUI exists.' That is a clear when-to-use, but it never states when not to use it or names a sibling alternative for cases where a full profile/financials is actually wanted.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description concentrates on what they cannot express: the paid access model ('$0.01 per call (x402, USDC on Base, no account)') and the fact that ranking is computed from the latest balance sheet. It omits pagination or coverage caveats, but the payment/no-account detail is genuinely additive context an agent must know before calling.

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

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

A single dense paragraph that front-loads cost, then usage, then behavior and return content. No filler sentences, though the pricing clause leads ahead of the actual purpose, which delays the primary framing slightly.

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 an output schema present, return values need not be spelled out, yet the description still summarizes the shape (top N, total with data, rank). Between annotations, full schema coverage and the output schema, an agent has everything needed to invoke this 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 description coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema: it clarifies that the cui rank (rang_ref) is only reported 'if cui is given and in the top N,' which the schema's simpler 'rank within the list' does not convey. It also ties the code to a NACE-based activity code sourced from romania_company_profile.cod_caen.

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: 'ranks active Romanian companies with a given main CAEN code ... by turnover ... from their latest balance sheet.' The delimiting scope (by CAEN code, ranked by turnover) clearly separates it from siblings like romania_company_profile and romania_company_financials, which operate on a single company rather than an industry cohort.

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?

'Use when you need market leaders or competitors in a Romanian industry, or to place a company against its peers' gives a concrete triggering scenario. It does not, however, name an alternative tool or state when-not-to-use (e.g. for a single company's own financials use romania_company_financials), so routing is implied rather than explicit.

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

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

Adds substantial context beyond the annotations: cost and payment mechanism ($0.01 per call, x402 USDC on Base, no account), a result cap (up to 200), matching semantics (exact full-name match, case- and diacritics-insensitive), and the scope limit that only *current* registrations are returned. Annotations cover safety/idempotency; the description covers everything else.

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 pricing and the use case, then scope, then return fields — a sensible order with no filler sentences. It loses a point for repeating the same motivation twice ('related parties... due diligence on a director' followed by 'related parties, director due diligence').

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

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

For a single-parameter read-only lookup, the description covers cost, scope, matching behavior, result cap, and the returned fields, while an output schema exists to carry the return-value detail. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and the schema already documents the min-3-char and URL-encoding requirements, so the baseline is 3. The description adds genuinely new meaning on top: the match is exact against the full registered name and is case- and diacritics-insensitive.

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: Romanian companies where a specific person is currently registered as administrator or legal representative in ONRC, with a stated cap of 200. This person-keyed reverse lookup is clearly distinguishable from all company-keyed siblings (company_profile, company_financials, company_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?

Explicit when-to-use framing: 'Use when you need a person's other Romanian business affiliations: related parties, conflicts of interest or due diligence on a director.' It names the triggering scenarios but does not name an alternative tool or state any exclusion, 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.