Skip to main content
Glama

Get the structured profile of a company by its registry ID

get_company_profile
Read-onlyIdempotent

Retrieve the full profile of a company using its registry-specific ID, returning unified fields like jurisdiction, status, incorporation date, and address, plus raw upstream data for cross-country comparison. Use this tool to get a company's core details before accessing filings or officers with dedicated tools.

Instructions

Fetch the full profile of a company by its registry-specific ID. Returns unified top-level fields (jurisdiction, company_id, company_name, status, status_detail, incorporation_date, registered_address) plus a jurisdiction_data object carrying the raw upstream fields verbatim. The status field is a coarse four-value enum (active / inactive / dissolved / unknown) safe for cross-country comparison; status_detail carries the registry's native status string. The registered_address top-level field is a flattened string; the original nested address (when upstream provides one) is preserved in jurisdiction_data.

Does NOT include filings, officers, PSCs, shareholders, or charges — call the dedicated tools (list_filings, get_officers, get_persons_with_significant_control, get_shareholders, get_charges) for those.

Input company_id is the registry's canonical identifier for the jurisdiction; shapes vary (8-digit numbers, prefixed alphanumerics, hyphenated forms, multi-shape routing by length, etc.) and many registries accept light normalisation (leading-zero padding, whitespace / hyphen stripping, alternate equivalents). Pull a company_id from search_companies whenever possible rather than guessing.

Optional flags include_vr, include_history, include_establishments enable extra upstream fetches on jurisdictions that support them and are ignored elsewhere. fresh: true bypasses the cache.

Per-country caveats (ID format, accepted input shapes, jurisdiction_data field catalogue, paid-tier gates, status taxonomy) are available on demand — call list_jurisdictions({jurisdiction:"<code>"}) for the full schema, or list_jurisdictions({supports_tool:"get_company_profile"}) for the country-support matrix. All registries are official government sources.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jurisdictionYesISO 3166-1 alpha-2 country code (uppercase). All registries are official government sources. Currently supported: AU, BE, CA, CA-BC, CA-NT, CH, CY, CZ, DE, ES, FI, FR, GB, HK, IE, IM, IS, IT, KR, KY, LI, MC, MX, MY, NL, NO, NZ, PL, RU, TW. Per-country capability, ID format, examples, status mapping, and caveats: call `list_jurisdictions({jurisdiction:'<code>'})`. To find which countries support a specific tool: `list_jurisdictions({supports_tool:'<tool>'})`.
company_idYesRegistry-specific company identifier. GB: 8-digit Companies House number (e.g. '00445790'), or SC/NI/OC/LP prefix (e.g. 'SC123456'). NO: 9-digit organisation number (e.g. '923609016'). AU: 11-digit ABN (e.g. '16009661901') or 9-digit ACN (e.g. '009661901'). IE: numeric (e.g. '104547'); add '/B' suffix to query the business-name register (e.g. '540274/B'). FR: 9-digit SIREN (e.g. '652014051') or 14-digit SIRET (auto-resolved to parent SIREN). FI: Y-tunnus '7digits-1digit' (e.g. '0112038-9'); 8-digit no-dash form auto-reformatted. CZ: 8-digit IČO (e.g. '27074358'); 1-7 digit values auto-padded. PL: 10-digit KRS number (e.g. '0000635012'); 1-9 digit values auto-padded. See the tool description for full details.
include_vrNoCZ only. When true, also fetch the VR (commercial register) record and merge it under jurisdiction_data._vr — adds spisovaZnacka (case file number array; use latest by datumZapisu), zakladniKapital (share capital history with vklad/splaceni), akcie (share emissions), cinnosti (registered business activities), insolvence + konkursy (insolvency proceedings — full records, not just the administrators surfaced via get_officers), rejstrik (public-register type), stavSubjektu. Slower than the basic profile (one extra upstream call) but avoids needing get_officers/PSC/charges just to inspect these fields.
include_historyNoPL only. When true, ALSO fetch /OdpisPelny and graft the full historical entry log (naglowekP.wpis[] — every change ever made to the KRS record, with numerWpisu / opis / dataWpisu / sygnaturaAktSprawyDotyczacejWpisu) onto jurisdiction_data. Doubles upstream calls.
include_establishmentsNoBE only. When true, ALSO fetch the vestiginglijst (establishment-units list) and graft it onto jurisdiction_data.establishments[] — each unit's 10-digit vestigingsnummer, status, start date, name, and address. One extra upstream call; omit to just get the count + establishments_list_url.
freshNoBypass cache. Default false.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queried_atYesISO-8601 + Europe/London timezone stamp for when the registry was queried.
jurisdictionNo
company_idNo
company_nameNo
statusNoFour-value unified status safe for cross-jurisdiction comparison.
status_detailNo
incorporation_dateNo
registered_addressNo
jurisdiction_dataNoFull original response fields from the upstream registry, field names unchanged. Shape is jurisdiction-specific — see `list_jurisdictions({ jurisdiction: '<CODE>' })`.
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the safety profile is clear. The description adds behavioral context: cache bypass via `fresh: true`, extra upstream fetches for certain jurisdictions, and the nature of `status` and `status_detail`. It does not mention rate limits or auth, but those are not critical given annotations. Score 4 because it adds good context beyond annotations.

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 description is well-structured with clear paragraphs, each serving a purpose: top-level fields, exclusions, input guidance, optional flags, and caveats. It is fairly long but every sentence adds value; front-loading the core functionality works well. A slight reduction for verbosity in the caveats section, but overall efficient.

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 tool's complexity (6 parameters, many jurisdictional nuances), the description is thorough: it covers output structure, exclusions, alternative tools, parameter behavior, and where to get further info (`list_jurisdictions`). Output schema exists, so return values need not be detailed. This is complete for the context.

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 baseline is 3. The description adds significant context for each parameter: e.g., explaining `company_id` shapes with examples for multiple jurisdictions, and for `include_vr`/`include_history`/`include_establishments` it explicitly states jurisdiction restrictions and what gets merged. This extra semantics raises the score to 4.

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 clearly states that the tool fetches the full profile of a company by its registry-specific ID, listing the unified fields and the `jurisdiction_data` object. It explicitly distinguishes what it does NOT include (filings, officers, etc.) and names the dedicated sibling tools for those, making the purpose very clear and distinct from siblings.

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?

The description gives explicit guidance on when to use this tool vs alternatives: it lists what is not included and points to dedicated tools (`list_filings`, `get_officers`, etc.). It also advises to use `search_companies` to get the `company_id` rather than guessing. Optional flags are explained with jurisdictional scope, and it directs users to `list_jurisdictions` for caveats and support matrix.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sophymarine/openregistry'

If you have feedback or need assistance with the MCP directory API, please join our Discord server