Leadgen MCP

Match a list of records to firms

match_companies

Read-onlyIdempotent

Match up to 500 company records to Romanian firms by CUI, name, county, or domain, returning CUI, companyName, confidence, matchedOn, or no_match with candidates.

Instructions

Match a list of up to 500 records (name, optional county, domain or CUI) to Romanian firms: each row gets match {cui, companyName, confidence, matchedOn} and the record, or no_match with up to 3 candidates. A valid CUI wins (confidence 1.0). Each row counts as one lookup; a batch larger than what is left today is refused whole.

Input Schema

Name	Required	Description
`rows`	Yes	Up to 500 records, each {name, county, domain, cui, ref} (any of them; ref is your own id, echoed back), or a bare string (a CUI, a domain or a name).
`fields`	No	Optional: 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.
`compact`	No	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).

Output Schema

Name	Required	Description
`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.
`total`	No	Number of input rows.
`errors`	No	Rows that are input errors (nothing to match on).
`fields`	No	The company fields kept when fields or compact trimmed the rows.
`source`	No	Data source: onrc (registry) or mfp (Ministry of Finance filings).
`matched`	No	Rows matched to a firm.
`message`	No	A sentence for the caller.
`noMatch`	No	Rows with no match above the threshold.
`results`	No	Per row: row, input, status (matched or no_match), match {cui, companyName, confidence, matchedOn}, company, or candidates.
`metering`	No	What the batch cost: rows, counted, notCounted (input-error rows are not counted) and the rule.
`warnings`	No	Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field).
`threshold`	No	Confidence a row needs to be matched (0-1).
`attribution`	No	The credit line to keep when redistributing the data (CC BY 4.0).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.3Oct 19, 2026

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 / properties / company / 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)."

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 cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description adds real operational context: each row consumes one lookup, an over-quota batch is refused atomically, and a valid CUI forces confidence 1.0. It stops short of covering rate limits or partial-failure behavior in detail.

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?

Three dense sentences, front-loaded with the core action and the 500-row cap. The inline {cui, companyName, confidence, matchedOn} output spec is slightly heavy but each sentence carries information.

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?

Given a 3-parameter tool with a full schema and an output schema, the description covers the matching rules, quota cost, and all-or-nothing batch refusal. The main gap is sibling routing, which contextual completeness does not fully resolve.

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%, so the schema already documents rows, fields, and compact fully. The description's field list and CUI rule largely restate schema content, earning the baseline 3 rather than adding new parameter meaning.

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 (match) and resource (a list of up to 500 records) against Romanian firms, and makes the batch nature explicit. It is clearly distinguishable from single-record siblings like find_company_by_domain or lookup_companies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The batch use case is implied and the row-quota mechanics are explained, but the description never states when to choose this tool over siblings such as lookup_companies or enrich_company. Usage is inferable rather than guided.

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

Deploy Server