Leadgen MCP

Find the company behind a website

find_company_by_domain

Read-onlyIdempotent

Identify the Romanian firm behind a website domain by checking the registry's website field or scanning the site's legal and contact pages for a CUI or registration number.

Instructions

Find the Romanian firm behind a website domain (dedeman.ro). Uses the registry's website field, else reads the site's home and legal/contact pages for the CUI or registration number it shows (matchedOn: registry_website, site_cui). Without one, it says so and offers name candidates from the page title or the domain name, each with a confidence (at most 0.7, never a match). One lookup.

Input Schema

Name	Required	Description
`domain`	Yes	The website's domain ('dedeman.ro'); a URL or a www. host is reduced to it. Public domains only.
`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.
`site`	No	What was read from the site: url, pagesRead, title, cuis, registrationCodes, error.
`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 a firm was identified.
`match`	No	The identified firm: cui, companyName, matchedOn.
`total`	No	Number of company records returned (at most 5).
`domain`	No	The normalised domain.
`fields`	No	The company fields kept when fields or compact trimmed the rows.
`reason`	No	When not found: no_cui_on_site or site_unreachable.
`message`	No	A sentence for the caller.
`results`	No	The company records, best first.
`warnings`	No	Notes on how the request was read (a clamped limit, a widened CAEN code, an ignored field).
`matchedOn`	No	registry_website, site_cui or site_registration_code.
`candidates`	No	When not found (also when the site cannot be read): up to 3 firms whose name matches the page title or the domain name, each with a confidence (at most 0.7).
`attribution`	No	The credit line to keep when redistributing the data (CC BY 4.0).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 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 / candidates / description

Previous value: -"When not found: up to 3 firms whose name matches the page title."New value: +"When not found (also when the site cannot be read): up to 3 firms whose name matches the page title or the domain name, each with a confidence (at most 0.7)."

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)."

First observedv0.1.0Oct 17, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses the two lookup paths (registry website field vs. reading home/legal/contact pages), the matchedOn values, that name candidates are capped at 0.7 confidence and are 'never a match', and that it is a single lookup. This is exactly the behavioral detail annotations cannot convey.

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?

Dense and front-loaded with the core purpose first, then method, then fallback behavior. The middle sentence is packed but not redundant; a slightly shorter phrasing would improve scannability.

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?

With an output schema present and annotations covering the safety profile, the description supplies everything remaining an agent needs: input shape, resolution strategy, confidence semantics, and the fact that a non-match is reported rather than fabricated.

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 coverage is 100%, so the domain, fields, and compact parameters are already fully documented in the schema. The description adds no parameter syntax or format detail of its own, 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 and resource ('Find the Romanian firm behind a website domain') with a concrete example (dedeman.ro) and names the matching method used. It is clearly distinguishable in substance from lookup/enrich siblings, though it never names an alternative tool to contrast against.

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?

Usage context is implied (you have a domain, you want the company) and the fallback chain tells the agent what will happen, but there is no explicit 'use this when X, use lookup_domain/lookup_business when Y' guidance despite many closely named siblings.

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

Deploy Server