Leadgen MCP

Find companies by director

lookup_director

Read-onlyIdempotent

Find Romanian companies by director or legal representative name using ONRC data. Search by person when you do not know the firm, with diacritic-insensitive whole-word or prefix matching.

Instructions

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.

Input Schema

Name	Required	Description
`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	Number of companies returned.
`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.

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 / 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.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description usefully adds matching semantics (diacritic-insensitive, whole-word, prefix option) plus the key ambiguity that one name can map to several people due to no personal ID. It does not mention pagination or result-count behavior beyond the schema's max_results.

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

Conciseness4/5

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

Front-loaded with the core purpose and matching rules, and nearly every sentence carries distinct information. The dangling reference to 'byCounty' as a signal for homonyms is slightly confusing since no such parameter appears in the schema, costing a point.

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

Completeness5/5

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 details are rightly omitted, and the description covers the tricky parts an agent needs: matching semantics, diacritics, prefix behavior, and the one-name-to-many-people caveat. Nothing essential for correct invocation is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already carries parameter meaning and the baseline would be 3. The description earns a point by reinforcing matching behavior with a concrete example ('pop maria' finds POP MARIA, not POPA MARIANA) and explaining the homonym ambiguity that no schema field conveys.

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 and resource with its scope: 'Find Romanian companies by the name of a director or legal representative (ONRC).' This clearly separates it from sibling firm-oriented tools such as find_company_by_domain, 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.

Usage Guidelines4/5

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

'Use this when you know a person rather than a firm' gives a clear selection condition and implicitly excludes firm/domain-based siblings. It does not name a specific alternative tool to switch to, so it stops short of full when/when-not routing.

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

Deploy Server