Leadgen MCP

Annual financial statements

lookup_financials

Read-onlyIdempotent

Retrieve a Romanian company's financial statements by tax ID (CUI), with revenue, profit, headcount, balance-sheet lines, ratios, and multi-year summaries from Ministry of Finance filings.

Instructions

Annual financial statements for a Romanian company from Ministry of Finance filings, every fiscal year on record since 2008: revenue, profit, headcount and balance-sheet lines in RON with each year's ratios (growth, margins, equity ratio, liquidity), plus a summary (3/5/10-year CAGR, loss years, health score). Resolve the firm with lookup_business first if you only have a name.

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.
`found`	No	Whether any filing is on record.
`total`	No	Number of fiscal years returned.
`years`	No	Per fiscal year: revenue, profit, loss, netResult, employees, assets, debt, equity (RON) and that year's ratios.
`source`	No	Data source: onrc (registry) or mfp (Ministry of Finance filings).
`message`	No	A sentence for the caller.
`summary`	No	History, revenue growth (3/5/10-year CAGR), latest ratios, health score and band, flags.
`attribution`	No	The credit line to keep when redistributing the data (CC BY 4.0).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds genuine value beyond that: the data source (Ministry of Finance filings), historical depth (every fiscal year since 2008), currency (RON), and the name-resolution prerequisite. Rate limits, auth, and coverage gaps (e.g. missing years, firms never filing) are unmentioned.

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?

The payload is front-loaded into one dense sentence and the routing rule is a short second sentence, so nothing is buried. The enumerated field list is long but each item is informative rather than filler.

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?

With an output schema present, the return format need not be explained, and annotations cover the safety profile; the description still supplies source, currency, and historical coverage. The remaining gap is the unresolved overlap with lookup_financial_ratios, which an agent facing both tools would need to disambiguate.

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?

There is a single parameter and the schema description coverage is 100%, with the schema itself documenting the CUI format, examples, and acceptance of 'RO' and leading zeros. The description adds no parameter-level meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource with unusually concrete scope: annual statements for a Romanian company sourced from Ministry of Finance filings, every fiscal year since 2008, including named line items in RON. It stops short of drawing the boundary against the sibling lookup_financial_ratios, whose territory (ratios) this description also claims, so an agent must guess which to call for ratio-only needs.

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?

Explicitly gives the prerequisite path: resolve the firm with lookup_business first when only a name is available, which is real routing guidance. It offers no when-to-use versus lookup_financial_ratios or the other lookup_* siblings, so selection among overlapping tools is left to inference.

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

Deploy Server