Skip to main content
Glama

Companero – Romanian Company Data

by ro.companero
OverviewDiscussionsAdmin

screen_companies

Keywords: verificare portofoliu, verificare listă de firme, verificare CUI-uri, screening firme, screening parteneri, verificare clienți, verificare furnizori, verificare în masă, verificare bonitate, control de credit, credit control, semnale de alertă firme, firme cu datorii, firme radiate, firme în insolvență, verifică-mi lista de parteneri. Keywords (EN): portfolio screening, batch company check, bulk due diligence, screen a list of companies, check partners/clients/suppliers, credit control, KYC suppliers, supplier risk screening, mass company verification, Romanian companies list check, flag companies with debts/insolvency.

Verifică o LISTĂ de firme românești (după CUI) și întoarce, per firmă, semnalele factuale deterministe deja cunoscute în Companero: firmă inactivă/radiată/suspendată, evenimente în istoricul de stări de la ONRC (dizolvare, lichidare, fuziune, divizare), datorii la stat (ANAF), capitaluri proprii negative, presiune financiară (Altman Z″), scădere de cifră de afaceri, bilanț nedepus recent, firmă tânără. Ideal pentru contabili, credit control, distribuitori cu mulți clienți pe termen de plată — „am o listă de N parteneri, spune-mi care au probleme".

Input: taxIds — listă de CUI-uri (numere sau string-uri; prefixul „RO" se ignoră). Maxim 100 CUI-uri per apel (peste 100 → eroare). Opțional label (nume pentru job, ex. „Portofoliu clienți iulie").

Comportament: pentru ≤20 CUI-uri raportul complet vine SINCRON (job + agregate + toate firmele cu flag-urile lor). Pentru 21–100 CUI-uri se creează un job asincron și primești jobId + status — verifici rezultatul cu tool-ul get_screening.

Tarifare: 1 credit per firmă REZOLVATĂ (CUI găsit în baza Companero). CUI-urile inexistente NU se taxează. Un portofoliu de 50 de firme = ~50 credite. Necesită autentificare.

Flag-uri și severități: inactive, status_event, state_debts, negative_equity (severitate HIGH); financial_pressure, turnover_drop, no_recent_filing (MEDIUM); young_company, not_found, screening_error (INFO). Sortare implicită: cele mai multe flag-uri high întâi.

Sunt FAPTE, nu verdicte: niciun scor de risc, niciun rating, nicio recomandare. Un eveniment de stare NU înseamnă insolvență - o fuziune apare tot acolo. status_event se numea insolvency_history până la politica sp2; rapoartele mai vechi pot purta încă vechiul cod.

Când NU e potrivit (dezambiguizare):

  • due_diligence = analiză narativă sintetizată de AI pe O SINGURĂ firmă.

  • get_company = profilul individual al unei firme după CUI.

  • screen_companies = semnale deterministe pe o LISTĂ de firme, format tabelar.

Important: Companero arată FAPTE, nu verdicte. Flag-urile sunt semnale factuale (ex. „figurează cu datorii ANAF de X lei la Q4-2025"), NU un „scor de risc" și NU o recomandare de a lucra sau nu cu firma.

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
labelNoNume opțional pentru job (ex. "Portofoliu clienți iulie").
taxIdsYesListă de CUI-uri de verificat (numere sau string-uri; "RO" se ignoră). Maxim 100 per apel; pentru ≤20 raportul e sincron, altfel job asincron interogat cu get_screening.
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.8/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 of behavioral disclosure. It explains that results are facts, not risk scores or recommendations, that status_event was formerly insolvency_history, that sync vs async behavior depends on list size, and that companies not found are not charged. It also documents the quote/confirm flow and authentication requirement.

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 well-organized into labeled sections and nearly every substantive section earns its place. However, it opens with two long keyword-stuffing lists and repeats the 'facts, not verdicts' point twice. It is comprehensive but not tightly edited or front-loaded.

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?

There is no output schema or annotations, yet the description covers the returned flags and severities, default sorting, not-found and error cases, async polling via get_screening, authentication, and credit costs. An agent has enough detail to call the tool correctly and interpret the response.

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

Parameters5/5

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

Although schema coverage is already 100%, the description adds significant meaning: taxIds accepts numbers or strings, ignores 'RO', and is capped at 100; label is purely a user-facing job name; confirm enables quote-only behavior and must be sent only after user approval. This goes well beyond the schema's field descriptions.

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: it verifies a list of Romanian companies by CUI and returns deterministic factual signals per company. It also explicitly distinguishes screen_companies from due_diligence and get_company by defining what each alternative does. The opening keyword block is noisy, but the core purpose is unmistakable.

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?

There is an explicit disambiguation section ('Când NU e potrivit') that names due_diligence and get_company as alternatives and clarifies that screen_companies handles deterministic list screening. It also gives concrete usage context: accountants, credit control, bulk partner lists, and the sync/async threshold.

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 toolsInspect
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