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 due_diligence (raport complet, 300 credite): 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.5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: edge construction uses only high/medium confidence identity links, excludes ambiguous common names, insolvency practitioners don't create edges, hubs (>50 firms) don't expand, data are public ONRC facts, no pattern inference is exposed (DPIA), and computed:false indicates network rebuild pending. It also explains cost tiers and confirmation flow, plus data refresh after monthly ONRC import. This is exemplary 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 description is long and comprehensive but structured with clear sections (keywords, main purpose, differentiation, tiers, semantics, usage, cost). It is not concise – there is a large keyword block that adds little value for an AI agent (keywords are likely for internal search). The key information is front-loaded after keywords, but the keyword list is noise. Some redundancy exists (cost mentioned in two places). However, the structure is logical and every major behavioral aspect is covered, though the length could be trimmed.

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?

For a complex tool with no output schema and no annotations, the description is remarkably complete. It covers purpose, usage scenarios, tier details, behavioral semantics, cost confirmation, data freshness, and limitations (no pattern inference). The output structure for both tiers is described with field names. Even though there's no output schema, the description provides enough for an agent to understand what will be returned. Nothing critical is missing.

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% – all three parameters (taxId, detail, confirm) have descriptions in the schema. The description adds semantic detail: detail toggles between summary and full with different response shapes and costs, confirm is required for credit-consuming calls and returns a quote otherwise. While the schema already provides basic descriptions, the description enriches meaning with tier definitions and confirmation semantics, but much of this could be inferred from the schema. Baseline 3 is appropriate.

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 explicitly states the tool returns the company group of a Romanian company by CUI, including connected firms and factual history of connecting persons. It clearly distinguishes itself from due_diligence by focusing strictly on network/group dimension. The verb 'Returnează' plus resource 'GRUPUL DE FIRME' and scope (after CUI) is specific and unambiguous.

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 description provides explicit when-to-use examples ('Ce alte firme are administratorul firmei X?', 'Face parte firma X dintr-un grup de firme?') and explicit exclusions (does not cover financial profile – use get_financial_health and get_balance_sheets). It also distinguishes from due_diligence with cost and scope. The 'Când îl folosești' section gives concrete trigger scenarios, and the cost confirmation behavior is clearly explained.

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