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):

  • 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. Changed1 schema field changed
    • removedInput schema / properties / taxIds / items
      Removed value: -{
-  "type": "string"
-}
  2. 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 delivers: auth requirement, sync behaviour for ≤20 CUIs vs async job for 21–100 with jobId/status, per-company credit pricing with unused CUI not charged, the `confirm: true` quote-then-execute flow, flag lists with severity tiers, default sort order, and the caveat that outputs are facts not verdicts. It even documents the `status_event` / legacy `insolvency_history` naming change.

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?

Core content is well-structured and front-loaded with the operative behaviour, sync/async rules, and pricing. However, the twin RO/EN keyword blocks are long and largely duplicate content already conveyed by the body, which bloats the definition well past what an agent needs to select and invoke the tool.

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 non-annotated, no-output-schema tool, the description is essentially complete: it explains inputs, cost mechanics, confirmation gating, sync/async routing with the follow-up tool named, the flag vocabulary with severities, sort behaviour, and the semantic warning about state events not implying insolvency.

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 the baseline is 3, but the description adds real meaning on top: the max of 100 CUIs and the error on overflow, the RO-prefix handling, the purpose of `label` as a job name, and crucially the behavioural consequence of list size (sync vs async). The `confirm` parameter's negotiation semantics (never send proactively, ask the human first) are reinforced beyond the schema text.

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 precise verb and resource: it verifies a LIST of Romanian companies by CUI and returns deterministic factual signals per company (inactive/deregistered, ONRC state events, ANAF debts, negative equity, financial pressure, etc.). It explicitly contrasts itself with the sibling `get_company` (single-profile lookup) and `get_screening` (async result retrieval), so an agent can route without opening either 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?

Has an explicit 'Când NU e potrivit' disambiguation block naming the alternative (`get_company` = individual profile, `screen_companies` = list signals), and names intended users (accountants, credit control, distributors with many clients). It also states the split between synchronous and asynchronous flows and the tool used to retrieve async results.

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