mcp-gtm-suite

Resolve Legal Entity

resolve_legal_entity

Idempotent

Map a company domain to the registered legal entity behind it—legal name, company number, jurisdiction, status, LEI, VAT—plus rejected-match audit trail from UK Companies House, GLEIF, and SEC EDGAR.

Instructions

Give it a company domain and it returns the registered legal entity behind it: legal name, company number, jurisdiction, status, entity type, LEI and VAT number, as one flat row with a full audit trail of what was rejected and why. Three registers are queried: UK Companies House, GLEIF and SEC EDGAR. Register search endpoints are fuzzy and always return something, so by default a record is accepted only when the normalized legal names are identical. That is why roughly 6 domains in 10 resolve rather than 10 in 10, and why a null here is a trustworthy answer rather than a gap. Read match_method, match_confidence and rejected_candidates before acting on a match. Setting match_strictness to fuzzy will hand you a confidently wrong company on most domains and should be treated as a research mode, not a default. This is not a company database and not a credit or risk product. Requires an APIFY_TOKEN and consumes Apify credits. Read only.

Input Schema

TableJSON Schema

Name	Required	Description
`domain`	Yes	A single company domain, for example monzo.com. Protocol and path are stripped.
`skipCache`	No	false uses the cache: 90 days for a resolved company, 7 days for a null. true forces a fresh look. Default: "false".
`validate_vat`	No	Runs any VAT number found on the company's own pages through the EU VIES service and returns the name VIES holds for it, as a cross-check against the register name. Default: true.
`max_charge_usd`	No	Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.
`legal_name_hint`	No	Skips the domain lookup and goes straight to the registers with this name. Use it when you already have the legal name and just want the register record.
`match_strictness`	No	exact accepts a register record only when the normalized legal names are equal, which is the default and the recommendation. fuzzy returns the best scoring candidate with a confidence below 100 and a warning in rejected_candidates. Register search is fuzzy and always returns something, so fuzzy mode will hand you a confidently wrong company on most domains. Default: "exact".
`jurisdiction_hint`	No	ISO-2 country code, for example GB or US. Narrows which registers are queried and cuts latency. Leave empty to query every register.
`sec_requester_name`	Yes	Required. Your own name or your company's name. The SEC requires every automated request to EDGAR to identify the requester by name and email, and the actor sends yours, never a default.
`sec_requester_email`	Yes	Required. Your own working email address. Sent to the SEC with your name in the User-Agent of each EDGAR request, in the form the SEC asks for. Nothing else uses it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.14.0Oct 16, 2026

addedInput schema / properties / max_charge_usd

Added value: +{
+  "description": "Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.",
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / sec_requester_email

Added value: +{
+  "description": "Required. Your own working email address. Sent to the SEC with your name in the User-Agent of each EDGAR request, in the form the SEC asks for. Nothing else uses it.",
+  "format": "email",
+  "type": "string"
+}

addedInput schema / properties / sec_requester_name

Added value: +{
+  "description": "Required. Your own name or your company's name. The SEC requires every automated request to EDGAR to identify the requester by name and email, and the actor sends yours, never a default.",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "domain"
-]New value: +[
+  "sec_requester_name",
+  "sec_requester_email",
+  "domain"
+]

Addedv1.1.1Oct 13, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds real behavioral context: ~6/10 resolve rate, defaults that reject non-identical names, requirement for APIFY_TOKEN, credit consumption, cache TTLs implied via skipCache. It does not restate readOnlyHint. However, the annotation readOnlyHint=false contradicts the description's closing 'Read only.'

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-loads what the tool does and its output, then explains the matching policy and the null-rate caveat. Slightly long, but every sentence carries non-obvious information. Could trim the sibling list of registers if it ever grew.

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?

Despite 9 parameters and no output schema, the description gives an agent everything needed: what it returns, the match semantics, the failure mode, the cost/auth model, and the trustworthiness of nulls. No material gap remains.

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 schema carries parameter detail. The description still adds value by explaining why match_strictness defaults to exact and why fuzzy is risky, and by framing SEC requester fields as regulatory requirements rather than arbitrary inputs.

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 (resolve) and resource (legal entity) with a precise output contract: registered legal name, company number, jurisdiction, status, entity type, LEI, VAT. It also names the three data sources (Companies House, GLEIF, SEC EDGAR), which distinguishes it clearly from siblings like resolve_company_identity.

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 states when to use fuzzy vs exact, when to use legal_name_hint, and what a null answer means. It also states when NOT to use it: 'not a company database and not a credit or risk product.' This is exactly the routing guidance an agent needs.

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

Resolve Legal Entity

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools