Skip to main content
Glama

get_company

Read-only

Look up a company in an official public EU business register in one call, any of the 27 EU states. Live open registers by ID or name: EE (with board members), FR (with directors), CZ, FI, PL (KRS number or NIP), LV, IE, HR (Sudski registar: OIB, MBS or full/partial name; no officers in the public API); DK (CVR via Datafordeler: CVR number or full registered name; no persons); NL (KVK open dataset, free: basic data of BV and NV by KVK number only, no names or persons; names return the kvk.nl search link plus GLEIF LEI holders); LT, SE and SI from nightly snapshots of the official open bulk files (data_as_of in the answer). Other states return the official register lookup URL plus matching LEI holders from GLEIF. Any EU VAT number is checked live in VIES (id_type=vat or a prefixed number like DE123456789); LEIs via id_type=lei or country=EU. Every answer has source_url, licence and retrieved_at. Free, read-only.

Input Schema

NameRequiredDescriptionDefault
queryYesRegistry code (EE 8 digits, FR SIREN, CZ IČO, FI Y-tunnus, PL KRS or NIP, LV 11 digits, LT 9 digits, SE organisationsnummer 10 digits, SI matična številka 7 or 10 digits, IE company number, HR OIB 11 digits or MBS, DK CVR 8 digits, NL KVK number 8 digits), VAT number, LEI or company name.
countryYesEU member state code (EE, FR, DE, ...; EL or GR for Greece), or EU for an LEI search.
id_typeNoOptional. vat = VIES check, lei = GLEIF. Default: detected from the query.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Registry code (EE 8 digits, FR SIREN, CZ IČO, FI Y-tunnus, PL KRS or NIP, LV 11 digits, LT 9 digits, SE organisationsnummer 10 digits, SI matična številka 7 or 10 digits, IE company number, HR OIB 11 digits or MBS, DK CVR 8 digits), VAT number, LEI or company name."New value: +"Registry code (EE 8 digits, FR SIREN, CZ IČO, FI Y-tunnus, PL KRS or NIP, LV 11 digits, LT 9 digits, SE organisationsnummer 10 digits, SI matična številka 7 or 10 digits, IE company number, HR OIB 11 digits or MBS, DK CVR 8 digits, NL KVK number 8 digits), VAT number, LEI or company name."
  2. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Registry code (EE 8 digits, FR SIREN, CZ IČO, FI Y-tunnus, PL KRS or NIP, LV 11 digits, LT 9 digits, SE organisationsnummer 10 digits, SI matična številka 7 or 10 digits, IE company number, HR OIB 11 digits or MBS), VAT number, LEI or company name."New value: +"Registry code (EE 8 digits, FR SIREN, CZ IČO, FI Y-tunnus, PL KRS or NIP, LV 11 digits, LT 9 digits, SE organisationsnummer 10 digits, SI matična številka 7 or 10 digits, IE company number, HR OIB 11 digits or MBS, DK CVR 8 digits), VAT number, LEI or company name."
  3. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Registry code (EE 8 digits, FR SIREN, CZ IČO, FI Y-tunnus, PL KRS or NIP, LV 11 digits, LT 9 digits, IE company number, HR OIB 11 digits or MBS), VAT number, LEI or company name."New value: +"Registry code (EE 8 digits, FR SIREN, CZ IČO, FI Y-tunnus, PL KRS or NIP, LV 11 digits, LT 9 digits, SE organisationsnummer 10 digits, SI matična številka 7 or 10 digits, IE company number, HR OIB 11 digits or MBS), VAT number, LEI or company name."
  4. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Registry code (EE 8 digits, FR SIREN, CZ IČO, FI Y-tunnus, PL KRS or NIP, LV 11 digits, LT 9 digits, IE company number), VAT number, LEI or company name."New value: +"Registry code (EE 8 digits, FR SIREN, CZ IČO, FI Y-tunnus, PL KRS or NIP, LV 11 digits, LT 9 digits, IE company number, HR OIB 11 digits or MBS), VAT number, LEI or company name."
  5. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, it discloses live versus snapshot data sources, country-specific limitations, fallback behavior, VAT/LEI handling, snapshot freshness via data_as_of, and answer provenance fields such as source_url, licence, and retrieved_at. This is unusually rich behavioral context for an open-world read-only lookup tool.

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?

The purpose is front-loaded and the dense country-specific details are relevant. However, the single long paragraph with many parenthetical clauses is harder to scan than it could be, even though little of the content is wasted.

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?

Given the complexity, lack of an output schema, and open-world nature, the description is complete: it covers supported countries, lookup modes, fallback behavior, limitations, VAT/LEI flows, and what fields every answer includes.

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 description coverage is 100%, so the schema already documents the query formats, country codes, and id_type enum. The description adds some operational context around prefixed VAT numbers and country=EU for LEI searches, but most parameter meaning is repeated from the schema rather than adding substantially new semantics.

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?

The description states a specific verb and resource: 'Look up a company in an official public EU business register.' It makes the scope explicit ('any of the 27 EU states') and distinguishes itself from generic lookup or sibling tools by emphasizing official registers, live versus snapshot data, VIES, and GLEIF fallback.

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?

It gives clear usage context, including which countries support ID/name lookups, what is unavailable in some registers (e.g. no officers in HR, no persons in DK/NL), and the fallback behavior for other states. It does not explicitly contrast with alternative tools, but no direct sibling company-lookup alternative exists in the sibling list.

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.