Skip to main content
Glama
darksider4all

Leadgen MCP

by darksider4all
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Look up a Romanian company

lookup_business
Read-onlyIdempotent

Find a Romanian company by name or CUI in the official ONRC registry; names ignore diacritics and CUIs match exactly.

Instructions

Look up a Romanian company by name or CUI (tax code) in the official ONRC registry of 4.2M firms. Diacritic-insensitive ('paval' finds 'PAVAL'); a CUI matches exactly. The first call for a named Romanian company. Ranked with a score: live firms first (exact name, then words), closed ones after; county lifts. For 'firms that do X in Y', use lookup_by_category (an empty result may carry a hint naming it).

Input Schema

NameRequiredDescriptionDefault
queryYesCompany name or CUI (tax ID) to search for. Names are diacritic-insensitive ('paval' finds PAVĂL); a CUI ('2816464', 'RO2816464') matches exactly.
countyNoOptional county hint (diacritic-insensitive): firms registered there rank higher. Not a filter.
fieldsNoOptional: keep only these company fields in each row, comma-separated (companyName,cui,county,risk; dotted paths such as risk.level work). Without it the full record is returned.
compactNoOptional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url).
max_resultsNoMaximum number of companies to return (1-100, default 10).

Output Schema

NameRequiredDescriptionDefault
asOfNoWhat to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.
hintNoWhen a name search finds nothing but reads like a category question: the lookup_by_category call that answers it.
errorNoSet only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.
foundNofalse when a well-formed CUI is not in the snapshot.
queryNoThe query as given.
totalNoRows returned in this answer (at most max_results), not the number of firms that match.
countyNoThe county hint, if one was given.
fieldsNoThe company fields kept when fields or compact trimmed the rows.
reasonNoWhy nothing was found (not_found).
sourceNoData source: onrc (registry) or mfp (Ministry of Finance filings).
messageNoA sentence for the caller.
resultsNoThe company records, best first.
warningsNoNotes on how the request was read (a clamped limit, a widened CAEN code, an ignored field).
attributionNoThe credit line to keep when redistributing the data (CC BY 4.0).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.3
    • changedInput schema / properties / compact / description
      Previous value: -"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level, phone, website, latest revenue and headcount)."New value: +"Optional: true keeps a short preset per row (name, CUI, county, city, legal form, risk level and what it did not check, phone, website, latest revenue and headcount, record url)."
    • changedOutput schema / properties / results / items / description
      Previous value: -"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity}], directors, status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, and score/match on name searches. With fields or compact, only the requested keys."New value: +"A company record: companyName, cui, registrationCode, registrationDate (DD/MM/YYYY), legalForm, euid, address, county, city, website, phone, caenActivities [{code, activity (RO), activityEn}], directors, representatives [{name, role}], status [{code, name}], latestFinancials {year, revenue, netResult, employees; RON}, anaf {mainCaen, vatPayer, eFactura, inactive}, risk {level, label, reasons, isLead}, source, asOf, url (the firm's public record page to share with the user; null for sole traders and other natural persons), and score/match on name searches. With fields or compact, only the requested keys (compact keeps url)."
    • changedOutput schema / properties / total / description
      Previous value: -"Number of companies returned."New value: +"Rows returned in this answer (at most max_results), not the number of firms that match."
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-derivable behavior: diacritic-insensitive matching, CUI exact-match semantics, live-before-closed ranking with county lift, and the empty-result hint. It stops short of stating result limits or pagination, but that is minor against the annotation coverage.

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 with the core purpose, then ranking rules, then the sibling redirect. Dense but every clause carries information; the parenthetical examples are compact. Slightly packed with semicolon-separated ranking detail, but nothing is wasted.

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, return values need no explanation, and the description covers matching rules, ranking order and the alternative path. A complex, highly-ranked lookup tool is adequately described; only the max_results/truncation boundary behavior is left implicit.

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?

Schema description coverage is 100% and the parameter descriptions already cover diacritic-insensitivity, the county-as-hint-not-filter nuance, fields/compact behavior and the 1-100 bounds. The description largely restates the query semantics, so baseline 3 is correct – it adds little the schema does not already say.

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 specific verb and resource ('Look up a Romanian company by name or CUI') and pins the data source ('official ONRC registry of 4.2M firms'). It also positions itself among siblings with 'The first call for a named Romanian company', so an agent can separate it from lookup_companies, lookup_by_category and match_companies without opening a 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?

Explicitly routes the disambiguating case: 'For firms that do X in Y, use lookup_by_category', and even explains the redirect an empty result may carry. Combined with the 'first call for a named Romanian company' framing, both when-to-use and when-to-use-something-else are stated.

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

Deploy Server

Other Tools