Skip to main content
Glama

Companero – Romanian Company Data

get_company_network

Keywords: grup de firme, firme legate, rețea de firme, conexiuni firmă, company group, related companies, company network, connected companies, administrator comun, asociat comun, shared director, beneficial owner network, firme radiate, istoric administratori, due diligence, KYC, risc de contrapartidă, counterparty risk, verificare partener, legături între firme, afiliați, affiliated companies, group structure, ownership links.

Returnează GRUPUL DE FIRME al unei companii românești (după CUI): alte firme conectate prin aceleași persoane (legături prin administratori și, unde sunt cunoscute, prin acționari), împreună cu istoricul factual al fiecărei persoane care leagă firmele: câte firme are în total, câte active, câte radiate, câte cu insolvență, câte cu datorii la stat.

Diferență față de profilul individual (get_company): acest tool răspunde STRICT la dimensiunea de rețea/grup — cine leagă firma de ce alte firme și ce istoric au acele legături. Pentru profil financiar și bilanțuri folosește get_financial_health și get_balance_sheets.

Două tier-uri (toggle prin detail):

  • detail: "summary" (DEFAULT, FREE): {groupSize, connectorCount, deletedInGroupCount, computedAt} — răspunde rapid la "face parte firma dintr-un grup și câte dintre firmele grupului sunt radiate?".

  • detail: "full" (PAID, 10 credite): expansiunea completă 2-hop: connectors[] (persoanele care leagă firma: nume, roluri, câte firme au în total, statistici — câte active/radiate/cu insolvență/cu datorii ANAF) + groupMembers[] (firmele din grup, deduplicate, cu starea lor și prin cine sunt conectate).

Semantici cheie (interpretează corect):

  • Muchiile folosesc DOAR legături cu încredere high/medium din rezoluția de identitate; persoanele cu nume comune neambiguizate sunt EXCLUSE structural — nu presupune niciodată că două firme sunt legate doar pentru că administratorii au același nume.

  • Practicienii în insolvență (lichidatori, administratori judiciari) NU creează muchii de grup — mandatele lor sunt procedurale.

  • Persoanele cu foarte multe firme (>50) apar ca isHub: true și nu extind grupul.

  • Cifrele sunt fapte publice ONRC (mandate, radieri, date), nu aprecieri. O firmă radiată în istoricul unui administrator NU e, prin ea însăși, un semnal negativ: radierea voluntară e obișnuită. Absența datelor de datorii pentru firme radiate demult NU înseamnă că erau curate.

  • Corelarea acestor fapte într-un tipar de comportament (persoane cu firme radiate care înregistrează firme noi) NU e expusă prin acest tool și nu apare în răspuns; e o prelucrare pentru care așteptăm evaluarea de impact (DPIA, art. 35 GDPR). Nu o deduce singur din cifre și nu o prezenta utilizatorului ca pe un rezultat al platformei.

  • computed: false → rebuild-ul de rețea nu a rulat încă pentru acest set de date.

Când îl folosești:

  • "Ce alte firme are administratorul firmei X?" / "Firme legate de X"

  • "Face parte firma X dintr-un grup de firme?"

  • "Are firma X administratori cu firme radiate în urmă?"

  • "Verifică istoricul oamenilor din spatele firmei X" (KYC, credit, contract nou, factoring)

Cost: free pentru detail=summary, 10 credite pentru detail=full. Datele se recalculează după fiecare import ONRC lunar.

Confirmarea costului: un apel care ar consuma credite are nevoie de confirm: true. Fără el primești DEVIZUL (cost în credite și RON, soldul contului, alternativa gratuită dacă există) și nu se consumă nimic — reia apoi EXACT același apel cu confirm: true, după ce omul a acceptat costul.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taxIdYesRomanian CUI (Cod Unic de Înregistrare).
detailNo"summary" (free, default) or "full" (paid, see ActionCostCatalog).
confirmNoAcordul utilizatorului de a consuma credite pentru acest apel. Fără el, apelul întoarce DEVIZUL (cost, sold, alternativa gratuită) și nu consumă nimic. Nu îl trimite din proprie inițiativă: întreabă întâi omul.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses tier pricing (free vs 10 credits), the DEVIZ/confirm protocol, edge-confidence rules, exclusion of insolvency practitioners, isHub handling, computed:false semantics, and what the tool deliberately does NOT expose (GDPR/DPIA pattern inference). This is unusually rich behavioral disclosure.

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

Conciseness3/5

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

The body is well organized with tier, semantics and usage sections, but it opens with a very large bilingual keyword block that consumes a lot of space without telling an agent anything actionable about invoking the tool. The content is long enough that the genuinely important routing sentences are buried mid-description.

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?

No output schema exists, yet the description specifies the returned fields for both tiers (groupSize, connectorCount, connectors[], groupMembers[], etc.) and the computed flag, so an agent knows what to expect. Combined with the cost/confirm rules, nothing needed 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 coverage is 100%, so baseline is 3, but the description adds real meaning: it enumerates the exact return payload of detail='summary' vs 'full', quantifies the cost of each, and explains that confirm without an explicit call returns a quote rather than consuming credits. That goes beyond the schema's terse enum note.

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 ('Returnează GRUPUL DE FIRME al unei companii românești (după CUI)') and immediately scopes it to network/group connections via shared persons. It explicitly distinguishes itself from get_company, get_financial_health and get_balance_sheets, so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Includes an explicit 'Când îl folosești' section with four concrete trigger phrasings, names the sibling tools that cover the other dimensions, and spells out the free vs paid tier decision. The confirm/cost flow adds a further explicit procedural condition.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources