Romanian companies: search, CUI risk verdict and prospect lists from official ONRC, ANAF, MF data.
Scored across 4 tools
Each tool has a clearly distinct purpose: name-based search (cauta_firma), attribute-based prospecting (prospecteaza_firme), risk verification (verifica_firma), and service information (despre_firmoscop). The two list-returning tools are differentiated by input type (name vs. filters) and workflow position, so an agent can easily select the right one.
Three of four tools follow a consistent verb_noun pattern in Romanian (cauta_firma, prospecteaza_firme, verifica_firma) with lowercase and underscores. The outlier is despre_firmoscop, which is a preposition+noun phrase rather than a verb, but this is a minor and conventional exception for an informational tool.
Four tools is a well-scoped set for the server's purpose of company search, prospecting, and risk verification. Each tool earns its place: search, filter, verify, and help. No redundant or missing operations at this count level.
The tool surface covers the core workflows: finding companies by name, filtering by attributes, verifying risk, and explaining the service. However, there is no tool to retrieve a detailed company profile (e.g., address, financials, representatives) directly from a CUI, and the prospect tool intentionally excludes contact data, which may be a minor gap for some lead-gen use cases.
Caută în indexul național (registrul comerțului) după numele firmei și întoarce candidați cu CUI, localitate și stare. Gratuit, nu consumă credite. Folosește CUI-ul rezultat cu verifica_firma.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Numele (sau o parte din numele) firmei — minim 3 caractere. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description adds valuable context beyond annotations: it is free and does not consume credits, and it returns candidate records with CUI, locality, and state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with zero wasted words, front-loading the action and the return fields. The workflow hint for `verifica_firma` follows logically and the credit-free note is kept brief.
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 one-parameter search tool with no output schema and annotations covering safety, the description is complete enough. It explains what is searched, what is returned, the cost model, and the recommended next tool, leaving no critical gap for an agent 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 description coverage is 100%, and the single `query` parameter is fully documented in the schema with type, minimum length, and meaning. The description only restates that it searches by company name and adds no further syntax, format, or matching behavior beyond what the schema already 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 states a specific verb and resource: searching the national trade registry by company name. It also names the return fields (CUI, locality, state) and explicitly routes the agent to the sibling tool `verifica_firma` for the next step, making it clearly distinguishable from 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?
It says to use the resulting CUI with `verifica_firma`, providing explicit workflow guidance and an alternative for the next action. It also states the tool is free and does not consume credits, giving useful context, though it does not explicitly state when not to use this tool vs `prospecteaza_firme`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ce este Firmoscop, cum se interpretează verdictele și cum obții credite. Gratuit, nu consumă credite.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot express — that the call is free and does not consume credits — which matters for a credit-metered product. It does not describe the return format, but the credit/cost disclosure is the salient extra trait 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?
A single sentence that front-loads the covered topics and closes with the cost attribute. Every clause earns its place; there is no filler or repetition of the title.
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 zero-parameter, zero-output informational tool with annotations covering the safety profile, the description is complete enough to invoke correctly. The only minor gap is that it doesn't indicate the nature or language of the returned content, but nothing essential to calling it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema has nothing to document and the baseline of 4 applies. No parameter explanation is needed or expected, and none of the description's content conflicts with the empty 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 names the resource (Firmoscop) and enumerates exactly what the tool returns: what Firmoscop is, how verdicts are interpreted, and how credits are obtained. This is a clear, specific informational purpose that an agent can distinguish from the operational siblings (cauta_firma, verifica_firma, prospecteaza_firme), 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?
Usage is only implied: the 'free, consumes no credits' note signals this is a safe, zero-cost call an agent can make freely, and the content list implies it is for orientation before using the other tools. There is no explicit statement of when to call this versus the sibling tools or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listă de firme românești filtrate după domeniu (cod CAEN, prefix acceptat — „41” = construcții), județ și localitate (diacriticele nu contează), formă juridică (SRL/PFA/SA…), benzi de cifră de afaceri și angajați (min/max), înscriere în e-Factura și intervalul datei de înmatriculare („firme noi”), sortate descrescător după cifra de afaceri. Firme și PFA-uri, fără date de contact/reprezentanți. Costă 1 credit/pagină. Ideal pentru lead-gen / cercetare de piață; folosește CUI-urile cu verifica_firma.
| Name | Required | Description | Default |
|---|---|---|---|
| caen | No | Cod CAEN sau prefix (ex. „4120” sau „41”). | |
| page | No | Pagina (implicit 1). | |
| county | No | Județul (ex. „Cluj”, „București”). | |
| address | No | Text din adresa sediului (stradă sau cod poștal; ONRC abreviază — caută partea distinctivă, ex. „dorobantilor”). | |
| finYear | No | Anul de bilanț pe care se aplică pragurile financiare (implicit: ultimul bilanț al fiecărei firme). | |
| eFactura | No | Doar firme înscrise în RO e-Factura (true) sau doar neînscrise (false). | |
| locality | No | Localitatea (ex. „Cluj-Napoca”; diacriticele nu contează). | |
| legalForm | No | Forma juridică: SRL, SA, PFA, II, IF, AF, PF, SNC… | |
| activeOnly | No | Doar firme active (exclude insolvență/radiere). | |
| maxTurnover | No | Cifra de afaceri maximă (lei) — benzi de mărime. | |
| minTurnover | No | Cifra de afaceri minimă (lei). | |
| localityType | No | Mediul: „urban” (municipii, orașe, sectoarele Bucureștiului) sau „rural” (comune, sate). | |
| maxEmployees | No | Numărul maxim de angajați. | |
| minEmployees | No | Numărul minim de angajați. | |
| registeredAfter | No | Înmatriculate la/după data asta (YYYY-MM-DD) — „firme noi”. | |
| registeredBefore | No | Înmatriculate până la data asta — vechime minimă. | |
| turnoverGrowthPct | No | Evoluția cifrei de afaceri față de anul precedent, în %: pozitiv = creștere minimă (ex. 20), negativ = scădere minimă (ex. −30 pentru prăbușiri). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly=true, destructive=false, openWorld=false), and the description goes beyond them by disclosing a cost constraint ("Costă 1 credit/pagină"), the result-set scope ("Firme și PFA-uri, fără date de contact/reprezentanți") and the default sort order. Those are exactly the operational facts an agent needs and cannot get from the schema.
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 filter inventory, then adds exclusions, cost and routing. Every clause carries information, though the long parenthetical chain makes it harder to scan than a short bulleted 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?
For a 17-parameter, no-output-schema tool with safety annotations, the description covers cost, sorting, result exclusions and cross-tool routing, which is close to sufficient. It does not indicate what identifying fields come back per firm (CUI, name, etc.), which is the main gap given there is no 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?
Schema description coverage is 100%, so the schema already carries the per-parameter semantics and the baseline is 3. The description adds only marginal meaning over it — the "41 = construcții" example and the diacritics-insensitive note both already appear in the property descriptions.
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 — lists Romanian firms filtered by a concretely enumerated set of criteria (CAEN, county, locality, legal form, turnover/employee bands, e-Factura, registration date), so the agent knows exactly what it produces. It does not, however, disambiguate itself from the sibling cauta_firma, leaving the agent to infer the split between bulk prospecting and name lookup.
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 usage context ("Ideal pentru lead-gen / cercetare de piață") and a concrete follow-up route ("folosește CUI-urile cu verifica_firma"), which is real cross-tool guidance. It stops short of stating when NOT to use it or naming cauta_firma as the alternative for single-firm lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verdict de risc comercial (verde/galben/roșu) pentru o firmă românească, construit determinist din surse publice oficiale interogate la sursă: ANAF (TVA, inactivitate), bilanțuri MF, dosare de instanță (insolvențe, litigii ca pârât), BPI. Folosește-l înainte ca utilizatorul să emită facturi cu termen de plată, să semneze contracte sau să dea avansuri. Costă 1 credit. Răspunsul include și un link de raport pentru om.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | Yes | CUI-ul firmei (codul unic de înregistrare), cu sau fără prefixul RO. Firme și PFA-uri. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description adds genuinely new behavior: the deterministic build from named public sources (ANAF, MF balances, court/insolvency, BPI), a 1-credit cost, and a human-readable report link in the response. It does not mention latency, caching, or failure modes, 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?
Three sentences, all front-loaded and load-bearing: purpose and data provenance first, then usage triggers, then cost and output. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still specifies the return shape (color verdict plus report link), the data sources, and the cost. Combined with annotations, an agent has everything needed to call 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 coverage is 100% and the single parameter already documents the optional RO prefix and PFA applicability, so the schema carries the burden. The description adds no format or syntax detail beyond what the schema states, making the baseline 3 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?
The description names a specific output (verdict de risc comercial verde/galben/roșu) for a specific resource (firmă românească), which no sibling (cauta_firma, prospecteaza_firme) produces. An agent can distinguish this risk-scoring tool from company search/prospecting siblings 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 gives concrete trigger conditions: use before the user issues invoices with payment terms, signs contracts, or pays advances. There are no explicit exclusions or named alternatives, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cauta_firmadespre_firmoscopprospecteaza_firmeverifica_firmaRomanian companies: ONRC registry, ANAF financials, VAT, EU/UN/US sanctions, administrator links.
Romanian company register: identity, filed financials, procurement, court records by name or CUI.
Read-only data on 3.9M Romanian companies: search, profiles, financials, status, CAEN.
Romanian company data (ONRC/ANAF): CUI lookup, KYB risk, financials. Pay per call via x402 USDC.
Add one secure layer between your agents and this server.
