Leadgen MCP

Look up many companies by CUI

lookup_companies

Read-onlyIdempotent

Look up up to 100 Romanian companies by CUI in one call, returning one result per input in order with found status and company record.

Instructions

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 counts as one lookup; a batch larger than what is left today is refused whole. fields or compact trims each record.

Input Schema

Name	Required	Description
`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.
`results`	No	Per input: input, cui, found, and company (the record) or error/reason.
`metering`	No	What the batch cost: rows, counted, notCounted (input-error rows are not counted) 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).
`attribution`	No	The credit line to keep when redistributing the data (CC BY 4.0).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.3Oct 19, 2026

changedInput schema / properties / compact / description

Previous 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 and what it did not check, phone, website, latest revenue and headcount, record url)."

changedOutput schema / properties / results / items / properties / company / description

Previous 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 (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)."

First observedv0.1.0Oct 17, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, so the description's added value is the quota accounting ('each row counts as one lookup'), the atomic whole-batch refusal, the per-row found flag, and the input-order guarantee — real operational context beyond the schema. It doesn't say whether refused batches surface as an error vs a partial result.

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

Conciseness5/5

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

Dense but front-loaded: batch scope, per-row semantics, quota rule, and trimming flags in order of importance, with no filler sentences.

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

Completeness4/5

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

An output schema exists so return shapes need no explanation, and the description covers ordering, the found flag, and quota failure. The one gap is what happens on invalid or unknown CUIs within the batch, and how the whole-batch refusal is reported.

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

Parameters3/5

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

Schema description coverage is 100%, so cuis, fields, and compact are already fully documented, including accepted CUI formats and dotted paths. The description only echoes that fields/compact trim each record, adding no syntax beyond the schema; baseline 3 applies.

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

Purpose5/5

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

States a specific verb (look up), resource (Romanian companies by CUI), and batch scope (up to 100, one result per input) that clearly separates it from the singular lookup_business sibling it references.

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

Usage Guidelines4/5

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

The 'many ... in one call' framing and the pointer to lookup_business for CUI formatting imply the batch-vs-single choice, and the quota/refusal rule tells the agent when a call will fail. It stops short of explicitly naming when to prefer this over match_companies or other siblings.

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

Deploy Server