webdata-tools-mcp

Find companies and new registrations in official registers

find_companies

Read-onlyIdempotent

Search official company registers by name or find newly registered, insolvent, deregistered and sold businesses; filter by country, location, industry and date to retrieve company details.

Instructions

Official company registers in one schema. mode "new": companies newly registered in France (BODACC), Norway (Brønnøysund), Finland (PRH), Estonia and the US states New York, Colorado, Connecticut and Oregon, and in France also insolvency judgments, deregistrations and business sales; filter by NACE/NAF industry code, city/region/postcode and keywords. mode "search": companies by name in France (with officers), Norway, Finland, Estonia, Czechia, the four US states and, for other countries, the worldwide LEI index. Registry id, legal form, status, dates, industry, address, employees, capital, officers or registered agents, business email where published (Connecticut), register link. Runs the Apify Actor tacps126/company-registry on your Apify account (about $0.0025 per company; spend per call is capped at $0.5).

Input Schema

Name	Required	Description	Default
`mode`	No	new = registrations and register events; search = look up by name.	new
`names`	No	Company names to search (mode "search"), e.g. ["Nokia"].
`events`	No	France, mode "new" (default: registration).
`countries`	No	ISO codes: FR, NO, FI, EE, CZ; US (all four states) or one state: US-NY, US-CO, US-CT, US-OR; others are searched in the LEI index.
`locations`	No	Cities, regions or postcode prefixes, e.g. ["Oslo", "75"].
`max_items`	No	Maximum results to return (default 50, max 1000). Cost scales with this.
`extra_input`	No	Advanced: extra Actor input fields, merged over the defaults.
`industry_codes`	No	NACE/NAF code prefixes, e.g. ["56.10"] restaurants, ["62"] IT; NAICS for Connecticut.
`registered_within_days`	No	mode "new": the last N days.

Output Schema

Name	Required	Description
`tool`	Yes	Name of the tool that produced the result.
`count`	Yes	Number of records the Actor returned.
`items`	Yes	The records. Long text fields are shortened to 600 characters.
`shown`	Yes	Number of records included in `items` (can be lower than count when the result is long).
`truncated`	Yes	True when records were left out to keep the result short; ask for fewer items.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.14.0Nov 2, 2026

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-schema context: it runs an Apify Actor on the caller's account at ~$0.0025 per company with a $0.5 per-call spend cap — critical for an agent deciding whether to call it or how to size max_items.

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?

A single dense paragraph with the core framing front-loaded ('Official company registers in one schema'), then mode 'new', mode 'search', returned fields, and cost. Every sentence carries information, though the country lists make it long and a bulleted mode split would scan faster.

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?

Covers both modes, jurisdiction coverage, filter dimensions, cost model and spend cap — enough for an agent to call correctly even for a 9-parameter tool with a nested extra_input object. The returned-field list is partly redundant given the output schema exists, and extra_input is left unexplained beyond 'advanced'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter logic the schema states only piecemeal: names apply to 'search' mode, events apply to France/'new', and other countries fall through to the LEI index. That mapping is real semantic value beyond the per-field descriptions.

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 ('Official company registers in one schema', 'find companies') and immediately splits the tool into two named modes with the jurisdictions each covers. No sibling tool in the list covers company registers, and the description makes the two-mode structure unmistakable.

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 routes the caller: mode 'new' for registrations/register events with event types, mode 'search' for lookup by name, and it states which countries each mode supports. It does not name alternative tools or say when NOT to use this one, which keeps it short of a 5.

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