Skip to main content
Glama

Company Register Search

company_register_search
Read-onlyIdempotent

Search the NATIONAL BUSINESS REGISTERS by company name and get the register's own id back — a Companies House number, a Norwegian organisasjonsnummer, a Finnish business id, a SIREN, a Japanese corporate number, an Estonian registry code, a CNPJ, or an LEI. Use this when you want the OFFICIAL REGISTERED ENTITY and the country is not the US, or when you do not know which country it is. Registers searched: Companies House (GB), Enhetsregisteret (NO), PRH/YTJ (FI), Sirene (FR), 法人番号公表サイト (JP), RIK e-Business Register (EE), and the GLEIF LEI crosswalk, which reaches jurisdictions we have no register pack for (DE, SE, AU, SG...). THIS TOOL REFUSES TO GUESS, and that is its point: when two different companies match a name equally well it answers match_status: "ambiguous" with BOTH, rather than naming one. A one-word trading name usually IS ambiguous — "Bolt", "Apple", "Next", "Sea", "DNB" each match a well-known group AND unrelated micro-entities whose registered name is exactly that word — so pass country when you know it. Every response names EVERY register it asked under searched[], with that register's own as-of date and row count, and a register that could not be reached carries an error there rather than reading as zero rows: "we could not ask Companies House" is never the same answer as "this company is not in Britain". related[] holds entities that collapsed INTO the match — the same company seen through another register, or another country's arm sharing its LEI — so a multinational returns one answer rather than tying with itself. NOT A PEOPLE SEARCH: sole traders and other natural persons are excluded on the publisher's own legal-form field, never guessed from the shape of a name. For US public companies prefer resolve_entity (CIK + ticker + FIGI); the two share this same matcher, and resolve_entity returns these register fields too.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe company name as you have it, in its own script. Pass it VERBATIM — do not strip the legal form ("Oyj", "AS", "株式会社", "Ltd"): in Japanese the form is a PREFIX as often as a suffix and 株式会社花王 and 花王株式会社 are DIFFERENT companies, so the form is often the only evidence that separates two candidates. Diacritics, full-width characters and kana are all handled.
limitNoMaximum candidates to return, 1-50 (default 10). Does not change which registers are asked, only how many rivals come back.
countryNoOPTIONAL ISO 3166-1 alpha-2 of the register you mean ("GB", "NO", "FI", "FR", "JP", "EE", "BR"). Narrows the fan-out, and is frequently the difference between an answer and `ambiguous` on a short name. The GLEIF crosswalk is asked whatever you pass, because for several jurisdictions it is the only register we can name at all.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/open-world/non-destructive, but the description adds substantial behavior beyond them: it refuses to guess and returns match_status 'ambiguous' with both candidates, exposes searched[] with per-register as-of dates and errors (unreachable register ≠ zero rows), and explains related[] collapsing. This is exactly the extra context the annotation bar rewards.

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-loaded with the core action and return value, then progressively details registers, ambiguity behavior, and exclusions in well-signposted blocks. It is dense and slightly repetitive (the register list and 'refuses to guess' theme recur), but length is largely justified by the tool's complexity.

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 no output schema, the description carries the burden and discharges it: it describes return fields (searched[], related[], match_status), error semantics, scope (not a people search), and register coverage. An agent has everything needed to call and interpret this complex tool.

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 decision-relevant meaning: it explains that a short name is often ambiguous and that passing country is 'frequently the difference between an answer and ambiguous', reinforcing schema semantics with usage guidance. It largely echoes the schema's name/limit detail, so it does not fully exceed the baseline.

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+resource ('Search the NATIONAL BUSINESS REGISTERS by company name') and the precise return artifact ('get the register's own id back — a Companies House number, ...'), with concrete examples of the identifier types. It also carves out its sibling explicitly ('For US public companies prefer resolve_entity'), so an agent can distinguish it from the nearest alternative without opening a schema.

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?

Explicit when-to-use ('when you want the OFFICIAL REGISTERED ENTITY and the country is not the US, or when you do not know which country it is'), explicit when-not (US public companies → resolve_entity, natural persons excluded), and explicit advice on passing country to avoid ambiguity. Alternatives and conditions are named, not inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.