MCP server for Romanian public data. Lets Claude (or any MCP client) check a company at ANAF, read its financial statements, find its court cases, get BNR exchange rates, validate IBANs, and put all of it together to tell you if an online shop looks like a scam. No API keys, everything comes from official public sources.
Pe scurt: verifici o firmă după CUI (activă, radiată, inactivă fiscal, plătitoare de TVA), îi vezi bilanțurile, dosarele din instanță și cursul BNR, direct din Claude. Și îl poți întreba „e țeapă magazinul ăsta?”.
tool | what it does | source |
| is this online shop legit? reads the CUI off the site, checks the company, its financials, insolvency cases and how old the site is, returns red flags / warnings / good signs | everything below + Wayback Machine |
| status of up to 500 companies by CUI: name, address, Reg. Com. number, CAEN, deregistered, VAT registered, VAT on collection, split VAT, fiscally inactive, e-Factura registry. optionally as of a past date | ANAF |
| filed balance sheets year by year: revenue, profit/loss, employees, debts, equity, cash | ANAF |
| cases in every Romanian court by party name or case number: stage, parties and roles, latest outcome, next hearing, insolvency as debtor | Portal Just |
| BNR reference rate for any day since 2005, with conversion | BNR |
| is an IBAN well formed, which Romanian bank issued it, is it a Treasury account | offline |
Related MCP server: ENTIA Entity Verification
Needs Python 3.10+.
pip install romania-mcp-serveror if you use uv you don't need to install anything, just point the client at uvx (see below).
Add this to claude_desktop_config.json:
{
"mcpServers": {
"romania": {
"command": "uvx",
"args": ["romania-mcp-server"]
}
}
}If you installed with pip, "command": "romania-mcp-server" with no args works too.
claude mcp add romania -- uvx romania-mcp-serverCursor, Windsurf etc. take the same JSON as Claude Desktop.
"e țeapă magazinul ăsta? https://..."
"here are my 40 suppliers' CUIs, which ones are fiscally inactive or deregistered?"
"was RO18547290 VAT registered on 15.03.2016?"
"how did 14399840 do in the last 5 years? revenue, profit, employees"
"does Foo Trade SRL have any insolvency cases? when's the next hearing?"
"cât fac 2.450 EUR în lei la cursul BNR din 14 martie 2025?"
"is this IBAN right? RO49 AAAA 1B31 0075 9384 0000"
shop_check decidesIt's a list of signals, not a verdict from above:
red flags (risk = high): no CUI anywhere on the site, CUI unknown to ANAF, company deregistered or fiscally inactive, company is the debtor in an insolvency case
warnings (two or more = medium): company or site younger than a few months, never archived by the Wayback Machine, no financial statements, zero revenue or employees, negative equity, no ANPC link, the company name ANAF returns never appears on the site (scam shops sometimes copy a real company's CUI)
good signs: company and site have been around for years, real revenue and employees, ANPC links present
It can't see reviews, delivery times or whether the products exist, so a "low" doesn't mean the shop is good, just that the company behind it checks out.
Responses are cached in sqlite at ~/.cache/romania-mcp/cache.sqlite3 so ANAF and friends don't get asked the same thing twice: company status 6h, financials 24h, court cases 3h, current exchange rates 1h, past years' rates 30 days.
ROMANIA_MCP_CACHE=off # disable
ROMANIA_MCP_CACHE_PATH=/tmp/x.dbANAF only searches by CUI, not by company name. Name search would need the ONRC dataset, maybe later.
ANAF asks for at most one request per second. The server spaces requests out, so 500 CUIs take about 5 seconds and 5 years of financials about 5.
Financial statements for a year are filed by mid next year, and some companies only have data from around 2020 on.
Portal Just's API only answers over plain http (their https is broken), and caps a search at 1000 cases.
.ro domains have no public RDAP and ROTLD's whois terms forbid automated queries, so for .ro shops the site age comes from the Wayback Machine only.
iban_check knows the main Romanian banks. A valid IBAN doesn't prove who owns the account.
git clone https://github.com/robyroro/romania-mcp
cd romania-mcp
pip install -e . pytest
pytestTests don't hit the network, HTTP calls are mocked.
To poke at it with the MCP inspector:
npx @modelcontextprotocol/inspector romania-mcpAll of this is public data, but court records name real people. Use it to vet companies you do business with, not to dig into individuals.
MIT © Robert Vind-Gardoș (@robyroro)
Financial statements a Romanian company filed with ANAF, year by year: revenue (cifra de afaceri), total income and expenses, net profit or loss (net_result), average employees, debts, equity, cash, receivables, inventory and fixed assets. Amounts are in RON. Years with nothing filed are marked filed=false.
Use it to see if a company is real and how it's doing: a shop with zero revenue and no employees, or with negative equity, is worth a closer look. Banks and insurers file a different layout, their lines come through under 'other'. Data starts around 2020 for some companies. Takes about a second per year. Cached for 24h.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | Yes | Company fiscal code (CUI / CIF), with or without the RO prefix, e.g. "14399840" or "RO14399840". | |
| years | No | How many years to fetch, counting back from last year. Statements for a year are filed by mid next year, so the most recent one can still be missing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, openWorld, non-destructive), it discloses currency (RON), the filed=false convention, that banks/insurers use a different layout surfaced under 'other', the ~2020 data horizon, ~1s per year latency, and 24h caching. That is unusually complete behavioral context.
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 contents, then caveats and performance notes in short sentences. It is slightly long, but each sentence (currency, field list, layout exception, latency, caching) carries distinct 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 compensates by enumerating returned fields, the currency, and the filed=false marker, and it flags layout exceptions. An agent has everything needed to call and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the data horizon around 2020 and the caveat that the most recent year may be missing. The 'years' semantics are largely already in the schema, so it lands above baseline without being fully additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It states a specific resource (Romanian company financial statements filed with ANAF) and enumerates the actual line items returned (revenue, net result, employees, debts, equity, etc.). This is clearly distinguishable from company_lookup, court_cases, exchange_rate and shop_check.
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 explicit usage context ('use it to see if a company is real and how it's doing') plus interpretation heuristics (zero revenue, no employees, negative equity). It doesn't name sibling alternatives for the basic-identity case, 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.
Official status of Romanian companies from ANAF's public registry: name, address, registration number (J...), CAEN code, registration date, whether it's deregistered (radiată), VAT registered (and since when), VAT on collection, split VAT, declared fiscally inactive, and in the RO e-Factura registry. Each company comes with a 'warnings' list (deregistered, fiscally inactive, suspended).
Use it to vet suppliers or clients, e.g. checking a list of suppliers for fiscally inactive ones, since buyers generally can't deduct expenses or VAT on their invoices. Only searches by CUI, not by name. CUIs with a wrong control digit are returned under 'invalid' without asking ANAF. ANAF allows about one request per second, so every 100 CUIs take a second. Cached for 6h.
| Name | Required | Description | Default |
|---|---|---|---|
| cuis | Yes | One or more CUIs, with or without RO, e.g. ["14399840", "RO18547290"]. Up to 500 in one call. | |
| date | No | Check the status as it was on this day (YYYY-MM-DD or DD.MM.YYYY), e.g. an invoice date to see if the supplier was VAT registered then. Defaults to today. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantial non-obvious behavior: ~1 request/second rate limit with the practical '100 CUIs take a second' translation, 6h caching, local control-digit validation returning invalid CUIs without hitting ANAF, and the semantics of the warnings list.
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 highest-value information (what registry, what fields) then moves to usage, constraints, and rate limits. The returned-field enumeration is long but each item earns its place since there is no output schema. Minor density cost.
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 return fields and warning values, plus rate limits, caching, and edge-case handling — everything an agent needs to call this correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the CUI-only restriction (no name search) and the purpose of the date parameter (e.g. an invoice date to see whether the supplier was VAT registered then). It stops short of explaining the invalid-CUI return shape.
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 — official status of Romanian companies from ANAF's public registry — and enumerates exactly what is returned (name, address, J number, CAEN, VAT status, warnings). This is clearly distinguishable from sibling company_financials, court_cases, or iban_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete use case (vetting suppliers/clients, e.g. screening a supplier list for fiscally inactive companies) with the business rationale. It also states a hard constraint: only searches by CUI, not by name. It does not explicitly name sibling alternatives for other lookup styles, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Court cases from Portal Just, the public portal of every Romanian court: case number, court, category (civil, criminal, insolvency...), stage, subject, parties and their roles, latest outcome and next hearing. For a party it also counts its roles (defendant, creditor...) and lists insolvency cases where it's the debtor, the strongest red flag for a company.
Prefer cui for companies: the portal has no fiscal codes, so a name search also returns other companies with similar names. A big company being creditor or plaintiff in many cases is normal, look at the roles. Portal Just caps a search at 1000 cases. Usually answers in 1-5s. Cached for 3h.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | No | A company's CUI. Its exact name and county come from ANAF, so only that company's cases are kept and insolvency is checked at the right court. Best for companies. | |
| court | No | Only cases at this court, e.g. "Tribunalul Cluj" or "Judecatoria Sectorul 4". Ambiguous names return an error listing the matching courts. | |
| limit | No | How many cases to return in detail, most recently updated first. Counts cover all of them. | |
| party | No | Name of a party to search for, e.g. "Dante International". "SC" and the legal form (SRL, SA) are dropped so different spellings match. Diacritics don't matter. | |
| since | No | Only cases registered on or after this day (YYYY-MM-DD or DD.MM.YYYY). | |
| case_number | No | Case number, e.g. "17902/3/2023". Use instead of or together with party. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and open-world behavior, but the description adds operational traits those don't cover: a 1000-case search cap, typical 1-5s latency, and 3h caching. It also explains the noise profile of name searches and why names may mismatch, which materially affects how an agent interprets results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the returned data set before moving to usage advice and operational notes, and every sentence carries information (cui preference, role interpretation, cap, latency, caching). It is dense and slightly longer than minimal, but no sentence is 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?
There is no output schema, so the description carries the burden of describing returns — it lists the fields, the party role counts, and the insolvency-debtor listing. Combined with the 100%-documented parameter schema and the operational notes (cap, cache, latency), an agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all six parameters in detail (cui, court, limit, party, since, case_number). The description adds selection meaning beyond the schema by explaining why cui is preferred over party and how to read party roles, which is genuine guidance rather than repetition.
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 (court cases from Portal Just, the Romanian courts portal) and enumerates what each record contains — case number, court, category, stage, subject, parties/roles, outcome, next hearing. It also scopes the tool's special behavior (role counting and insolvency-as-debtor detection), so an agent knows exactly what this tool returns without opening a schema. No sibling covers court data, so no differentiation gap exists.
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 an explicit routing preference ("Prefer cui for companies") with the reason (portal has no fiscal codes, so name searches return similar-named companies), and interpretive guidance ("A big company being creditor or plaintiff in many cases is normal, look at the roles"). It does not say when to reach for this tool rather than company_lookup or company_financials, so it stops short of full alternative-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official National Bank of Romania (BNR) reference rate: how many RON one unit of a currency is worth on a day, and optionally an amount converted to RON. rate_date is the day of the fixing that was used.
BNR publishes once per working day around 13:00. For a VAT invoice in foreign currency the usual rule is the last rate published before the invoice date, so ask for the day before. Cached for 1h (past years for 30 days).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Day to get the rate for (YYYY-MM-DD or DD.MM.YYYY), from 2005 on. Weekends and holidays give the last rate before. Defaults to the latest rate. | |
| amount | No | Amount in that currency to convert to RON, e.g. 1500 for 1500 EUR. | |
| currency | No | ISO code like "EUR", "USD", "GBP", or "ALL" for every currency BNR publishes. | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly/openWorld/idempotent, and the description adds traits they do not cover: BNR publishes once per working day around 13:00, results are cached for 1h (past years for 30 days), and weekends/holidays resolve to the last prior rate. Timing, staleness, and fallback behavior are exactly the non-obvious 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?
The core definition is front-loaded in the first sentence, followed by publication timing and the practical invoice rule. Four compact sentences with no redundancy, though the caching/parenthetical detail is slightly dense for its position.
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 the result means (RON per unit of currency, optionally an converted amount) and which day the fixing came from, plus freshness and holiday behavior. An agent has everything needed to call it and interpret the response.
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 date formats, the 'ALL' currency sentinel, and the amount semantics; baseline is 3. The description's only addition, 'rate_date is the day of the fixing that was used', concerns a return field rather than clarifying a parameter 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+resource: returning the official BNR reference rate for a currency on a given day, plus optional conversion to RON. It also defines the domain term 'rate_date' and would not be confused with any sibling (court_cases, iban_check, shop_check, company_financials, company_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?
It gives concrete conditional guidance: for a VAT invoice in foreign currency, the usual rule is the last rate published before the invoice date, 'so ask for the day before'. This is real when-to-use context rather than restatement. It stops short of naming explicit exclusions or alternatives (none of the siblings overlap, so the cost is low).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that an IBAN is well formed (length and mod-97 check digits, catches typos) and, for Romanian IBANs, which bank issued it and whether it's a State Treasury account. Works for any country's IBAN, offline, nothing is sent anywhere.
A valid IBAN only means the number is well formed: it doesn't prove the account exists or who owns it. Use company_lookup to check the company you're paying.
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | IBAN to check, spaces allowed, e.g. "RO49 AAAA 1B31 0075 9384 0000". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, but the description adds genuinely new context: the check is fully offline with nothing transmitted, and it discloses the semantics of a 'valid' result as only well-formedness, not account existence. That is meaningful beyond the annotations. Only minor gap: it doesn't say what is returned for an invalid IBAN (error vs. negative result), and 'offline' sits slightly awkwardly against openWorldHint=true, though that is a data-locality statement rather than a read/write contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight paragraphs with no filler: the validation scope comes first, then the enrichment, then the caveat and the routing hint. Every sentence 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 compensates by describing what a result contains (well-formedness plus, for Romanian IBANs, issuing bank and State Treasury status) and the limits of that result. The only omission is the shape of a failure response (error vs. invalid flag), which a caller would benefit from knowing.
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 required parameter and 100% schema description coverage including a concrete spaced-IBAN example, the schema fully documents the argument. The description explains what 'check' means (length + mod-97) but adds no syntax, format, or edge-case detail about the iban field itself, 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 and resource ('check that an IBAN is well formed') plus the exact validation methods (length, mod-97 check digits) and the extra Romanian-bank/Treasury enrichment. It also explicitly differentiates itself from the sibling company_lookup, so an agent can route 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 when the tool applies (any country's IBAN, offline), when it is insufficient ('a valid IBAN only means the number is well formed: it doesn't prove the account exists or who owns it'), and names the alternative to use for that gap (company_lookup). When-to-use, when-not, and the alternative are all explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is an online shop legit? Reads the CUI off the site (homepage, then terms / contact pages), then checks the company at ANAF, its last two years of financials, insolvency and other cases on Portal Just, and how long the site has been online (Wayback Machine). Returns a risk level (high / medium / low / unknown) with red_flags, warnings and good_signs, plus all the data behind them.
Use this first for "e țeapă?" questions, then the other tools to dig deeper. The result is signals, not proof: a scam can copy a real company's CUI, which is why it checks that the company name appears on the site. Fetches a few pages of the shop like a browser would. Takes 5-20s.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | No | The company's CUI, if you already know it or the site hides it from bots. | |
| url | Yes | The shop's address, e.g. "https://example.ro" or just "example.ro". |
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 correctly focuses on what they don't say: it fetches several pages like a browser, takes 5-20s, and returns signals rather than proof, including the specific caveat about CUI copying. The remaining gap is minor since annotations carry the read-only story and no output schema is promised.
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 question, then the data sources, then the output, then the routing and caveats. Dense but every sentence carries operational content; nothing is restated 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 must describe returns and does: a risk level (high/medium/low/unknown) with red_flags, warnings, good_signs, plus the underlying data. The latency and evidence-limitation caveats round out what an agent needs before calling it.
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 both parameters are documented in the schema itself, so the baseline is 3. The description mentions reading the CUI off the site, which loosely motivates the optional cui parameter, but adds no syntax or fallback detail the schema lacks.
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 question it answers ('Is an online shop legit?') plus the concrete resources it consults (ANAF, Portal Just, Wayback Machine) and the verdict shape it returns. Clearly distinguishable from siblings like company_lookup and court_cases, which cover single facets of the same investigation.
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: 'Use this first for "e țeapă?" questions, then the other tools to dig deeper.' This gives both the trigger condition and the ordering relative to the sibling tools, leaving nothing to inference.
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.
v0.1.0company_financialscompany_lookupcourt_casesexchange_rateiban_checkshop_checkScored across 6 tools
Each tool targets a distinct domain object: company_financials (filings), company_lookup (registry status), court_cases (litigation), exchange_rate (FX), iban_check (bank validation), and shop_check (composite first-pass). company_financials vs company_lookup could be blurred but the descriptions clearly separate financials from registry/VAT status, and shop_check is explicitly positioned as a wrapper over the others.
All names are consistently snake_case with a domain_entity or verb_noun shape, which reads predictably. There is slight variation between noun_noun (court_cases, exchange_rate) and verb_noun (company_lookup, shop_check, iban_check), but the convention is readable and uniform.
Six tools is well-scoped for a Romanian company-vetting server, with each tool earning a clear place. No redundancy or filler: the composite shop_check and the granular primitives complement rather than duplicate each other.
The surface covers the core vetting lifecycle: identity/status, financials, litigation, FX for invoices, IBAN sanity, and an aggregate risk check. The notable gap is that company_lookup only accepts CUI, so name-based discovery is a dead end (though this is a real ANAF constraint, not a design omission).
Romanian business-registry lookup, director search, contact extraction, and WHOIS/DNS audit.
Romanian company risk checks by CUI — verdict verde/galben/roșu from official public sources.
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.
