Companero – Romanian Company Data

search_persons

Keywords: persoană, administrator, asociat, reprezentant legal, lichidator, antreprenor, due diligence, conflict de interese, KYC, ONRC, search person, find administrator, beneficial owner.

Caută o persoană fizică (administrator, asociat, reprezentant legal, lichidator, mandatar) și află în câte firme românești apare. FREE.

Sursa: ONRC Open Data (Registrul Comerțului — Legea 265/2022 privind registrul comerțului). Profilurile sunt construite agregând aparițiile aceleiași persoane în mai multe firme, după nume + (când e public) dată / loc de naștere.

CÂND îl folosești:

"În câte firme apare X?" — caută numele, sortat desc după companyCount, ia top hit, apoi get_person.
"Cine sunt antreprenorii cu cele mai multe firme dintr-un județ?" — filtrează county, sortare implicită desc după companyCount returnează top serial-administratori.
"Persoana X are conflict de interese cu firma Y?" — caută X → get_person → caută taxId-ul Y în lista companiilor.
"X e lichidator / e implicat în insolvență?" — get_person afișează rolurile cu roleCategory: procedural.
KYC / due diligence — verifică structura cross-company a unui beneficiar real.

DEZAMBIGUARE: căutarea EXCLUDE structural clusterele de nume comun fără elemente discriminatorii (cele marcate UNRESOLVED) — pe toate tier-urile, și NU există parametru care să le includă. Ce primești sunt profiluri deja dezambiguate. Pentru nume frecvente pot rămâne totuși mai multe persoane distincte cu același nume: filtrează county sau birthYearFrom/birthYearTo ca să reduci candidații înainte de a cheltui credite pe get_person.

ACCES & COST:

ANONIM: maxim 10 rezultate, doar name + companyCount + profileUrl. Pentru disambiguare completă (an naștere, județ, confidence) — autentifică-te.
AUTENTIFICAT (free): până la 100 rezultate, inclusiv birthYear, knownCounties, occurrenceCount, confidence — toate câmpurile necesare ca LLM să aleagă fără call adițional.
Profilul complet (toate companiile, alias-uri, locul nașterii) e disponibil prin get_person — 1 credit per profil.

Confidence (autentificat):

HIGH: identificare sigură (CNP sau nume + DOB + locul nașterii).
MEDIUM: nume + DOB se potrivesc — probabil aceeași persoană.
LOW: doar nume; nume rar deci puțin probabil să fie altcineva.
UNRESOLVED: nume comun fără elemente discriminatorii — nu apare în rezultatele acestei unelte.

GDPR: niciun CNP nu e returnat. Toate datele provin din publicări legale ONRC.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Free-text name (e.g. "Popescu Ion"). Order-insensitive.
`page`	No	Alias vechi (1-based) pentru `offset`. Folosește `offset`.
`limit`	No	Câte rezultate (1-10 anonim, până la 100 autentificat). Numele canonic, la fel ca la `search_companies` și `search_cities`.
`county`	No	County (residence or birth, fuzzy match). E.g. "Cluj".
`offset`	No	De la al câtelea rezultat. Numele canonic.
`pageSize`	No	Alias vechi pentru `limit`. Folosește `limit`.
`birthYearTo`	No	Inclusive upper bound on year of birth. Authenticated callers only.
`birthYearFrom`	No	Inclusive lower bound on year of birth. Authenticated callers only.
`minConfidence`	No	One of "high","medium","low","unresolved". Filters out lower tiers. Authenticated callers only.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026
- removedInput schema / required
```
Removed value: -[]
```
First observedSep 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses anonymous vs authenticated result fields and limits, that full profiles cost 1 credit via get_person, the meaning of each confidence tier, the ONRC data source, and GDPR handling (no CNP returned). It also explains that common-name UNRESOLVED clusters are excluded before returning results. This is rich, transparent operational context.

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?

The description is long and opens with a keyword list that does little to help an agent select the tool, which weakens front-loading. However, the remaining sections are well-structured with clear headings and dense, useful routing information. Minor verbosity aside, every substantive paragraph earns its place.

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?

Given 9 optional parameters, no annotations, and no output schema, the description is exceptionally complete: it covers purpose, usage, disambiguation, access tiers, cost, confidence semantics, data source, and GDPR. It also explains what fields are returned in each access mode and directs agents to get_person for full profiles. Nothing critical 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 baseline is 3. The description adds meaning beyond the schema by stating the default sort order (descending by companyCount), the effect of minConfidence tiers, and how county and birthYearFrom/birthYearTo filters help disambiguate before spending credits. These operational semantics go beyond the schema's parameter definitions.

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?

The description states a specific verb and resource: 'Caută o persoană fizică ... și află în câte firme românești apare.' It also differentiates from the sibling get_person by noting that full profiles require get_person and one credit. An agent can immediately tell this is a search tool for natural persons and how it differs from related tools.

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

Usage Guidelines5/5

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

The 'CÂND îl folosești' section gives explicit when-to-use scenarios with step-by-step guidance, including routing to get_person for full profiles and using county or birth-year filters for disambiguation. It also states that UNRESOLVED clusters are structurally excluded and no parameter can include them. This is comprehensive usage guidance with alternatives and exclusions.

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

All Companero – Romanian Company Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?