Leadgen ONRC Romania
Server Details
Romanian company data for agents: 4.2M ONRC firms, ANAF status, financials 2008–2025. Free key.
- Status
- Healthy
- Uptime
- 99.3% over 43 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Server Listing
- Leadgen MCP
TDQS
Scored across 17 tools
The lookup_* family is large but each tool targets a distinct resource (business, category, director, domain, batch, financials). The main overlap is enrich_company versus lookup_business + extract_contacts, which the description explicitly resolves; a few adjacent pairs like lookup_domain/find_company_by_domain and lookup_financials/lookup_financial_ratios could momentarily confuse, but their descriptions distinguish them.
Names are overwhelmingly snake_case and grouped into clear families (lookup_*, watch_*). Minor deviations such as lookup_by_category, find_company_by_domain, and the bare unwatch keep it from perfect uniformity, but the convention remains predictable.
17 tools is slightly above the typical 3-15 sweet spot, but each maps to a real capability: single and batch lookup, matching, enrichment, domain profiling, financials, watches, usage, and feedback. There is no obvious filler, so the count is reasonable rather than bloated.
The surface covers the core leadgen lifecycle: discovery, enrichment, financials, domain profiles, batch matching, watch/poll/unwatch, usage, and issue reporting. Minor gaps remain (no explicit list_watchlist tool separate from poll, no batch enrichment or contact extraction), but agents can work around them.
Available Tools
17 toolsenrich_companyCompany profile with website contactsARead-onlyIdempotentInspect
A whole-firm profile in one call: the ONRC registry record plus the contacts discovered on that firm's website, each labelled with a confidence and a source. Prefer this over lookup_business followed by extract_contacts when you want everything about one company. cui is its tax code; website overrides the registered one; max_pages bounds the crawl; refresh=true crawls now instead of answering from the cache.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | Yes | Romanian tax identification number (CUI), e.g. '2816464'; 'RO' and leading zeros are accepted. | |
| refresh | No | true crawls now even if a cached result exists (default false: answer from the cache when there is one). | |
| website | No | Optional website override (domain or URL). When omitted, the firm's registered website is used (an error if none is on file). | |
| max_pages | No | Maximum number of pages to crawl (1-20, default 5). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cui | No | The firm's CUI. |
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| company | No | A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address (a sole trader's PFA/II/IF locality only in an answer listing several firms, with addressScope: locality), county, city, website, phone (+ phoneSource: ANAF, declared by the taxpayer), caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url). |
| crawled | No | true when the site was crawled for this answer. |
| message | No | A sentence for the caller. |
| website | No | The website crawled. |
| cacheHit | No | true when answered from the cache. |
| contacts | No | Contacts found, each with type, value, confidence and source; an email also has personal (true for a firstname.lastname@ address: GDPR art. 14 and Law 506/2004 apply), role addresses first. |
| crawlError | No | Why the crawl failed, if it did. |
| pagesCrawled | No | Pages read. |
| websiteSource | No | Where the website came from: registry or override. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world and non-destructive behavior. The description adds useful context beyond them: cache-vs-live semantics for refresh, the error case when no registered website exists and no override is given, and that contacts come back with confidence and source labels. The cache and website details are also present in the schema descriptions, so the incremental value is modest.
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 tightly packed sentences, front-loaded with the value proposition, then the routing rule, then parameter semantics. Every clause carries information; 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?
An output schema exists so return-value detail is unnecessary. The description covers purpose, alternative routing, cost/behavior trade-offs (cache vs crawl), and the fallback error path, leaving no gap for an agent 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%, so the baseline is 3, but the description adds interpretive meaning: cui is the tax code, website overrides the registered one, max_pages bounds the crawl, refresh forces a live crawl. That clarifies intent beyond the field-level docs.
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: a whole-firm profile combining the ONRC registry record with website-discovered contacts, each labelled with confidence and source. It explicitly distinguishes itself from lookup_business and extract_contacts, so an agent can route correctly without opening schemas.
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?
"Prefer this over lookup_business followed by extract_contacts when you want everything about one company" names the alternative tools and the condition that selects this one. No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_contactsExtract contacts from a websiteARead-onlyIdempotentInspect
Crawl a company website and extract emails, phone numbers and social profiles. Accepts a bare domain or a full URL; max_pages (1-20, default 5) bounds the crawl.
| Name | Required | Description | Default |
|---|---|---|---|
| website | Yes | The website to crawl: a bare domain ('example.com') or a full URL ('https://example.com'). | |
| max_pages | No | Maximum number of pages to crawl (1-20, default 5). |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | No | The start URL crawled. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| domain | No | The site's registrable domain. |
| emails | No | Addresses on the site's own domain. |
| github | No | GitHub profile. |
| phones | No | Phone numbers found. |
| message | No | A sentence for the caller. |
| No | X / Twitter profile. | |
| youtube | No | YouTube channel. |
| No | Facebook profile. | |
| No | LinkedIn page. | |
| No | Instagram profile. | |
| otherEmails | No | Other addresses found on the site. |
| socialLinks | No | Every social link found, best first. |
| pagesCrawled | No | Pages read. |
| personalEmails | No | Addresses shaped like a person's (firstname.lastname@): personal data, so GDPR art. 14 and Law 506/2004 apply. Role addresses (office@) rank first. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description's remaining behavioral contribution is the crawl-bound statement (max_pages 1-20, default 5), which largely duplicates the schema. It says nothing about runtime, throttling, or what happens on a large or unreachable site, so it adds only modest context beyond 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?
Two sentences with no filler: the capability statement comes first, then the input/crawl-bound note. Every clause earns its place and nothing is 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 an output schema present, the description need not explain return values, and annotations carry the safety profile. Combined with a fully documented two-parameter schema, the definition is nearly complete; only the absence of any sibling routing (enrich_company, lookup_domain) leaves a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters already carry format and range details in the schema ('bare domain' vs 'full URL', '1-20, default 5'). The description restates those same facts rather than extending them, so the baseline of 3 for fully documented schema applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a concrete verb+resource pairing ('Crawl a company website and extract emails, phone numbers and social profiles') and names the exact artifact produced, so the agent can distinguish it from lookup-style siblings like find_company_by_domain or lookup_domain. It stops short of explicitly contrasting itself with those siblings, which keeps it at a 4 rather than a 5.
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 purpose ('crawl a website' clearly maps to the contact-extraction job in this toolset), and it notes the accepted input formats for the website argument. However, it offers no when-to-use/when-not guidance and never points to a sibling such as enrich_company or lookup_domain for overlapping contact-enrichment needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_company_by_domainFind the company behind a websiteARead-onlyIdempotentInspect
Find the Romanian firm behind a website domain (dedeman.ro). Uses the registry's website field, else reads the site's home and legal/contact pages for the CUI or registration number it shows (matchedOn: registry_website, site_cui). Without one, it says so and offers name candidates from the page title or the domain name, each with a confidence (at most 0.7, never a match). One lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The website's domain ('dedeman.ro'); a URL or a www. host is reduced to it. Public domains only. | |
| fields | No | Optional: keep only these company fields in each row, comma-separated (companyName,cui,county,risk; dotted paths such as risk.level work). Without it the full record is returned. | |
| compact | No | Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url). |
Output Schema
| Name | Required | Description |
|---|---|---|
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| site | No | What was read from the site: url, pagesRead, title, cuis, registrationCodes, error. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| found | No | Whether a firm was identified. |
| match | No | The identified firm: cui, companyName, matchedOn. |
| total | No | Number of company records returned (at most 5); the same as returned. |
| domain | No | The normalised domain. |
| fields | No | The company fields kept when fields or compact trimmed the rows. |
| reason | No | When not found: no_cui_on_site or site_unreachable. |
| message | No | A sentence for the caller. |
| results | No | The company records, best first. |
| returned | No | Rows in results. Every list answer carries it with this one meaning. |
| warnings | No | Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field). |
| matchedOn | No | registry_website, site_cui or site_registration_code. |
| candidates | No | When not found (also when the site cannot be read): up to 3 firms whose name matches the page title or the domain name, each with a confidence (at most 0.7). |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add mechanism — and it does: it names the two resolution paths (registry website field, then home/legal-contact page CUI), the matchedOn values, the confidence cap of 0.7, and the rule that a candidate is 'never a match'. It stops short of describing failure/error modes or rate limits beyond 'One lookup.'
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 that are front-loaded with the core purpose before the mechanism detail. Every clause carries information, though the parenthetical mechanism sentence packs a lot of nested detail that could be split more cleanly.
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, yet the description still usefully defines matchedOn semantics and candidate confidence so the agent can interpret results. Combined with full schema coverage, the definition is nearly self-sufficient, with only explicit sibling routing 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 domain, fields and compact are already fully documented in the schema (including the www/URL reduction and dotted-path syntax). The description adds no parameter-level detail beyond confirming a single lookup, 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 — 'Find the Romanian firm behind a website domain (dedeman.ro)' — with a concrete example, so an agent immediately knows the input (domain) and output (company). It does not, however, explicitly distinguish itself from the sibling lookup_domain, which an agent could easily confuse with this tool.
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: you call this when you have a domain but not the company. There is no explicit 'when to use this vs. lookup_business/lookup_domain' guidance, though the closing 'One lookup.' hints at a cost/single-call constraint that helps the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageShow my daily allowanceARead-onlyIdempotentInspect
Show your own allowance: plan, daily limit, lookups used today, how many remain, when it resets (00:00 UTC) and any credit balance. Free and never counted as a lookup. Limits: 30 anonymous MCP calls a day, 50 with a free API key from https://leadgen.adrianhomelab.com/start (an email address, no payment).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| plan | No | Plan name (free, pro, business). |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| links | No | get_a_key, pricing, docs. |
| counted | No | Always false: this call is not counted. |
| message | No | A sentence for the caller. |
| identity | No | Who is counted: kind (key or anonymous) and counted_as. |
| remaining | No | Lookups left today. |
| resets_at | No | When the allowance resets (ISO 8601, 00:00 UTC). |
| suspended | No | true when the key is suspended. |
| used_today | No | Lookups used today. |
| daily_limit | No | Lookups allowed per UTC day. |
| entitlements | No | What the plan includes. |
| resets_in_seconds | No | Seconds until the reset. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), the description discloses the rate-limit policy, the exact reset moment (00:00 UTC), that the call is uncounted against quota, and how to raise the limit via a free API key with no payment. This is substantive operational and auth context the annotations do not carry.
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?
Purpose is front-loaded in the first clause, followed by the returned fields and then the cost/limit notes, so the agent gets the essential fact first. It is slightly dense with the enumerated fields plus the signup URL, but every sentence 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?
With an output schema present, return-value exposition is not required, yet the description still names the key fields, and the safety profile is fully covered by annotations. For a zero-param read tool, nothing needed 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?
The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The enumerated return fields are a bonus rather than a substitute for missing parameter documentation.
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 ('Show your own allowance') and enumerates exactly what the response contains: plan, daily limit, lookups used today, remaining count, reset time and credit balance. There is no sibling tool that overlaps with a usage/quota self-check, so differentiation is inherent and an agent can pick it instantly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent the call is free and 'never counted as a lookup', which is a concrete usage signal, and supplies the quota ceilings (30 anonymous, 50 with a key) so the agent knows when the plan is exhausted. It does not state an explicit when-to-call trigger or name an alternative, but with a zero-parameter read tool and no competing sibling there is little else to route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_businessLook up a Romanian companyARead-onlyIdempotentInspect
Look up a Romanian company by name or CUI (tax code) in the official ONRC registry of 4.2M firms. Diacritic-insensitive ('paval' finds 'PAVAL'); a CUI matches exactly. The first call for a named Romanian company. Ranked with a score: live firms first (exact name, then words), closed ones after; county lifts. For 'firms that do X in Y', use lookup_by_category (an empty result may carry a hint naming it).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name or CUI (tax ID) to search for. Names are diacritic-insensitive ('paval' finds PAVĂL); a CUI ('2816464', 'RO2816464') matches exactly. | |
| county | No | Optional county hint (diacritic-insensitive): firms registered there rank higher. Not a filter. | |
| fields | No | Optional: keep only these company fields in each row, comma-separated (companyName,cui,county,risk; dotted paths such as risk.level work). Without it the full record is returned. | |
| compact | No | Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url). | |
| max_results | No | Maximum number of companies to return (1-100, default 10). |
Output Schema
| Name | Required | Description |
|---|---|---|
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| hint | No | When a name search finds nothing but reads like a category question: the lookup_by_category call that answers it. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| found | No | false when a well-formed CUI is not in the snapshot. |
| query | No | The query as given. |
| total | No | Rows returned in this answer (at most max_results), not the number of firms that match; the same as returned (kept: the published v1 field). |
| county | No | The county hint, if one was given. |
| fields | No | The company fields kept when fields or compact trimmed the rows. |
| reason | No | Why nothing was found (not_found). |
| source | No | Data source: onrc (registry) or mfp (Ministry of Finance filings). |
| message | No | A sentence for the caller. |
| results | No | The company records, best first. |
| returned | No | Rows in results. Every list answer carries it with this one meaning. |
| warnings | No | Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field). |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, not destructive), but the description adds substantial behavior beyond them: diacritic-insensitive matching, exact-only CUI semantics, and a ranked-score result order (live firms, exact name then words, closed after, county lifts). This is real operational context the agent cannot get from the 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 core purpose and identifier, then behavior, then routing. Dense but well ordered; the quoted 'paval'/'PAVAL' example duplicates the schema wording and is the one sentence that costs more than it earns.
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 no explanation, and annotations cover the safety profile. Between the ranking rules, CUI/name semantics, and sibling routing, 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?
Schema description coverage is 100%, so all five parameters are already documented. The description's mention of diacritic insensitivity and CUI exactness largely restates the query param, and 'county lifts' restates the county param's 'rank higher, not a filter' semantics. Baseline 3 is appropriate; no meaningful syntax or format is added.
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 (look up a Romanian company) plus the exact identifier space (name or CUI) and the authoritative source (official ONRC registry of 4.2M firms). An agent can distinguish it from lookup_by_category, lookup_companies, and find_company_by_domain 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?
Explicitly positions itself as 'the first call for a named Romanian company' and names both the alternative and the trigger: 'For firms that do X in Y, use lookup_by_category'. It even warns that an empty result may carry a hint naming that alternative, which is unusually concrete routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_by_categoryFind companies by activityARead-onlyIdempotentInspect
Find companies by what they do, not by name: a curated topic ('software', 'retail'), plain words ('dentists', a CAEN class title; see matched) or CAEN codes ('4321,4322'; 6201 also finds Rev.3 6210). Narrow by county; qualify by revenue, headcount, VAT, main activity. active_only (default) drops dead and ANAF-inactive firms.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Order of the results: 'newest' registrations first (default), 'revenue' (latest filing's turnover, biggest first) or 'employees' (headcount, biggest first); firms without a filing come last. | newest |
| topic | Yes | What the firms do: a curated topic ('software', 'retail'), plain words for a trade ('dentists', 'stomatologie'), a CAEN class title in Romanian or English, or CAEN codes ('6201' or '4321,4322'). Case-, space- and diacritic-insensitive. A number that names another activity in each revision takes a suffix: '4781r3' (Rev.3) or '4781r2' (Rev.2). | |
| county | No | Optional county to narrow to (diacritic-insensitive: 'bucuresti', 'cluj'; a county town such as 'Cluj-Napoca' or a Bucharest sector is read as its county); omit for nationwide. An unknown county is an error (unknown_county) with suggestions, not 0 firms. | |
| fields | No | Optional: keep only these company fields in each row, comma-separated (companyName,cui,county,risk; dotted paths such as risk.level work). Without it the full record is returned. | |
| compact | No | Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url). | |
| vat_payer | No | Optional: true keeps VAT-registered firms only, false only non-VAT payers (ANAF data). Omit for both. | |
| legal_form | No | Optional legal form(s) to keep, comma-separated, case-insensitive: 'SRL', 'SA', 'PFA', 'II', or 'SRL,SA' (companies, no sole traders). Default: any form. | |
| active_only | No | Default true: drop firms that are not a lead (struck off, dissolving, in liquidation, insolvent or bankrupt, activity suspended, or ANAF fiscally inactive). false returns every firm. | |
| has_website | No | true keeps only firms with a website on file in the registry (default false). | |
| max_results | No | Maximum number of companies to return (1-100, default 10). | |
| max_revenue | No | Optional maximum net turnover in RON on the latest filing. | |
| min_revenue | No | Optional minimum net turnover in RON on the latest filing (FY2025, else FY2024). Firms without a filing never match a band. | |
| max_employees | No | Optional maximum average headcount on the latest filing. | |
| min_employees | No | Optional minimum average headcount on the latest filing. | |
| main_activity_only | No | Default false: a firm matches when the code is ANY of its authorised activities (ONRC lists a dozen per firm, most never practised). true keeps only firms whose DECLARED main activity is one of the codes (ANAF main CAEN, else the CAEN on the latest filing): fewer, more relevant firms. The Leadgen app's lists use true by default. |
Output Schema
| Name | Required | Description |
|---|---|---|
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| sort | No | The order of results: newest, revenue or employees. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| label | No | Human label of what was matched. |
| query | No | The topic as given. |
| topic | No | The curated topic matched, if any. |
| total | No | Rows returned in this answer (at most max_results), not the size of the match set: a full page (total == max_results) may have more; narrow the filters or raise max_results. The same as returned; the size of the whole list is matchTotal. |
| appUrl | No | The same list opened in the Leadgen app (CAEN codes, county, legal form, active and main-activity filters), to share with the user; null when the app cannot open it (more than 10 codes, a legal form it does not offer). |
| county | No | The county filter, if any. |
| fields | No | The company fields kept when fields or compact trimmed the rows. |
| source | No | Data source: onrc (registry) or mfp (Ministry of Finance filings). |
| filters | No | The filters applied (legalForm, activeOnly, revenue and headcount bands, vatPayer, mainActivityOnly ...). |
| matched | No | How plain words were read: by, niche or class title, codes. |
| message | No | A sentence for the caller. |
| results | No | The company records, best first. |
| returned | No | Rows in results. Every list answer carries it with this one meaning. |
| warnings | No | Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field). |
| caenCodes | No | The CAEN codes searched, when given or derived as codes. |
| caenNames | No | The CAEN codes as asked, named: [{code, title (Romanian), titleEn}]. |
| truncated | No | true when max_results was cut to the list cap (and the list is full). |
| candidates | No | When the words fit several activities (ambiguous_topic): the ones to choose from. |
| codesAdded | No | CAEN Rev.2/Rev.3 counterparts added to the search. |
| matchTotal | No | How many firms the whole list holds with every filter (active_only on; null when off): exact, or estimated when matchTotalApproximate is true. |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
| warningDetails | No | The warnings that have a machine-readable form (the CAEN Rev.2/Rev.3 notes): [{code, params, message}], message the same English line as in warnings; null when none. |
| availableTopics | No | The curated topic ids, when the topic is unknown or ambiguous. |
| matchTotalMargin | No | The 99% margin of an estimated matchTotal. |
| availableTopicNames | No | Each curated topic id with its name, e.g. {"agriculture": "Agriculture & Food"}, next to availableTopics. |
| inactiveFilteredOut | No | Firms removed by active_only (null when off). |
| matchTotalApproximate | No | true when matchTotal is estimated (matchTotalMargin: its 99% margin). |
| inactiveFilteredOutApproximate | No | true when that count is estimated. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, not destructive, closed world), so the bar is lower; the description still adds non-obvious behaviour: active_only defaults to dropping dead and ANAF-inactive firms, and a single code ('6201') also surfaces firms under the matching code in other CAEN revisions. It does not discuss result caps or the matched field's semantics, 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?
A tight three-clause sentence: what it matches on, how to narrow, and the default lifetime filter. Front-loaded with the key distinction ('not by name'), though the parenthetical about Rev.3/Rev.2 codes is dense and slightly interrupts the flow.
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 and full parameter documentation, the description only needs to frame the tool; it does that, covering input modes, narrowing, and the active_only default. It omits any note on the referenced 'matched' field's meaning and on result volume/sorting, which would help for a 15-parameter search 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 description coverage is 100% across all 15 parameters, so the schema already documents topic forms, county handling, sort, field projection and the filter bands. The description only restates a subset (county, revenue, headcount, VAT, main activity) at a higher level, adding no syntax or edge-case 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 and resource ('Find companies') and immediately scopes it by modality: by activity rather than by name, with the three accepted input flavours (curated topic, plain trade words, CAEN codes). An agent can tell this apart from the name/domain/director lookups among the siblings 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?
Implied usage only: 'Narrow by county; qualify by revenue, headcount, VAT, main activity' signals how to constrain a search but never says when to reach for this tool over lookup_companies, lookup_business or match_companies, and names no exclusions. Adequate context, no routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_companiesLook up many companies by CUIARead-onlyIdempotentInspect
Look up many Romanian companies by CUI in one call (up to 100): one result per input, in input order, each with found true/false and the company record. Each row is one lookup; rows past today's allowance come back not_processed (partial: true, remaining: rows to resend after the reset). fields or compact trims each record.
| Name | Required | Description | Default |
|---|---|---|---|
| cuis | Yes | Up to 100 CUIs, as a list or one comma-separated string ('RO', spaces and leading zeros accepted, as in lookup_business). | |
| fields | No | Optional: keep only these company fields in each row, comma-separated (companyName,cui,county,risk; dotted paths such as risk.level work). Without it the full record is returned. | |
| compact | No | Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url). |
Output Schema
| Name | Required | Description |
|---|---|---|
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| found | No | Rows that matched a firm. |
| total | No | Number of input rows. |
| errors | No | Rows that are input errors (empty, not a CUI, wrong control digit). |
| fields | No | The company fields kept when fields or compact trimmed the rows. |
| source | No | Data source: onrc (registry) or mfp (Ministry of Finance filings). |
| message | No | A sentence for the caller. |
| partial | No | true when today's allowance ran out partway: the first processed rows were answered, the rest have status not_processed (not run, not counted). |
| results | No | Per input: input, cui, found, and company (the record) or error/reason; status not_processed for a row today's allowance did not cover. |
| metering | No | What the batch cost: rows, counted, notCounted (input-error rows and rows not processed are not counted), notProcessed (when partial) and the rule. |
| notFound | No | Well-formed CUIs not in the snapshot. |
| warnings | No | Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field). |
| processed | No | Rows answered, from the first one (input-error rows included). |
| remaining | No | Rows not processed (the last ones): send them again after the reset. 0 when the whole batch ran. |
| dailyLimit | No | When partial: the daily-limit notice in the refusal vocabulary (error daily_limit_reached, message, limit, used, remaining allowance, resets_at, requested, processed, plan, get_a_key, pricing, docs, upgrade with a key). |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond that: allowance/quota exhaustion produces not_processed rows with partial: true and a remaining count, results preserve input order, and each row carries a found flag. That quota and partial-failure disclosure is exactly what annotations cannot express.
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 action and cap, then layered with result-shape and quota details. It is dense and somewhat run-on in the middle, but every clause carries operational information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter batch tool with an output schema, the description covers everything an agent needs: batch size limit, result ordering, the found flag, quota-exhaustion semantics and the recovery instruction ('rows to resend after the reset'). Nothing material 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 description coverage is 100%, so the schema already documents cuis, fields and compact. The description's note that 'fields or compact trims each record' and the 100-CUI cap add only marginal value over 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 and resource with batch scope: 'Look up many Romanian companies by CUI in one call (up to 100)'. An agent can tell it apart from single-record siblings like lookup_business or lookup_by_category immediately.
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 batch limit and one-result-per-input ordering imply this is the tool for bulk lookups, and it references lookup_business for CUI formatting. However, it never explicitly says when to prefer this over match_companies or repeated lookup_business calls, so usage selection is left largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_directorFind companies by directorARead-onlyIdempotentInspect
Find Romanian companies by the name of a director or legal representative (ONRC). Diacritic-insensitive. Whole words: 'pop maria' finds POP MARIA, not POPA MARIANA; prefix=true matches prefixes. The registry has no personal ID, so one name can be several people: homonyms and byCounty say so. Use this when you know a person rather than a firm.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Director / representative name to search for (e.g. 'Ion Popescu'); diacritic-insensitive, each word a whole word of the name. | |
| fields | No | Optional: keep only these company fields in each row, comma-separated (companyName,cui,county,risk; dotted paths such as risk.level work). Without it the full record is returned. | |
| prefix | No | true matches each word as a prefix ('pop' also finds POPA, POPESCU); default false (whole words). | |
| compact | No | Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url). | |
| max_results | No | Maximum number of companies to return (1-100, default 10). |
Output Schema
| Name | Required | Description |
|---|---|---|
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| note | No | What homonyms means for this name. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| match | No | words (whole words) or prefix. |
| query | No | The name as given. |
| total | No | Every matching firm, not just the rows returned. |
| fields | No | The company fields kept when fields or compact trimmed the rows. |
| source | No | Data source: onrc (registry) or mfp (Ministry of Finance filings). |
| message | No | A sentence for the caller. |
| results | No | The company records, best first. |
| byCounty | No | Matching firms per county. |
| homonyms | No | true when the matches span several counties (likely several people). |
| returned | No | Rows in results. Every list answer carries it with this one meaning. |
| warnings | No | Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field). |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
| distinctCounties | No | Number of counties the matches are in. |
| totalIsLowerBound | No | true when the scan stopped early and total is a minimum. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent safety profile, and the description adds genuine behavioral context: diacritic-insensitivity, whole-word matching, and the important caveat that the registry has no personal ID so one name can map to several people (homonyms, byCounty). It doesn't discuss pagination or result limits, keeping it just short of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then scoping details, then the routing rule. Dense but each sentence carries a distinct fact; a semicolon-packed third sentence is the only mild drag.
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 5 parameters, full schema coverage, an output schema, and annotations carrying the safety profile, the description supplies everything an agent needs, including the crucial matching-semantics and homonym caveats.
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 prefix, fields, compact and max_results are already documented. The description reinforces prefix semantics with a concrete example ('pop maria' finds POP MARIA, not POPA MARIANA), which is marginally useful but largely duplicates 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?
States a specific verb (find) and resource (Romanian companies by director/legal representative) with the ONRC registry named. This clearly separates it from firm-oriented siblings like lookup_companies and match_companies.
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 routing rule: 'Use this when you know a person rather than a firm.' It clearly implies the opposite case is served by other lookup tools, though it does not name a specific sibling to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_domainDomain WHOIS, DNS and email auditARead-onlyIdempotentInspect
WHOIS plus DNS records (A, MX, NS, TXT) and an SPF/DMARC email-security audit for a domain. Use it to profile a company's web estate or check its email posture. include_dns and include_security toggle the two halves.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to look up (e.g. 'example.com'); a URL is reduced to its host. | |
| include_dns | No | Include DNS records (A, AAAA, MX, NS, TXT, SOA); default true. | |
| include_security | No | Include the SPF/DMARC email-security check; default true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| dns | No | Records by type: A, AAAA, MX, NS, TXT, SOA. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| whois | No | registrar, creationDate, expirationDate, updatedDate, nameServers, registrantOrg, registrantCountry. |
| domain | No | The normalised domain. |
| message | No | A sentence for the caller. |
| security | No | hasSPF, spf, hasDMARC, dmarc. |
| resolvedIP | No | An address the domain resolves to. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, open-world, non-destructive operation, so the safety profile is covered. The description adds that the lookup is split into DNS and email-security halves, but discloses nothing about rate limits, failures on non-existent domains, or external source variability that an agent would find useful.
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 tight sentences with the payload list front-loaded and the toggles noted last. Nothing is padded, though the final toggle sentence is largely redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation here, and the description covers scope, toggles, and intended use. A note on behavior for non-existent or malformed domains would complete it, but it is otherwise sufficient 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 100%, so all three parameters are fully documented in the schema, including defaults and the URL-to-host normalization. The description's note that include_dns/include_security toggle the two halves restates what the schema already conveys, 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 (lookup) and resource (domain) and enumerates the concrete payloads: WHOIS, DNS records, and an SPF/DMARC email audit. This distinguishes it from the sibling company-lookup tools, which fetch entity data rather than domain infrastructure.
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 it to profile a company's web estate or check its email posture" gives clear context for when to reach for this tool. It stops short of naming an alternative or exclusion (e.g., when to prefer find_company_by_domain or enrich_company instead), so it is not a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_financial_ratiosFinancial ratios and health scoreARead-onlyIdempotentInspect
Financial analysis of a Romanian company: multi-year revenue trend (YoY, 3/5/10-year CAGR), margins, headcount, solvency and liquidity ratios, a 0–100 health score with its rule-by-rule breakdown, red flags, and peer percentiles within the same CAEN activity and county. Verdict: 'growing', 'stable' or 'distressed'. Use lookup_financials for the raw figures.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | Yes | Romanian tax identification number (CUI), e.g. '2816464'; 'RO' and leading zeros are accepted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cui | No | The firm's CUI. |
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| flags | No | Red flags. |
| found | No | Whether any filing is on record. |
| peers | No | Percentiles within the same CAEN activity and county. |
| total | No | Number of fiscal years used. |
| years | No | Per fiscal year figures and margins. |
| ratios | No | Margins, equity ratio, debt to equity, liquidity, returns. |
| source | No | Data source: onrc (registry) or mfp (Ministry of Finance filings). |
| history | No | Years on record, loss years, revenue peak. |
| message | No | A sentence for the caller. |
| signals | No | The distress signals found. |
| verdict | No | growing, stable or distressed. |
| distress | No | true when the distress signals fire. |
| headcount | No | Latest headcount and its change. |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
| healthScore | No | 0-100 score, band and its rule-by-rule components. |
| revenueTrend | No | Latest revenue, YoY growth, 3/5/10-year CAGR, trend label. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds real behavioral content beyond that: the fixed verdict vocabulary ('growing', 'stable', 'distressed'), the rule-by-rule health score breakdown, and that peer percentiles are scoped to the same CAEN activity and county.
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 tool's identity and output scope, then closes with the sibling routing sentence. The first sentence is dense with a long enumeration, but each clause carries information an agent needs; no filler sentences.
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, so return values need not be explained, yet the description still characterizes the key result fields and the verdict vocabulary, which aids interpretation. For a single-parameter, read-only lookup with full annotations, nothing an agent needs to call or interpret 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?
Schema description coverage is 100% and the single 'cui' parameter is fully documented in the schema, including the 'RO' prefix and leading-zero tolerance. The description adds no parameter-level meaning 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 and resource ('financial analysis of a Romanian company') and enumerates the exact derived outputs: multi-year trend with CAGR windows, margins, solvency/liquidity ratios, a 0–100 health score, red flags, and peer percentiles. It also names the sibling it differs from, so an agent can separate it from lookup_financials 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?
Explicitly routes the agent: 'Use lookup_financials for the raw figures,' which gives a clear alternative and the condition that selects it (computed ratios vs. raw figures). It stops short of stating any when-not-to-use case or prerequisites, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_financialsAnnual financial statementsARead-onlyIdempotentInspect
Annual financial statements for a Romanian company from Ministry of Finance filings, every fiscal year on record since 2008: revenue, profit, headcount and balance-sheet lines in RON with each year's ratios (growth, margins, equity ratio, liquidity), plus a summary (3/5/10-year CAGR, loss years, health score). Resolve the firm with lookup_business first if you only have a name.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | Yes | Romanian tax identification number (CUI), e.g. '2816464'; 'RO' and leading zeros are accepted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cui | No | The firm's CUI. |
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| found | No | Whether any filing is on record. |
| total | No | Number of fiscal years returned. |
| years | No | Per fiscal year: revenue, profit, loss, netResult, employees, assets, debt, equity (RON) and that year's ratios. |
| source | No | Data source: onrc (registry) or mfp (Ministry of Finance filings). |
| message | No | A sentence for the caller. |
| summary | No | History, revenue growth (3/5/10-year CAGR), latest ratios, health score and band, flags. |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds genuine value beyond that: the data source (Ministry of Finance filings), historical depth (every fiscal year since 2008), currency (RON), and the name-resolution prerequisite. Rate limits, auth, and coverage gaps (e.g. missing years, firms never filing) are unmentioned.
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 payload is front-loaded into one dense sentence and the routing rule is a short second sentence, so nothing is buried. The enumerated field list is long but each item is informative rather than 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 an output schema present, the return format need not be explained, and annotations cover the safety profile; the description still supplies source, currency, and historical coverage. The remaining gap is the unresolved overlap with lookup_financial_ratios, which an agent facing both tools would need to disambiguate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter and the schema description coverage is 100%, with the schema itself documenting the CUI format, examples, and acceptance of 'RO' and leading zeros. The description adds no parameter-level meaning, 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+resource with unusually concrete scope: annual statements for a Romanian company sourced from Ministry of Finance filings, every fiscal year since 2008, including named line items in RON. It stops short of drawing the boundary against the sibling lookup_financial_ratios, whose territory (ratios) this description also claims, so an agent must guess which to call for ratio-only needs.
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 gives the prerequisite path: resolve the firm with lookup_business first when only a name is available, which is real routing guidance. It offers no when-to-use versus lookup_financial_ratios or the other lookup_* siblings, so selection among overlapping tools is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
match_companiesMatch a list of records to firmsARead-onlyIdempotentInspect
Match a list of up to 500 records (name, optional county, domain or CUI) to Romanian firms: each row gets match {cui, companyName, confidence, matchedOn} and the record, or no_match with up to 3 candidates. A valid CUI wins (confidence 1.0). Each row is one lookup; rows past today's allowance come back not_processed (partial: true, remaining: rows to resend after the reset).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | Up to 500 records, each {name, county, domain, cui, ref} (any of them; ref is your own id, echoed back), or a bare string (a CUI, a domain or a name). | |
| fields | No | Optional: keep only these company fields in each row, comma-separated (companyName,cui,county,risk; dotted paths such as risk.level work). Without it the full record is returned. | |
| compact | No | Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url). |
Output Schema
| Name | Required | Description |
|---|---|---|
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| total | No | Number of input rows. |
| errors | No | Rows that are input errors (nothing to match on). |
| fields | No | The company fields kept when fields or compact trimmed the rows. |
| source | No | Data source: onrc (registry) or mfp (Ministry of Finance filings). |
| matched | No | Rows matched to a firm. |
| message | No | A sentence for the caller. |
| noMatch | No | Rows with no match above the threshold. |
| partial | No | true when today's allowance ran out partway: the first processed rows were answered, the rest have status not_processed (not run, not counted). |
| results | No | Per row: row, input, status (matched or no_match), match {cui, companyName, confidence, matchedOn}, company, or candidates. |
| metering | No | What the batch cost: rows, counted, notCounted (input-error rows and rows not processed are not counted), notProcessed (when partial) and the rule. |
| warnings | No | Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field). |
| processed | No | Rows answered, from the first one (input-error rows included). |
| remaining | No | Rows not processed (the last ones): send them again after the reset. 0 when the whole batch ran. |
| threshold | No | Confidence a row needs to be matched (0-1). |
| dailyLimit | No | When partial: the daily-limit notice in the refusal vocabulary (error daily_limit_reached, message, limit, used, remaining allowance, resets_at, requested, processed, plan, get_a_key, pricing, docs, upgrade with a key). |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/non-destructive profile, yet the description adds substantial behavior beyond them: a 500-row limit, per-row lookup accounting, a daily allowance with not_processed rows, partial:true with a remaining count for resend-after-reset, and the CUI-wins-at-confidence-1.0 rule. This is exactly the operational context an agent needs to handle partial 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?
Dense but front-loaded: the batch scope and row cap come first, then result shape, then the CUI rule and rate-limit behavior. Nearly every clause carries information, with only mild redundancy between the output-shape sentence and the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 3-parameter batch tool with an output schema, the description covers everything needed to call it correctly: input sources, row cap, match/no_match semantics, the CUI override, and the allowance/partial-result handling. Nothing material is left for the agent to guess.
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 fully documents the row shape, fields, and compact parameters. The description restates the matchable fields but does not elaborate on the fields or compact options, so it sits at the baseline for high-coverage schemas.
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 (match) and a precise scope (a list of up to 500 records to Romanian firms), which is distinct from the single-lookup siblings. It stops short of explicitly naming an alternative such as lookup_companies, so an agent must infer the batch-vs-single distinction rather than being told.
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 500-row cap and the per-row allowance clause imply this is the batch tool for bulk matching, which is useful context. However, there is no explicit statement of when to pick this over lookup_companies or find_company_by_domain, 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.
poll_watchlistCollect watchlist changesAInspect
Collect everything the watch tools have found: call it to drain the changeset for every watch owned by your API key, most severe first. Company watches return an 'updated' entry with the changed fields and risk; CAEN and county watches return the 'new' firms registered since the last poll (200 a poll, the rest next).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the poll ran. |
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| owner | No | Whose watches these are (key prefix or IP). |
| total | No | Number of watches with news. |
| active | No | Every watch you hold, changed or not: kind (company or caen), target (CUI or code), county, since, name. Remove one with unwatch. |
| message | No | A sentence for the caller. |
| watches | No | Per watch: an 'updated' company with its changed fields and risk, or the 'new' firms registered in a watched activity. |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
| email_alerts | No | How to get the same changes by email. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, and the description explains exactly why: 'drain the changeset' discloses that collection consumes/mutates the pending changeset state, and 'since the last poll (200 a poll, the rest next)' discloses the non-idempotent pagination cap. It also describes ordering ('most severe first') and the differing output shapes for company vs CAEN/county watches, which is well beyond what the annotations 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?
Two sentences, tightly front-loaded with what the tool does and why, followed by the output and pagination details. Every clause earns its place with 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?
An output schema exists so return values need not be explained, yet the description still summarizes the two result shapes ('updated' entries with fields and risk, 'new' firms for CAEN/county) and the 200-per-poll limit. For a zero-parameter polling tool, 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?
The tool takes zero parameters, so per the baseline the description carries no parameter burden beyond baseline 4. Schema coverage is 100% (empty object), and there is nothing in the parameter surface for the description to compensate for.
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 uses a specific verb ('Collect... drain the changeset') and resource ('every watch owned by your API key'), and it explicitly frames itself against the sibling watch tools that create the watches. An agent can distinguish this from watch_company/watch_caen/unwatch without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly establishes the context of use: call this to drain what the watch tools have found for your API key. It implies the setup/consume relationship with the watch_* siblings, but it never states when not to call it or names an explicit alternative (e.g., unwatch to stop collection).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_issueReport missing or wrong dataAInspect
Report to the person who runs Leadgen what is missing or wrong: a missing field, firm or source (kind 'gap'), a wrong company record ('wrong_record', pass its cui), a bug, an idea. Free, never counted as a lookup. contact is optional (an address for a reply); nothing is mailed to it automatically. Registry records are corrected at the source (ONRC) and arrive with the next snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | No | Optional CUI of the firm the report is about (for 'wrong_record'). | |
| kind | No | One of 'gap' (a missing field, firm or source; the default), 'wrong_record' (pass its cui), 'bug', 'idea', 'other'. | gap |
| contact | No | Optional email address for a reply; nothing is mailed to it automatically. | |
| message | Yes | The report, in plain words: what is missing or wrong. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The report's id. |
| kind | No | The kind filed. |
| note | No | For wrong_record: how registry records get corrected. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| status | No | received. |
| message | No | A sentence for the caller. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so safety is covered; the description goes further with real operational context: the report is free and never counted as a lookup, no email is sent to contact automatically, and registry corrections land at the source (ONRC) with the next snapshot. What is missing is who consumes the report or any acknowledgement/timing expectation for non-registry kinds.
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 purpose, then kind taxonomy, then cost and delivery caveats — a sensible order. It is a single dense block with some restatement of schema-documented details (contact behavior appears in both places), so minor trimming is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 params, an output schema present, and 100% schema coverage, the description covers what an agent needs: what to report, which kind to pick, and the cost/behavioural implications. It stops short of describing expected acknowledgement or how the reporter is identified, but no essential calling information 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 description coverage is 100%, so the schema already defines cui, kind, contact and message. The description restates those same semantics (kind values, 'pass its cui', contact is optional and not auto-mailed) rather than adding new meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Report to the person who runs Leadgen what is missing or wrong') and immediately enumerates the reportable categories (gap, wrong_record, bug, idea). This cleanly separates it from every sibling, all of which are read-only lookups rather than feedback channels.
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 each report kind: gaps for missing fields/firms/sources, 'wrong_record' with its cui, plus bug and idea. It doesn't need to name a non-reporting alternative because no sibling does this job, but it also never states any exclusion or precondition beyond the kind semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unwatchStop watching a company or activityADestructiveIdempotentInspect
Stop watching a company (cui) or a CAEN activity code (code, plus the county it was watched in, if any), on your API key: the watch and its baseline are removed. Unwatching something you do not watch changes nothing (removed: 0). poll_watchlist lists your active watches.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | No | CUI of a watched firm (e.g. '2816464'); give this or code. | |
| code | No | A watched CAEN activity code (e.g. '6210'); give this or cui. | |
| county | No | With code: the county the code was watched in (diacritic-insensitive); omit for a nationwide watch. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the request was valid. |
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| kind | No | company or caen. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| owner | No | Whose watches these are (key prefix or IP). |
| active | No | The watches you still hold (as in poll_watchlist). |
| county | No | The CAEN watch's county; null for nationwide or a company. |
| target | No | The CUI or CAEN code. |
| message | No | A sentence for the caller. |
| removed | No | 1 when the watch was removed, 0 when you did not hold it. |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, but the description adds concrete value: it says the watch AND its baseline are removed, that the operation is scoped to 'your API key', and that a redundant call returns 'removed: 0'. That corroborates and enriches the idempotent/destructive annotations rather than merely repeating them.
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 compact sentences, front-loaded with the action and its scope, followed by the no-op guarantee and the cross-reference. Every sentence earns its place.
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 so return values need no explanation, and annotations cover the safety profile; the description supplies the baseline-removal effect, API-key scoping, and the sibling pointer. Only minor gaps (e.g. required-permission context) remain.
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 each parameter already documents its own meaning, so the baseline is 3. The description restates the cui/code alternation and adds that county is 'the county it was watched in, if any', but contributes no syntax or format 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?
States a specific verb (stop watching) and the two interchangeable resource modes (company cui, CAEN code), and distinguishes itself from the watch_company/watch_caen siblings. An agent can identify the inverse operation 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?
Explains the no-op case ('unwatching something you do not watch changes nothing') and routes the agent to poll_watchlist to see active watches. It lacks an explicit statement of prerequisites or when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_caenWatch an activity for new firmsAIdempotentInspect
Watch a CAEN activity code, optionally scoped to one county, for newly registered firms. A registration-date cutoff is the baseline: only firms registered after it are reported, and poll_watchlist slides the cutoff forward so each new firm surfaces once. A retired CAEN Rev.2 code (6201) also watches its Rev.3 successor (6210), with a warning.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | CAEN activity code to watch (e.g. '6210'); a retired Rev.2 code also watches its Rev.3 successor. | |
| county | No | Optional county name to scope the watch to (diacritic-insensitive); omit to watch nationwide. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the watch is in place. |
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| watch | No | kind, target, owner (key prefix), county, baseline. |
| message | No | A sentence for the caller. |
| warnings | No | Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field). |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
| alreadyWatching | No | true when you already held this watch (nothing changed). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower. The description still adds real behavior beyond them: the registration-date baseline cutoff, the dedup guarantee that each firm surfaces once, and the retired Rev.2 → Rev.3 alias with a warning. It doesn't cover watch lifetime or how to remove the watch, hence 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 tight sentences: purpose first, then the cutoff/polling mechanics, then the edge case alias. No filler and the most important information is front-loaded.
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, so return values need not be described, and annotations carry the safety profile. The description covers scope, cutoff semantics, dedup, and the alias edge case; only watch lifecycle/auth requirements are unaddressed, which is a minor 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 description coverage is 100% — both 'code' and 'county' are documented, including diacritic-insensitivity and nationwide default. The description's note about retired Rev.2 codes restates what the schema already says, adding no new parameter semantics, 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 ('Watch a CAEN activity code') plus the scope ('for newly registered firms'), which cleanly separates it from watch_company (single firm) and unwatch. An agent can identify what is being created 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?
The description explains the workflow relationship to poll_watchlist ('slides the cutoff forward so each new firm surfaces once'), which tells the agent when this tool's output will be consumed. It stops short of an explicit when-not/exclusion rule against the sibling watch tools, so it lands at clear context without routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_companyWatch a company for changesAIdempotentInspect
Register a company (by CUI) to monitor. Stores a fingerprint of its current registry record as the baseline; poll_watchlist then reports changes between monthly ONRC snapshots - a new director, a new CAEN activity, an address or status change - and when ANAF declares it fiscally inactive or its VAT status flips.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | Yes | Romanian tax identification number (CUI) of the firm to watch, e.g. '2816464'. Watching a firm you already watch changes nothing. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the watch is in place. |
| asOf | No | What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source. |
| error | No | Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted. |
| watch | No | kind, target, owner (key prefix), county, baseline. |
| message | No | A sentence for the caller. |
| attribution | No | The credit line to keep when redistributing the data (CC BY 4.0). |
| alreadyWatching | No | true when you already held this watch (nothing changed). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: it stores a fingerprint of the current registry record as a baseline, changes are computed between monthly ONRC snapshots, and it enumerates the change classes detected (director, CAEN activity, address, status, ANAF fiscal-inactivity, VAT flip). It also reinforces idempotency ('watching a firm you already watch changes nothing'), consistent with idempotentHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence, front-loaded with the action, then the baseline mechanism, then the reported outcomes and cadence. No filler sentences and nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, full schema coverage, an output schema, and annotations covering the safety profile, the description supplies everything else an agent needs: what registration stores, when results appear (monthly snapshots), and via which sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already defines CUI with an example plus the idempotency note. The description only restates 'by CUI', adding no format or constraint detail 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 concrete verb+resource ('Register a company ... to monitor') and immediately names the downstream consumer (poll_watchlist), which separates it from siblings like watch_caen and unwatch. An agent can pick it 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?
Explains the workflow context clearly: register here, then poll_watchlist reports changes. It does not state exclusions or explicitly contrast with watch_caen (CAEN-specific watching) or unwatch, 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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
lookup_by_category1 field changed- added
Output schema / properties / warningDetailsAdded value: +{ + "description": "The warnings that have a machine-readable form (the CAEN Rev.2/Rev.3 notes): [{code, params, message}], message the same English line as in warnings; null when none.", + "items": { + "type": "object" + }, + "type": [ + "array", + "null" + ] +}
3 tool updates
- Changed
lookup_companies7 fields changed- added
Output schema / properties / dailyLimitAdded value: +{ + "description": "When partial: the daily-limit notice in the refusal vocabulary (error daily_limit_reached, message, limit, used, remaining allowance, resets_at, requested, processed, plan, get_a_key, pricing, docs, upgrade with a key).", + "type": [ + "object", + "null" + ] +} - changed
Output schema / properties / metering / descriptionPrevious value: -"What the batch cost: rows, counted, notCounted (input-error rows are not counted) and the rule."New value: +"What the batch cost: rows, counted, notCounted (input-error rows and rows not processed are not counted), notProcessed (when partial) and the rule." - added
Output schema / properties / partialAdded value: +{ + "description": "true when today's allowance ran out partway: the first processed rows were answered, the rest have status not_processed (not run, not counted).", + "type": [ + "boolean", + "null" + ] +} - added
Output schema / properties / processedAdded value: +{ + "description": "Rows answered, from the first one (input-error rows included).", + "type": [ + "integer", + "null" + ] +} - added
Output schema / properties / remainingAdded value: +{ + "description": "Rows not processed (the last ones): send them again after the reset. 0 when the whole batch ran.", + "type": [ + "integer", + "null" + ] +} - changed
Output schema / properties / results / descriptionPrevious value: -"Per input: input, cui, found, and company (the record) or error/reason."New value: +"Per input: input, cui, found, and company (the record) or error/reason; status not_processed for a row today's allowance did not cover." - added
Output schema / properties / results / items / properties / statusAdded value: +{ + "description": "not_processed (reason daily_limit_reached) for a row not run; absent otherwise.", + "type": [ + "string", + "null" + ] +}
- Changed
lookup_financial_ratios1 field changed- changed
Output schema / descriptionPrevious value: -"Derived financial intelligence and a verdict."New value: +"Financial ratios, a health score, peer percentiles and a verdict."
- Changed
match_companies6 fields changed- added
Output schema / properties / dailyLimitAdded value: +{ + "description": "When partial: the daily-limit notice in the refusal vocabulary (error daily_limit_reached, message, limit, used, remaining allowance, resets_at, requested, processed, plan, get_a_key, pricing, docs, upgrade with a key).", + "type": [ + "object", + "null" + ] +} - changed
Output schema / properties / metering / descriptionPrevious value: -"What the batch cost: rows, counted, notCounted (input-error rows are not counted) and the rule."New value: +"What the batch cost: rows, counted, notCounted (input-error rows and rows not processed are not counted), notProcessed (when partial) and the rule." - added
Output schema / properties / partialAdded value: +{ + "description": "true when today's allowance ran out partway: the first processed rows were answered, the rest have status not_processed (not run, not counted).", + "type": [ + "boolean", + "null" + ] +} - added
Output schema / properties / processedAdded value: +{ + "description": "Rows answered, from the first one (input-error rows included).", + "type": [ + "integer", + "null" + ] +} - added
Output schema / properties / remainingAdded value: +{ + "description": "Rows not processed (the last ones): send them again after the reset. 0 when the whole batch ran.", + "type": [ + "integer", + "null" + ] +} - changed
Output schema / properties / results / items / properties / status / descriptionPrevious value: -"matched, no_match, or an error status."New value: +"matched, no_match, error, or not_processed (reason daily_limit_reached: not run, not counted)."
8 tool updates
- Changed
enrich_company2 fields changed- changed
Output schema / properties / company / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address (a sole trader's PFA/II/IF locality only in an answer listing several firms, with addressScope: locality), county, city, website, phone (+ phoneSource: ANAF, declared by the taxpayer), caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)." - changed
Output schema / properties / contacts / descriptionPrevious value: -"Contacts found, each with type, value, confidence and source."New value: +"Contacts found, each with type, value, confidence and source; an email also has personal (true for a firstname.lastname@ address: GDPR art. 14 and Law 506/2004 apply), role addresses first."
- Changed
extract_contacts1 field changed- added
Output schema / properties / personalEmailsAdded value: +{ + "description": "Addresses shaped like a person's (firstname.lastname@): personal data, so GDPR art. 14 and Law 506/2004 apply. Role addresses (office@) rank first.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] +}
- Changed
find_company_by_domain1 field changed- changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address (a sole trader's PFA/II/IF locality only in an answer listing several firms, with addressScope: locality), county, city, website, phone (+ phoneSource: ANAF, declared by the taxpayer), caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_business1 field changed- changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address (a sole trader's PFA/II/IF locality only in an answer listing several firms, with addressScope: locality), county, city, website, phone (+ phoneSource: ANAF, declared by the taxpayer), caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_by_category1 field changed- changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address (a sole trader's PFA/II/IF locality only in an answer listing several firms, with addressScope: locality), county, city, website, phone (+ phoneSource: ANAF, declared by the taxpayer), caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_companies1 field changed- changed
Output schema / properties / results / items / properties / company / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address (a sole trader's PFA/II/IF locality only in an answer listing several firms, with addressScope: locality), county, city, website, phone (+ phoneSource: ANAF, declared by the taxpayer), caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_director1 field changed- changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address (a sole trader's PFA/II/IF locality only in an answer listing several firms, with addressScope: locality), county, city, website, phone (+ phoneSource: ANAF, declared by the taxpayer), caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
match_companies1 field changed- changed
Output schema / properties / results / items / properties / company / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address (a sole trader's PFA/II/IF locality only in an answer listing several firms, with addressScope: locality), county, city, website, phone (+ phoneSource: ANAF, declared by the taxpayer), caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
4 tool updates
- Changed
find_company_by_domain2 fields changed- added
Output schema / properties / returnedAdded value: +{ + "description": "Rows in results. Every list answer carries it with this one meaning.", + "type": [ + "integer", + "null" + ] +} - changed
Output schema / properties / total / descriptionPrevious value: -"Number of company records returned (at most 5)."New value: +"Number of company records returned (at most 5); the same as returned."
- Changed
lookup_business2 fields changed- added
Output schema / properties / returnedAdded value: +{ + "description": "Rows in results. Every list answer carries it with this one meaning.", + "type": [ + "integer", + "null" + ] +} - changed
Output schema / properties / total / descriptionPrevious value: -"Rows returned in this answer (at most max_results), not the number of firms that match."New value: +"Rows returned in this answer (at most max_results), not the number of firms that match; the same as returned (kept: the published v1 field)."
- Changed
lookup_by_category2 fields changed- added
Output schema / properties / returnedAdded value: +{ + "description": "Rows in results. Every list answer carries it with this one meaning.", + "type": [ + "integer", + "null" + ] +} - changed
Output schema / properties / total / descriptionPrevious value: -"Rows returned in this answer (at most max_results), not the size of the match set: a full page (total == max_results) may have more; narrow the filters or raise max_results."New value: +"Rows returned in this answer (at most max_results), not the size of the match set: a full page (total == max_results) may have more; narrow the filters or raise max_results. The same as returned; the size of the whole list is matchTotal."
- Changed
lookup_director1 field changed- changed
Output schema / properties / returned / descriptionPrevious value: -"Number of companies returned."New value: +"Rows in results. Every list answer carries it with this one meaning."
8 tool updates
- Changed
enrich_company1 field changed- changed
Output schema / properties / company / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
find_company_by_domain1 field changed- changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_business1 field changed- changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_by_category9 fields changed- changed
Input schema / properties / main_activity_only / descriptionPrevious value: -"true keeps firms whose declared main activity (ANAF main CAEN, else the CAEN on the latest filing) is one of the codes, instead of any authorised activity (default false)."New value: +"Default false: a firm matches when the code is ANY of its authorised activities (ONRC lists a dozen per firm, most never practised). true keeps only firms whose DECLARED main activity is one of the codes (ANAF main CAEN, else the CAEN on the latest filing): fewer, more relevant firms. The Leadgen app's lists use true by default." - added
Input schema / properties / sortAdded value: +{ + "default": "newest", + "description": "Order of the results: 'newest' registrations first (default), 'revenue' (latest filing's turnover, biggest first) or 'employees' (headcount, biggest first); firms without a filing come last.", + "enum": [ + "newest", + "revenue", + "employees" + ], + "title": "Sort", + "type": "string" +} - changed
Output schema / descriptionPrevious value: -"A lead list: firms in an activity, newest registration first."New value: +"A lead list: firms in an activity, newest registration first (or by turnover / headcount: sort)." - added
Output schema / properties / caenNamesAdded value: +{ + "description": "The CAEN codes as asked, named: [{code, title (Romanian), titleEn}].", + "type": [ + "array", + "null" + ] +} - added
Output schema / properties / matchTotalAdded value: +{ + "description": "How many firms the whole list holds with every filter (active_only on; null when off): exact, or estimated when matchTotalApproximate is true.", + "type": [ + "integer", + "null" + ] +} - added
Output schema / properties / matchTotalApproximateAdded value: +{ + "description": "true when matchTotal is estimated (matchTotalMargin: its 99% margin).", + "type": [ + "boolean", + "null" + ] +} - added
Output schema / properties / matchTotalMarginAdded value: +{ + "description": "The 99% margin of an estimated matchTotal.", + "type": [ + "integer", + "null" + ] +} - changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)." - added
Output schema / properties / sortAdded value: +{ + "description": "The order of results: newest, revenue or employees.", + "type": [ + "string", + "null" + ] +}
- Changed
lookup_companies1 field changed- changed
Output schema / properties / results / items / properties / company / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_director1 field changed- changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
match_companies1 field changed- changed
Output schema / properties / results / items / properties / company / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
unwatch2 fields changed- added
Output schema / properties / asOfAdded value: +{ + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] +} - added
Output schema / properties / attributionAdded value: +{ + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] +}
10 tool updates
- Changed
find_company_by_domain2 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url)." - changed
Output schema / properties / candidates / descriptionPrevious value: -"When not found: up to 3 firms whose name matches the page title."New value: +"When not found (also when the site cannot be read): up to 3 firms whose name matches the page title or the domain name, each with a confidence (at most 0.7)."
- Changed
lookup_business2 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url)." - changed
Output schema / properties / total / descriptionPrevious value: -"Number of companies returned."New value: +"Rows returned in this answer (at most max_results), not the number of firms that match."
- Changed
lookup_by_category6 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url)." - changed
Input schema / properties / county / descriptionPrevious value: -"Optional county name to narrow to (diacritic-insensitive: 'bucuresti', 'cluj'); omit for nationwide."New value: +"Optional county to narrow to (diacritic-insensitive: 'bucuresti', 'cluj'; a county town such as 'Cluj-Napoca' or a Bucharest sector is read as its county); omit for nationwide. An unknown county is an error (unknown_county) with suggestions, not 0 firms." - added
Output schema / properties / availableTopicNamesAdded value: +{ + "description": "Each curated topic id with its name, e.g. {\"agriculture\": \"Agriculture & Food\"}, next to availableTopics.", + "type": [ + "object", + "null" + ] +} - changed
Output schema / properties / availableTopics / descriptionPrevious value: -"The curated topics, when the topic is unknown."New value: +"The curated topic ids, when the topic is unknown or ambiguous." - changed
Output schema / properties / total / descriptionPrevious value: -"Number of companies returned."New value: +"Rows returned in this answer (at most max_results), not the size of the match set: a full page (total == max_results) may have more; narrow the filters or raise max_results." - changed
Output schema / properties / truncated / descriptionPrevious value: -"true when more firms match than were returned."New value: +"true when max_results was cut to the list cap (and the list is full)."
- Changed
lookup_companies1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url)."
- Changed
lookup_director1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url)."
- Changed
match_companies1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url)."
- Changed
poll_watchlist2 fields changed- added
Output schema / properties / activeAdded value: +{ + "description": "Every watch you hold, changed or not: kind (company or caen), target (CUI or code), county, since, name. Remove one with unwatch.", + "type": [ + "array", + "null" + ] +} - added
Output schema / properties / attributionAdded value: +{ + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] +}
- Added
unwatch - Changed
watch_caen1 field changed- added
Output schema / properties / attributionAdded value: +{ + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] +}
- Changed
watch_company1 field changed- added
Output schema / properties / attributionAdded value: +{ + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] +}
7 tool updates
- Changed
enrich_company1 field changed- changed
Output schema / properties / company / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
find_company_by_domain2 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)." - changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_business2 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)." - changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_by_category3 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)." - added
Output schema / properties / appUrlAdded value: +{ + "description": "The same list opened in the Leadgen app (CAEN codes, county, legal form, active and main-activity filters), to share with the user; null when the app cannot open it (more than 10 codes, a legal form it does not offer).", + "type": [ + "string", + "null" + ] +} - changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_companies2 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)." - changed
Output schema / properties / results / items / properties / company / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
lookup_director2 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)." - changed
Output schema / properties / results / items / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
- Changed
match_companies2 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount, record url)." - changed
Output schema / properties / results / items / properties / company / descriptionPrevious value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
16 tool updates
- Changed
enrich_company5 fields changed- added
Input schema / properties / cui / descriptionAdded value: +"Romanian tax identification number (CUI), e.g. '2816464'; 'RO' and leading zeros are accepted." - added
Input schema / properties / max_pages / descriptionAdded value: +"Maximum number of pages to crawl (1-20, default 5)." - added
Input schema / properties / refresh / descriptionAdded value: +"true crawls now even if a cached result exists (default false: answer from the cache when there is one)." - added
Input schema / properties / website / descriptionAdded value: +"Optional website override (domain or URL). When omitted, the firm's registered website is used (an error if none is on file)." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "The firm's registry record plus the contacts found on its website.", + "properties": { + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "cacheHit": { + "description": "true when answered from the cache.", + "type": [ + "boolean", + "null" + ] + }, + "company": { + "additionalProperties": true, + "description": "A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys.", + "type": "object" + }, + "contacts": { + "description": "Contacts found, each with type, value, confidence and source.", + "type": [ + "array", + "null" + ] + }, + "crawlError": { + "description": "Why the crawl failed, if it did.", + "type": [ + "string", + "null" + ] + }, + "crawled": { + "description": "true when the site was crawled for this answer.", + "type": [ + "boolean", + "null" + ] + }, + "cui": { + "description": "The firm's CUI.", + "type": [ + "string", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "pagesCrawled": { + "description": "Pages read.", + "type": [ + "integer", + "null" + ] + }, + "website": { + "description": "The website crawled.", + "type": [ + "string", + "null" + ] + }, + "websiteSource": { + "description": "Where the website came from: registry or override.", + "type": [ + "string", + "null" + ] + } + }, + "type": "object" +}
- Changed
extract_contacts3 fields changed- added
Input schema / properties / max_pages / descriptionAdded value: +"Maximum number of pages to crawl (1-20, default 5)." - added
Input schema / properties / website / descriptionAdded value: +"The website to crawl: a bare domain ('example.com') or a full URL ('https://example.com')." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Contacts found on a website.", + "properties": { + "domain": { + "description": "The site's registrable domain.", + "type": [ + "string", + "null" + ] + }, + "emails": { + "description": "Addresses on the site's own domain.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "facebook": { + "description": "Facebook profile.", + "type": [ + "string", + "null" + ] + }, + "github": { + "description": "GitHub profile.", + "type": [ + "string", + "null" + ] + }, + "instagram": { + "description": "Instagram profile.", + "type": [ + "string", + "null" + ] + }, + "linkedin": { + "description": "LinkedIn page.", + "type": [ + "string", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "otherEmails": { + "description": "Other addresses found on the site.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "pagesCrawled": { + "description": "Pages read.", + "type": [ + "integer", + "null" + ] + }, + "phones": { + "description": "Phone numbers found.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "socialLinks": { + "description": "Every social link found, best first.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "twitter": { + "description": "X / Twitter profile.", + "type": [ + "string", + "null" + ] + }, + "url": { + "description": "The start URL crawled.", + "type": [ + "string", + "null" + ] + }, + "youtube": { + "description": "YouTube channel.", + "type": [ + "string", + "null" + ] + } + }, + "type": "object" +}
- Changed
find_company_by_domain2 fields changed- added
Input schema / properties / domain / descriptionAdded value: +"The website's domain ('dedeman.ro'); a URL or a www. host is reduced to it. Public domains only." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "The firm behind a website domain, or why none was found.", + "properties": { + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "attribution": { + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] + }, + "candidates": { + "description": "When not found: up to 3 firms whose name matches the page title.", + "type": [ + "array", + "null" + ] + }, + "domain": { + "description": "The normalised domain.", + "type": [ + "string", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "fields": { + "description": "The company fields kept when fields or compact trimmed the rows.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "found": { + "description": "Whether a firm was identified.", + "type": [ + "boolean", + "null" + ] + }, + "match": { + "description": "The identified firm: cui, companyName, matchedOn.", + "type": [ + "object", + "null" + ] + }, + "matchedOn": { + "description": "registry_website, site_cui or site_registration_code.", + "type": [ + "string", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "reason": { + "description": "When not found: no_cui_on_site or site_unreachable.", + "type": [ + "string", + "null" + ] + }, + "results": { + "description": "The company records, best first.", + "items": { + "additionalProperties": true, + "description": "A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys.", + "type": "object" + }, + "type": [ + "array", + "null" + ] + }, + "site": { + "description": "What was read from the site: url, pagesRead, title, cuis, registrationCodes, error.", + "type": [ + "object", + "null" + ] + }, + "total": { + "description": "Number of company records returned (at most 5).", + "type": [ + "integer", + "null" + ] + }, + "warnings": { + "description": "Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field).", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
get_usage1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Your plan, daily allowance and what is left today.", + "properties": { + "counted": { + "description": "Always false: this call is not counted.", + "type": [ + "boolean", + "null" + ] + }, + "daily_limit": { + "description": "Lookups allowed per UTC day.", + "type": [ + "integer", + "null" + ] + }, + "entitlements": { + "description": "What the plan includes.", + "type": [ + "object", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "identity": { + "description": "Who is counted: kind (key or anonymous) and counted_as.", + "type": [ + "object", + "null" + ] + }, + "links": { + "description": "get_a_key, pricing, docs.", + "type": [ + "object", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "plan": { + "description": "Plan name (free, pro, business).", + "type": [ + "string", + "null" + ] + }, + "remaining": { + "description": "Lookups left today.", + "type": [ + "integer", + "null" + ] + }, + "resets_at": { + "description": "When the allowance resets (ISO 8601, 00:00 UTC).", + "type": [ + "string", + "null" + ] + }, + "resets_in_seconds": { + "description": "Seconds until the reset.", + "type": [ + "integer", + "null" + ] + }, + "suspended": { + "description": "true when the key is suspended.", + "type": [ + "boolean", + "null" + ] + }, + "used_today": { + "description": "Lookups used today.", + "type": [ + "integer", + "null" + ] + } + }, + "type": "object" +}
- Changed
lookup_business4 fields changed- added
Input schema / properties / county / descriptionAdded value: +"Optional county hint (diacritic-insensitive): firms registered there rank higher. Not a filter." - added
Input schema / properties / max_results / descriptionAdded value: +"Maximum number of companies to return (1-100, default 10)." - added
Input schema / properties / query / descriptionAdded value: +"Company name or CUI (tax ID) to search for. Names are diacritic-insensitive ('paval' finds PAVĂL); a CUI ('2816464', 'RO2816464') matches exactly." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Ranked companies for a name, or the firm with that CUI.", + "properties": { + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "attribution": { + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] + }, + "county": { + "description": "The county hint, if one was given.", + "type": [ + "string", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "fields": { + "description": "The company fields kept when fields or compact trimmed the rows.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "found": { + "description": "false when a well-formed CUI is not in the snapshot.", + "type": [ + "boolean", + "null" + ] + }, + "hint": { + "description": "When a name search finds nothing but reads like a category question: the lookup_by_category call that answers it.", + "type": [ + "object", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "query": { + "description": "The query as given.", + "type": [ + "string", + "null" + ] + }, + "reason": { + "description": "Why nothing was found (not_found).", + "type": [ + "string", + "null" + ] + }, + "results": { + "description": "The company records, best first.", + "items": { + "additionalProperties": true, + "description": "A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys.", + "type": "object" + }, + "type": [ + "array", + "null" + ] + }, + "source": { + "description": "Data source: onrc (registry) or mfp (Ministry of Finance filings).", + "type": [ + "string", + "null" + ] + }, + "total": { + "description": "Number of companies returned.", + "type": [ + "integer", + "null" + ] + }, + "warnings": { + "description": "Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field).", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
lookup_by_category13 fields changed- added
Input schema / properties / active_only / descriptionAdded value: +"Default true: drop firms that are not a lead (struck off, dissolving, in liquidation, insolvent or bankrupt, activity suspended, or ANAF fiscally inactive). false returns every firm." - added
Input schema / properties / county / descriptionAdded value: +"Optional county name to narrow to (diacritic-insensitive: 'bucuresti', 'cluj'); omit for nationwide." - added
Input schema / properties / has_website / descriptionAdded value: +"true keeps only firms with a website on file in the registry (default false)." - added
Input schema / properties / legal_form / descriptionAdded value: +"Optional legal form(s) to keep, comma-separated, case-insensitive: 'SRL', 'SA', 'PFA', 'II', or 'SRL,SA' (companies, no sole traders). Default: any form." - added
Input schema / properties / main_activity_only / descriptionAdded value: +"true keeps firms whose declared main activity (ANAF main CAEN, else the CAEN on the latest filing) is one of the codes, instead of any authorised activity (default false)." - added
Input schema / properties / max_employees / descriptionAdded value: +"Optional maximum average headcount on the latest filing." - added
Input schema / properties / max_results / descriptionAdded value: +"Maximum number of companies to return (1-100, default 10)." - added
Input schema / properties / max_revenue / descriptionAdded value: +"Optional maximum net turnover in RON on the latest filing." - added
Input schema / properties / min_employees / descriptionAdded value: +"Optional minimum average headcount on the latest filing." - added
Input schema / properties / min_revenue / descriptionAdded value: +"Optional minimum net turnover in RON on the latest filing (FY2025, else FY2024). Firms without a filing never match a band." - added
Input schema / properties / topic / descriptionAdded value: +"What the firms do: a curated topic ('software', 'retail'), plain words for a trade ('dentists', 'stomatologie'), a CAEN class title in Romanian or English, or CAEN codes ('6201' or '4321,4322'). Case-, space- and diacritic-insensitive. A number that names another activity in each revision takes a suffix: '4781r3' (Rev.3) or '4781r2' (Rev.2)." - added
Input schema / properties / vat_payer / descriptionAdded value: +"Optional: true keeps VAT-registered firms only, false only non-VAT payers (ANAF data). Omit for both." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A lead list: firms in an activity, newest registration first.", + "properties": { + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "attribution": { + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] + }, + "availableTopics": { + "description": "The curated topics, when the topic is unknown.", + "type": [ + "array", + "null" + ] + }, + "caenCodes": { + "description": "The CAEN codes searched, when given or derived as codes.", + "type": [ + "array", + "null" + ] + }, + "candidates": { + "description": "When the words fit several activities (ambiguous_topic): the ones to choose from.", + "type": [ + "array", + "null" + ] + }, + "codesAdded": { + "description": "CAEN Rev.2/Rev.3 counterparts added to the search.", + "type": [ + "array", + "null" + ] + }, + "county": { + "description": "The county filter, if any.", + "type": [ + "string", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "fields": { + "description": "The company fields kept when fields or compact trimmed the rows.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "filters": { + "description": "The filters applied (legalForm, activeOnly, revenue and headcount bands, vatPayer, mainActivityOnly ...).", + "type": [ + "object", + "null" + ] + }, + "inactiveFilteredOut": { + "description": "Firms removed by active_only (null when off).", + "type": [ + "integer", + "null" + ] + }, + "inactiveFilteredOutApproximate": { + "description": "true when that count is estimated.", + "type": [ + "boolean", + "null" + ] + }, + "label": { + "description": "Human label of what was matched.", + "type": [ + "string", + "null" + ] + }, + "matched": { + "description": "How plain words were read: by, niche or class title, codes.", + "type": [ + "object", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "query": { + "description": "The topic as given.", + "type": [ + "string", + "null" + ] + }, + "results": { + "description": "The company records, best first.", + "items": { + "additionalProperties": true, + "description": "A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys.", + "type": "object" + }, + "type": [ + "array", + "null" + ] + }, + "source": { + "description": "Data source: onrc (registry) or mfp (Ministry of Finance filings).", + "type": [ + "string", + "null" + ] + }, + "topic": { + "description": "The curated topic matched, if any.", + "type": [ + "string", + "null" + ] + }, + "total": { + "description": "Number of companies returned.", + "type": [ + "integer", + "null" + ] + }, + "truncated": { + "description": "true when more firms match than were returned.", + "type": [ + "boolean", + "null" + ] + }, + "warnings": { + "description": "Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field).", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
lookup_companies2 fields changed- added
Input schema / properties / cuis / descriptionAdded value: +"Up to 100 CUIs, as a list or one comma-separated string ('RO', spaces and leading zeros accepted, as in lookup_business)." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "One result per input CUI, in input order.", + "properties": { + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "attribution": { + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "errors": { + "description": "Rows that are input errors (empty, not a CUI, wrong control digit).", + "type": [ + "integer", + "null" + ] + }, + "fields": { + "description": "The company fields kept when fields or compact trimmed the rows.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "found": { + "description": "Rows that matched a firm.", + "type": [ + "integer", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "metering": { + "description": "What the batch cost: rows, counted, notCounted (input-error rows are not counted) and the rule.", + "type": [ + "object", + "null" + ] + }, + "notFound": { + "description": "Well-formed CUIs not in the snapshot.", + "type": [ + "integer", + "null" + ] + }, + "results": { + "description": "Per input: input, cui, found, and company (the record) or error/reason.", + "items": { + "additionalProperties": true, + "description": "One input row's answer.", + "properties": { + "company": { + "additionalProperties": true, + "description": "A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys.", + "type": "object" + }, + "cui": { + "description": "The normalised CUI.", + "type": [ + "string", + "null" + ] + }, + "found": { + "description": "Whether a firm has this CUI.", + "type": [ + "boolean", + "null" + ] + }, + "input": { + "description": "The value as given.", + "type": [ + "string", + "null" + ] + } + }, + "type": "object" + }, + "type": [ + "array", + "null" + ] + }, + "source": { + "description": "Data source: onrc (registry) or mfp (Ministry of Finance filings).", + "type": [ + "string", + "null" + ] + }, + "total": { + "description": "Number of input rows.", + "type": [ + "integer", + "null" + ] + }, + "warnings": { + "description": "Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field).", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
lookup_director4 fields changed- added
Input schema / properties / max_results / descriptionAdded value: +"Maximum number of companies to return (1-100, default 10)." - added
Input schema / properties / name / descriptionAdded value: +"Director / representative name to search for (e.g. 'Ion Popescu'); diacritic-insensitive, each word a whole word of the name." - added
Input schema / properties / prefix / descriptionAdded value: +"true matches each word as a prefix ('pop' also finds POPA, POPESCU); default false (whole words)." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Firms where a person with this name is director or representative.", + "properties": { + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "attribution": { + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] + }, + "byCounty": { + "description": "Matching firms per county.", + "type": [ + "object", + "null" + ] + }, + "distinctCounties": { + "description": "Number of counties the matches are in.", + "type": [ + "integer", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "fields": { + "description": "The company fields kept when fields or compact trimmed the rows.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "homonyms": { + "description": "true when the matches span several counties (likely several people).", + "type": [ + "boolean", + "null" + ] + }, + "match": { + "description": "words (whole words) or prefix.", + "type": [ + "string", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "What homonyms means for this name.", + "type": [ + "string", + "null" + ] + }, + "query": { + "description": "The name as given.", + "type": [ + "string", + "null" + ] + }, + "results": { + "description": "The company records, best first.", + "items": { + "additionalProperties": true, + "description": "A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys.", + "type": "object" + }, + "type": [ + "array", + "null" + ] + }, + "returned": { + "description": "Number of companies returned.", + "type": [ + "integer", + "null" + ] + }, + "source": { + "description": "Data source: onrc (registry) or mfp (Ministry of Finance filings).", + "type": [ + "string", + "null" + ] + }, + "total": { + "description": "Every matching firm, not just the rows returned.", + "type": [ + "integer", + "null" + ] + }, + "totalIsLowerBound": { + "description": "true when the scan stopped early and total is a minimum.", + "type": [ + "boolean", + "null" + ] + }, + "warnings": { + "description": "Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field).", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
lookup_domain4 fields changed- added
Input schema / properties / domain / descriptionAdded value: +"Domain name to look up (e.g. 'example.com'); a URL is reduced to its host." - added
Input schema / properties / include_dns / descriptionAdded value: +"Include DNS records (A, AAAA, MX, NS, TXT, SOA); default true." - added
Input schema / properties / include_security / descriptionAdded value: +"Include the SPF/DMARC email-security check; default true." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "WHOIS, DNS records and the SPF/DMARC audit of a domain.", + "properties": { + "dns": { + "description": "Records by type: A, AAAA, MX, NS, TXT, SOA.", + "type": [ + "object", + "null" + ] + }, + "domain": { + "description": "The normalised domain.", + "type": [ + "string", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "resolvedIP": { + "description": "An address the domain resolves to.", + "type": [ + "string", + "null" + ] + }, + "security": { + "description": "hasSPF, spf, hasDMARC, dmarc.", + "type": [ + "object", + "null" + ] + }, + "whois": { + "description": "registrar, creationDate, expirationDate, updatedDate, nameServers, registrantOrg, registrantCountry.", + "type": [ + "object", + "null" + ] + } + }, + "type": "object" +}
- Changed
lookup_financial_ratios2 fields changed- added
Input schema / properties / cui / descriptionAdded value: +"Romanian tax identification number (CUI), e.g. '2816464'; 'RO' and leading zeros are accepted." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Derived financial intelligence and a verdict.", + "properties": { + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "attribution": { + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] + }, + "cui": { + "description": "The firm's CUI.", + "type": [ + "string", + "null" + ] + }, + "distress": { + "description": "true when the distress signals fire.", + "type": [ + "boolean", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "flags": { + "description": "Red flags.", + "type": [ + "array", + "null" + ] + }, + "found": { + "description": "Whether any filing is on record.", + "type": [ + "boolean", + "null" + ] + }, + "headcount": { + "description": "Latest headcount and its change.", + "type": [ + "object", + "null" + ] + }, + "healthScore": { + "description": "0-100 score, band and its rule-by-rule components.", + "type": [ + "object", + "null" + ] + }, + "history": { + "description": "Years on record, loss years, revenue peak.", + "type": [ + "object", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "peers": { + "description": "Percentiles within the same CAEN activity and county.", + "type": [ + "object", + "null" + ] + }, + "ratios": { + "description": "Margins, equity ratio, debt to equity, liquidity, returns.", + "type": [ + "object", + "null" + ] + }, + "revenueTrend": { + "description": "Latest revenue, YoY growth, 3/5/10-year CAGR, trend label.", + "type": [ + "object", + "null" + ] + }, + "signals": { + "description": "The distress signals found.", + "type": [ + "array", + "null" + ] + }, + "source": { + "description": "Data source: onrc (registry) or mfp (Ministry of Finance filings).", + "type": [ + "string", + "null" + ] + }, + "total": { + "description": "Number of fiscal years used.", + "type": [ + "integer", + "null" + ] + }, + "verdict": { + "description": "growing, stable or distressed.", + "type": [ + "string", + "null" + ] + }, + "years": { + "description": "Per fiscal year figures and margins.", + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
lookup_financials2 fields changed- added
Input schema / properties / cui / descriptionAdded value: +"Romanian tax identification number (CUI), e.g. '2816464'; 'RO' and leading zeros are accepted." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Every annual filing on record for the firm, newest first (RON).", + "properties": { + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "attribution": { + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] + }, + "cui": { + "description": "The firm's CUI.", + "type": [ + "string", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "found": { + "description": "Whether any filing is on record.", + "type": [ + "boolean", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "source": { + "description": "Data source: onrc (registry) or mfp (Ministry of Finance filings).", + "type": [ + "string", + "null" + ] + }, + "summary": { + "description": "History, revenue growth (3/5/10-year CAGR), latest ratios, health score and band, flags.", + "type": [ + "object", + "null" + ] + }, + "total": { + "description": "Number of fiscal years returned.", + "type": [ + "integer", + "null" + ] + }, + "years": { + "description": "Per fiscal year: revenue, profit, loss, netResult, employees, assets, debt, equity (RON) and that year's ratios.", + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
match_companies7 fields changed- added
Input schema / $defs / MatchRow / properties / county / descriptionAdded value: +"Optional county hint (diacritic-insensitive): firms there rank higher." - added
Input schema / $defs / MatchRow / properties / cui / descriptionAdded value: +"Optional CUI (tax code); a valid one wins (confidence 1.0)." - added
Input schema / $defs / MatchRow / properties / domain / descriptionAdded value: +"Optional website domain ('dedeman.ro'), matched to the registry's website field." - added
Input schema / $defs / MatchRow / properties / name / descriptionAdded value: +"Company name (diacritic-insensitive; legal-form words ignored)." - added
Input schema / $defs / MatchRow / properties / ref / descriptionAdded value: +"Your own id for the row, echoed back unchanged." - added
Input schema / properties / rows / descriptionAdded value: +"Up to 500 records, each {name, county, domain, cui, ref} (any of them; ref is your own id, echoed back), or a bare string (a CUI, a domain or a name)." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "One match per input record, in input order.", + "properties": { + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "attribution": { + "description": "The credit line to keep when redistributing the data (CC BY 4.0).", + "type": [ + "string", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "errors": { + "description": "Rows that are input errors (nothing to match on).", + "type": [ + "integer", + "null" + ] + }, + "fields": { + "description": "The company fields kept when fields or compact trimmed the rows.", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "matched": { + "description": "Rows matched to a firm.", + "type": [ + "integer", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "metering": { + "description": "What the batch cost: rows, counted, notCounted (input-error rows are not counted) and the rule.", + "type": [ + "object", + "null" + ] + }, + "noMatch": { + "description": "Rows with no match above the threshold.", + "type": [ + "integer", + "null" + ] + }, + "results": { + "description": "Per row: row, input, status (matched or no_match), match {cui, companyName, confidence, matchedOn}, company, or candidates.", + "items": { + "additionalProperties": true, + "description": "One input row's answer.", + "properties": { + "candidates": { + "description": "Best candidates when no_match.", + "type": [ + "array", + "null" + ] + }, + "company": { + "additionalProperties": true, + "description": "A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys.", + "type": "object" + }, + "input": { + "description": "The row as read: name, county, domain, cui, ref.", + "type": [ + "object", + "null" + ] + }, + "match": { + "description": "The firm matched: cui, companyName, confidence, matchedOn.", + "type": [ + "object", + "null" + ] + }, + "ref": { + "description": "Your own id for the row, echoed back.", + "type": [ + "string", + "null" + ] + }, + "row": { + "description": "Position of the row in the input (0-based).", + "type": [ + "integer", + "null" + ] + }, + "status": { + "description": "matched, no_match, or an error status.", + "type": [ + "string", + "null" + ] + } + }, + "type": "object" + }, + "type": [ + "array", + "null" + ] + }, + "source": { + "description": "Data source: onrc (registry) or mfp (Ministry of Finance filings).", + "type": [ + "string", + "null" + ] + }, + "threshold": { + "description": "Confidence a row needs to be matched (0-1).", + "type": [ + "number", + "null" + ] + }, + "total": { + "description": "Number of input rows.", + "type": [ + "integer", + "null" + ] + }, + "warnings": { + "description": "Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field).", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
poll_watchlist1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "What changed for your watches since the last poll, most severe first.", + "properties": { + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "email_alerts": { + "description": "How to get the same changes by email.", + "type": [ + "string", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "ok": { + "description": "true when the poll ran.", + "type": [ + "boolean", + "null" + ] + }, + "owner": { + "description": "Whose watches these are (key prefix or IP).", + "type": [ + "string", + "null" + ] + }, + "total": { + "description": "Number of watches with news.", + "type": [ + "integer", + "null" + ] + }, + "watches": { + "description": "Per watch: an 'updated' company with its changed fields and risk, or the 'new' firms registered in a watched activity.", + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
report_issue5 fields changed- added
Input schema / properties / contact / descriptionAdded value: +"Optional email address for a reply; nothing is mailed to it automatically." - added
Input schema / properties / cui / descriptionAdded value: +"Optional CUI of the firm the report is about (for 'wrong_record')." - added
Input schema / properties / kind / descriptionAdded value: +"One of 'gap' (a missing field, firm or source; the default), 'wrong_record' (pass its cui), 'bug', 'idea', 'other'." - added
Input schema / properties / message / descriptionAdded value: +"The report, in plain words: what is missing or wrong." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "The receipt for the report.", + "properties": { + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "id": { + "description": "The report's id.", + "type": [ + "integer", + "null" + ] + }, + "kind": { + "description": "The kind filed.", + "type": [ + "string", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "For wrong_record: how registry records get corrected.", + "type": [ + "string", + "null" + ] + }, + "status": { + "description": "received.", + "type": [ + "string", + "null" + ] + } + }, + "type": "object" +}
- Changed
watch_caen3 fields changed- added
Input schema / properties / code / descriptionAdded value: +"CAEN activity code to watch (e.g. '6210'); a retired Rev.2 code also watches its Rev.3 successor." - added
Input schema / properties / county / descriptionAdded value: +"Optional county name to scope the watch to (diacritic-insensitive); omit to watch nationwide." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "The watch registered (or already held) for the activity code.", + "properties": { + "alreadyWatching": { + "description": "true when you already held this watch (nothing changed).", + "type": [ + "boolean", + "null" + ] + }, + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "ok": { + "description": "true when the watch is in place.", + "type": [ + "boolean", + "null" + ] + }, + "warnings": { + "description": "Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field).", + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "watch": { + "description": "kind, target, owner (key prefix), county, baseline.", + "type": [ + "object", + "null" + ] + } + }, + "type": "object" +}
- Changed
watch_company2 fields changed- added
Input schema / properties / cui / descriptionAdded value: +"Romanian tax identification number (CUI) of the firm to watch, e.g. '2816464'. Watching a firm you already watch changes nothing." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "The watch registered (or already held) for the firm.", + "properties": { + "alreadyWatching": { + "description": "true when you already held this watch (nothing changed).", + "type": [ + "boolean", + "null" + ] + }, + "asOf": { + "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.", + "type": [ + "object", + "null" + ] + }, + "error": { + "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.", + "type": [ + "string", + "null" + ] + }, + "message": { + "description": "A sentence for the caller.", + "type": [ + "string", + "null" + ] + }, + "ok": { + "description": "true when the watch is in place.", + "type": [ + "boolean", + "null" + ] + }, + "watch": { + "description": "kind, target, owner (key prefix), county, baseline.", + "type": [ + "object", + "null" + ] + } + }, + "type": "object" +}
7 tool updates
- Added
find_company_by_domain - Changed
lookup_business2 fields changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount).", + "title": "Compact", + "type": "boolean" +} - added
Input schema / properties / fieldsAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional: keep only these company fields in each row, comma-separated (companyName,cui,county,risk; dotted paths such as risk.level work). Without it the full record is returned.", + "title": "Fields" +}
- Changed
lookup_by_category2 fields changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount).", + "title": "Compact", + "type": "boolean" +} - added
Input schema / properties / fieldsAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional: keep only these company fields in each row, comma-separated (companyName,cui,county,risk; dotted paths such as risk.level work). Without it the full record is returned.", + "title": "Fields" +}
- Added
lookup_companies - Changed
lookup_director2 fields changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount).", + "title": "Compact", + "type": "boolean" +} - added
Input schema / properties / fieldsAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional: keep only these company fields in each row, comma-separated (companyName,cui,county,risk; dotted paths such as risk.level work). Without it the full record is returned.", + "title": "Fields" +}
- Added
match_companies - Added
report_issue
2 tool updates
- Changed
lookup_business1 field changed- added
Input schema / properties / countyAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "County" +}
- Changed
lookup_director1 field changed- added
Input schema / properties / prefixAdded value: +{ + "default": false, + "title": "Prefix", + "type": "boolean" +}
1 tool update
- Added
get_usage
1 tool update
- Changed
lookup_by_category6 fields changed- added
Input schema / properties / main_activity_onlyAdded value: +{ + "default": false, + "title": "Main Activity Only", + "type": "boolean" +} - added
Input schema / properties / max_employeesAdded value: +{ + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Max Employees" +} - added
Input schema / properties / max_revenueAdded value: +{ + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Max Revenue" +} - added
Input schema / properties / min_employeesAdded value: +{ + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Min Employees" +} - added
Input schema / properties / min_revenueAdded value: +{ + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Min Revenue" +} - added
Input schema / properties / vat_payerAdded value: +{ + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Vat Payer" +}
1 tool update
- Changed
enrich_company1 field changed- added
Input schema / properties / refreshAdded value: +{ + "default": false, + "title": "Refresh", + "type": "boolean" +}
1 tool update
- Changed
lookup_by_category3 fields changed- added
Input schema / properties / active_onlyAdded value: +{ + "default": true, + "title": "Active Only", + "type": "boolean" +} - added
Input schema / properties / has_websiteAdded value: +{ + "default": false, + "title": "Has Website", + "type": "boolean" +} - added
Input schema / properties / legal_formAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Legal Form" +}
Related MCP Connectors
Romanian companies: ONRC registry, ANAF financials, VAT, EU/UN/US sanctions, administrator links.
Romanian companies: search, CUI risk verdict and prospect lists from official ONRC, ANAF, MF data.
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.
Related MCP Servers
- AlicenseAqualityBmaintenanceRomanian public data with no API keys: ANAF company status by CUI (VAT, fiscally inactive, deregistered), filed financial statements, Portal Just court cases and BNR exchange rates. Includes shop_check, which flags whether an online shop looks like a scam.6MIT
- AlicenseAqualityBmaintenanceProvides keyless access to Romanian public economic and cultural data, including exchange rates, company/VAT lookups, open datasets, official statistics, seismic-risk building records, and classified cultural heritage.12MIT
- AlicenseAqualityCmaintenanceStructured business intelligence for AI agents. 11.3M verified entities, 40.3M BORME mercantile acts, EU VAT validation (VIES), GLEIF LEI and healthcare registries. 12 tools.61MIT
- AlicenseNot gradedqualityBmaintenanceFrench company data for AI agents: directors with probable business email, people search, counterparty checks (KYB) and hiring signals from official registries. Paid per call with x402 (USDC on Base or Solana), charged only when found.1,321 npmMIT
Glama MCP Gateway
Add one secure layer between your agents and this server.