Skip to main content
Glama

Companero – Romanian Company Data

due_diligence

Keywords: due diligence, raport, audit, verificare firmă, KYC, risc, bonitate, analiză, profil financiar, situație juridică, datorii ANAF, insolvență, administratori, asociați, reprezentanți legali, contracte publice, SEAP, exposure cross-company, beneficial owner, AI report, business intelligence, company report, risk assessment, romanian company audit.

Generează o «Analiză firmă» pentru o firmă românească, dat CUI-ul (Cod Unic de Înregistrare). Este o EVALUARE ORIENTATIVĂ pe baza datelor publice (ONRC, ANAF, SEAP) — NU un verdict, o recomandare sau un raport de bonitate. Raportul este produs de un agent AI care agregează:

  • profilul ONRC (nume, județ, oraș, CAEN principal, dată înregistrare, stare juridică, număr de ordine în registrul comerțului, plătitor de TVA)

  • bilanțuri ANAF ultimii 5 ani (cifră de afaceri, profit/pierdere, active, datorii, capital social, angajați declarați, capital propriu) plus cifrele derivate calculate de noi (marje, grad de îndatorare, variații anuale) — modelul NU calculează, primește rezultatele

  • indicatorii de sănătate financiară (aceiași cu get_financial_health)

  • reprezentanți legali activi, cu rolurile grupate și „exposure cross-company" (în câte alte firme apare aceeași persoană)

  • datorii ANAF curente (trimestrul cel mai recent importat), cu distincția explicită între „are datorii", „confirmat FĂRĂ datorii la trimestrul X" și „încă nu avem trimestru importat"

  • contracte publice SEAP ca furnizor la stat (valorile de acord-cadru raportate SEPARAT de contractele ordinare) plus „dependența de stat" (valoare contracte ÷ cifră de afaceri, serie anuală)

Monitorul Oficial NU intră în acest raport; insolvența, dizolvarea, lichidarea și radierea se citesc din starea juridică de la registru.

Un agent AI produce, pe baza acestor date, un raport JSON structurat cu:

  • oneLineSummary — rezumat scurt factual (max 200 caractere)

  • executiveSummary — 3-5 propoziții, situație generală

  • financialOverview, governanceOverview, legalOverview — câte un paragraf per dimensiune

  • riskFlags[] — listă de semnale de risc cu severitate (critical/high/ medium/informational), categorie (financial/legal/governance/tax/ operational/reputational), titlu, descriere, și evidence[] — citate concrete din dossier (NU fapte inventate — agentul este forțat să trimită la câmpul-sursă)

  • confidence — încrederea agentului în raport (0..1)

Când îl folosești:

  • "Vreau un raport de due diligence pentru firma cu CUI X"

  • "Verifică bonitatea firmei Y"

  • "Cât de riscantă e firma cu CUI Z?"

  • "Pot să fac afaceri cu firma X? Sunt vreun semnal de risc?"

  • "Generează un raport pentru această companie / acest CUI"

  • "Audit / KYC pe firma X"

Cost & caching: 300 credite (15 RON) per raport PER versiune-de-date. Abonamentul Pro include O analiză pe lună calendaristică — prima rulare nouă a lunii nu consumă credite; următoarele se taxează normal. Dacă tu (sau oricine altcineva) ai cerut deja raportul pe acest CUI și nu s-au schimbat datele subordonate (bilanț nou, schimbare administrator, contract public nou, datorii ANAF noi), apelul folosește un cache existent și e gratuit oricum — un raport din cache NU consumă analiza inclusă a lunii. În _meta primești chargedThisRequest (bool) ca să știi dacă creditele s-au consumat sau nu, și bannerNewerAvailable (bool) care semnalizează că datele sursă s-au schimbat faţă de versiunea pentru care utilizatorul a plătit anterior.

Output: obiect JSON cu status, report (câmpul schemaVersion din răspuns spune versiunea exactă), _meta. Rapoartele cu severity=critical trec automat printr-o coadă de review uman înainte de publicare (status=pending_review).

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), e.g. 37418771.
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.
refreshNoForce a fresh report even if a cached version exists for

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries full weight and is unusually transparent: it states the report is AI-generated, indicative rather than a verdict, subject to human review for critical severity, cached per data version, and requires explicit user confirmation before consuming credits. It also spells out the deviz behavior and cache charging semantics.

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-structured with bullet lists and front-loaded purpose, but it opens with a long keyword dump (due diligence, raport, audit, KYC, ...) that adds noise. It is verbose overall, though most sentences carry useful behavioral or usage information.

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?

Despite no output schema, the description documents the JSON report shape (`oneLineSummary`, `executiveSummary`, `riskFlags[]`, `confidence`), the `report`/`_meta` envelope, cost, caching, human-review queue, and confirmation flow. An agent has everything needed to decide, invoke, and handle the response correctly.

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 coverage is 100%, so the schema already explains `taxId`, `confirm`, and `refresh`; the description reinforces the confirmation policy but adds little per-parameter semantics beyond it. Cost, cache, and `_meta` fields are behavioral context rather than new parameter meaning.

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 opens with a specific verb and resource: it generates a company analysis report for a Romanian firm given a CUI, and explicitly states what it is not ('NU un verdict, o recomandare sau un raport de bonitate'). It enumerates the report dimensions and excludes Monitorul Oficial, which separates it from data-retrieval siblings like get_company or get_anaf_debts.

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?

It provides an explicit 'Când îl folosești' section with concrete user phrasings ('Vreau un raport de due diligence...', 'Verifică bonitatea...') and describes the cost/confirmation protocol. It does not name sibling tools as alternatives for narrower data needs, though it notes the financial-health indicators are the same as `get_financial_health`.

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