Leadgen MCP

Financial ratios and health score

lookup_financial_ratios

Read-onlyIdempotent

Analyze a Romanian company by CUI to retrieve multi-year revenue trends, margins, solvency and liquidity ratios, health score, red flags, peer percentiles, and a growth/stable/distressed verdict.

Instructions

Derived financial intelligence for a Romanian company: multi-year revenue trend (YoY, 3/5/10-year CAGR), margins, headcount, solvency and liquidity ratios, a 0-100 health score with its rule-by-rule breakdown, red flags, and peer percentiles within the same CAEN activity and county. Verdict: 'growing', 'stable' or 'distressed'. Use lookup_financials for the raw figures.

Input Schema

Name	Required	Description	Default
`cui`	Yes	Romanian tax identification number (CUI), e.g. '2816464'; 'RO' and leading zeros are accepted.

Output Schema

Name	Required	Description
`cui`	No	The firm's CUI.
`asOf`	No	What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.
`error`	No	Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.
`flags`	No	Red flags.
`found`	No	Whether any filing is on record.
`peers`	No	Percentiles within the same CAEN activity and county.
`total`	No	Number of fiscal years used.
`years`	No	Per fiscal year figures and margins.
`ratios`	No	Margins, equity ratio, debt to equity, liquidity, returns.
`source`	No	Data source: onrc (registry) or mfp (Ministry of Finance filings).
`history`	No	Years on record, loss years, revenue peak.
`message`	No	A sentence for the caller.
`signals`	No	The distress signals found.
`verdict`	No	growing, stable or distressed.
`distress`	No	true when the distress signals fire.
`headcount`	No	Latest headcount and its change.
`attribution`	No	The credit line to keep when redistributing the data (CC BY 4.0).
`healthScore`	No	0-100 score, band and its rule-by-rule components.
`revenueTrend`	No	Latest revenue, YoY growth, 3/5/10-year CAGR, trend label.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, so safety is covered. The description adds real behavioral value beyond that: the discrete verdict enum ('growing'/'stable'/'distressed'), the presence of a rule-by-rule health-score breakdown, red flags and peer-percentile benchmarking. It omits any note on data freshness or what happens for companies with sparse filings.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded: the payload of the tool is stated first, with the sibling routing instruction last. The opening sentence is a long comma-separated enumeration, but each item is a distinct returned artifact rather than filler, so it stays efficient.

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?

An output schema exists so return values need not be restated, yet the description still gives the agent the semantic shape (verdict enum, health-score breakdown, peer grouping by CAEN and county) plus scope and the alternative tool. Nothing needed to select or call this correctly 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?

Only one parameter and schema coverage is 100%, with the schema itself documenting the CUI format and the 'RO'/leading-zero tolerance. The description adds no further meaning about the identifier, so the baseline 3 for schema-covered params applies.

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+resource and enumerates exactly what 'derived financial intelligence' means: YoY/3-5-10y CAGR, margins, headcount, solvency/liquidity ratios, a 0-100 health score, red flags, peer percentiles. It explicitly distinguishes itself from the sibling lookup_financials ('raw figures'), so an agent can separate the two 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternative (lookup_financials) and the condition that selects it ('for the raw figures'), and scopes the tool to Romanian companies via the CUI input. It does not state prerequisites, failure modes (e.g. company with no filed statements), or exclusions beyond that one routing sentence, so it stops short of a full when/when-not map.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server