Getregdata

What getregdata does

getregdata exposes business-registry research functions to MCP-compatible agents. The catalog covers KYC/AML, KYB, beneficial ownership, adverse media, insolvency, financial statements, property records, corporate officers, licensing registers, environmental registrations, and B2B research across multiple jurisdictions.

The most consolidated workflow is regdata_poland_kyb_check. Given a Polish NIP or KRS, it resolves company identity, finds beneficial owners, and checks insolvency, restructuring, and enforcement records for both the company and each owner. The result includes a normalized verdict, risk flags, and underlying registry entries. Other tools target a single source when deeper detail or a different country is needed.

How it works

Registry operations are backed by Apify actors and return structured results. regdata_catalog helps an agent select a suitable registry tool, while regdata_describe returns the live input schema and description for an actor or tool name. This allows callers to construct inputs without hard-coding every actor's fields; additional actor-specific fields may be accepted beyond the basic schema.

Some checks take long enough to finish after the initial MCP call. In that case, the tool returns a status, run ID, and note rather than the dataset. The check has already been billed, so the caller should use regdata_run_result with that run ID. If processing continues, the same handle is returned for another retrieval attempt. Re-running the original check can create a second charge.

The Poland KYB operation commonly takes 20–30 seconds and can take longer as the number of beneficial owners increases. A partial verdict indicates that a source could not be reached; it should not be interpreted as a clean result.

Setup and configuration

A local MCP configuration can launch the package with npx:

{
  "mcpServers": {
    "getregdata": {
      "command": "npx",
      "args": ["-y", "getregdata-mcp"],
      "env": {"APIFY_TOKEN": "apify_api_xxxxx"},
      "timeout": 600000
    }
  }
}

The local server uses APIFY_TOKEN for Apify access. The package can also be added as agent skills with npx skills add Nolpak14/getregdata -g -y. For remote use, connect an MCP client to Apify's hosted endpoint and select the desired registry actors; authentication uses OAuth and billing is associated with the user's Apify account.

Tools and capabilities

• Browse available registry tools and their returned fields with regdata_catalog.
• Retrieve live actor schemas with regdata_describe.
• Collect completed results from asynchronous runs with regdata_run_result.
• Run a combined Polish KYB check with identity, UBO, and insolvency screening.
• Screen people or companies for categorized adverse media, including source provenance and severity.
• Query registries for company records, directors, shareholders, financial statements, insolvency proceedings, liens, mortgages, PEPs, premises, waste registration, certified email, and beneficial owners.

Coverage includes Polish KRS, CRBR, KRZ, MSiG, KNF, REGON, land registers, and financial filings, alongside registries and public sources in Austria, Belgium, California, Czechia, France, Germany, Italy, Slovakia, and Spain. Individual tools have source-specific search limits and result semantics. For example, broad searches may be refused or marked incomplete rather than treated as an empty result.

Limitations and notes

Many registry operations are scrapers for public portals that lack official APIs, so availability and response time depend on the source. A search capped by the source's match limit is not evidence that the requested entity or filing is absent; narrowing the query is required. The California business registry, California UCC index, Czech insolvency register, and German insolvency register each report broad or excessive-match conditions explicitly.

Some source data is restricted. Poland's public BDO search provides registration details but not waste codes or permits behind login. The Poland KRS tool retrieves complete names from public PDF extracts because the official API masks them. Registry results should therefore be interpreted with each source's status, coverage, and search constraints in mind.