Skip to main content
Glama

Companero – Romanian Company Data

by ro.companero
OverviewDiscussionsAdmin

get_financial_health

Keywords: indicatori financiari, lichiditate, solvabilitate, profitabilitate, marjă, Altman Z, bonitate, analiză financiară, sănătate financiară, current ratio, quick ratio, cash ratio, debt to equity, leverage, working capital, net margin, operating margin, ROE, ROA, turnover growth, revenuePerEmployee, financial ratios, liquidity, solvency, financial health, company health, financial analysis, balance sheet ratios, indicatori bilanț, poziționare industrie, industry position, CAEN percentile, financial score, financial indicators.

Calculează și returnează indicatori financiari determiniști pentru o firmă românească după CUI, din bilanțurile ANAF (și surse publice agregate pentru ani mai vechi). Calcul pur, fără LLM — rezultate instant, cost marginal zero.

Grupe de indicatori: lichiditate (currentRatio, quickRatio, cashRatio) · solvabilitate / structură (debtToEquity, leverageRatio, workingCapital) · profitabilitate (netMargin, operatingMargin, roe, roa) · eficiență / dinamică (receivablesDays, turnoverGrowth, employeeGrowth, revenuePerEmployee) · Altman Z″-score (model academic: „zona sigură" Z″>2.6, „zona gri" 1.1–2.6, „zona de presiune financiară" <1.1; cu componente X1–X4) · poziționare în industrie față de percentilele P25/median/P75 din industry_pulse_agg (turnover, profit, angajați, segmentul CAEN × județ cu fallback național; disponibil doar pentru segmente ≥ 30 firme).

Două tier-uri (detail):

  • detail: "summary" (DEFAULT, FREE): netMargin + leverageRatio + turnoverGrowth pentru ultimul an cu bilanț + poziționare față de industrie. „Cum stă firma față de concurență?" (Lichiditatea și Altman Z″ apar doar în full, unde există date — bilanțul ANAF simplificat nu le conține pentru majoritatea firmelor.)

  • detail: "full" (PAID, 2 credite): toți indicatorii pe toți anii disponibili (serie multi-an) + Altman Z″ cu componente + poziționare vs. ambele segmente (CAEN × județ și național) + nota metodologică. Folosește pentru due diligence complet, analiză de credit, comparație competitivă.

IMPORTANT — interpretare:

  • null pe un indicator = necalculabil din lipsă de date (microentitățile nu raportează toate câmpurile bilanțului). null ≠ 0.

  • Altman Z″ este un model academic — nu un verdict sau rating Companero. Prezintă zonele cu denumirile academice.

  • Capitaluri proprii ≤ 0 → debtToEquity și roe emit flag negativeEquity.

Când îl folosești:

  • „Care e lichiditatea / solvabilitatea firmei X?"

  • „Cum se compară cifra de afaceri a firmei Z cu industria ei?"

  • „Ce indică Altman Z-score pentru firma W?"

  • „Evoluția marjei nete în ultimii 5 ani la firma V"

  • Due diligence financiar pre-colaborare (furnizor, client, partener)

  • Analiză de credit sau factoring · screening B2B

Cost: free pentru detail=summary, 2 credite pentru detail=full.

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.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does it thoroughly. It discloses null semantics (null ≠ 0), the academic nature of Altman Z (not a verdict), the negativeEquity flag, the free vs paid tiers, and the confirm flow for paid calls (DEVIZ first, then replay with confirm:true). It also mentions data limitations (microentities may lack fields).

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 begins with a large keyword block that is redundant and does not help an agent select the tool. The rest is structured with sections, bold titles, and clear indicator groupings, but the overall length is inflated. Valuable information is present, but some sentences are repetitive (e.g., cost details are repeated), so it does not fully earn its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and complex behavior (two detail tiers, paid confirmation), the description compensates well by listing indicator groups, explicating the Altman Z zones, and clarifying the confirmation flow. It does not give an exact response JSON shape, but an agent can infer what to expect. Slightly more explicit response structure would make it a 5.

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 description coverage is 100% for all parameters, so the baseline is 3. The description adds value beyond the schema by explaining what each detail level returns (indicator groups, multi-year series) and by elaborating the confirm behavior (returns a quote without consuming credits). It does not substantially expand on taxId beyond the schema's 'Romanian CUI', but the added detail/confirm context justifies a 4.

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 clearly states the tool computes and returns deterministic financial indicators for a Romanian company by CUI from ANAF balance sheets. This distinguishes it from sibling tools like get_balance_sheets, which would provide raw data. The two detail tiers are also clearly explained, so an agent can understand what the tool does at a glance.

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?

The description includes a concrete 'Când îl folosești' section listing example questions and use cases (due diligence, credit analysis, B2B screening). It also explains when to choose 'summary' vs 'full' and notes the cost difference. However, it does not explicitly mention alternative tools or when not to use this one, stopping short of a 5.

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