openregistry

Officers

get_officers

Read-onlyIdempotent

Retrieve a company's current and past officers from 27 national registries, including directors, secretaries, and partners. Supports filtering by active status and deduplication for consecutive appointments.

Instructions

Return a company's officers — current directors, secretaries, members, partners, board members, procurists, liquidators, plus historical resignations by default. Each officer has a unified shape (officer_id, name, role, appointed_on, resigned_on, is_active) plus raw upstream fields in jurisdiction_data. Role labels pass through in the registry's native language (e.g. Styremedlem, Předseda představenstva, Président); translate client-side. Birth-date precision varies by registry.

Officer-ID stability varies: corporate officers usually carry the corporate's own company_id; natural persons may carry a synthetic index. Some registries mask names under GDPR — that masking is upstream. Jurisdictions without an officer feed return 501.

Input Schema

TableJSON Schema

Name	Required	Description
`jurisdiction`	Yes	ISO 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_id`	Yes	Registry company ID, from search_companies.
`include_resigned`	No	Include resigned officers. Default true; set false for currently-serving only.
`group_by_person`	No	CZ only. Dedupe the same person across consecutive appointments (board member → chair → vice-chair) into one entry; appointments list under `jurisdiction_data._appointments[]`. Default false.
`fresh`	No	Bypass cache; refetch from upstream.

Output Schema

TableJSON Schema

Name	Required	Description
`queried_at`	Yes	ISO-8601 + Europe/London timezone stamp for when the registry was queried.
`officers`	No
`items`	No
`data`	No	Adapter returns a bare array; textResult() wraps under `data`.
`total_count`	No
`next_cursor`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.0.4May 12, 2026

addedInput schema / properties / company_id / description

Added value: +"Registry company ID, from search_companies."

addedInput schema / properties / fresh / description

Added value: +"Bypass cache; refetch from upstream."

changedInput schema / properties / group_by_person / description

Previous value: -"CZ only. When true, dedupe the same person across multiple appointments (e.g. board member → chair → vice-chair) into a single entry. Identity key is (name + datumNarozeni for natural persons, or pravnickaOsoba.ico for corporate). Each grouped entry's jurisdiction_data._appointments[] lists all roles with their dates. Default false (returns one entry per appointment, matching GB behaviour)."New value: +"CZ only. Dedupe the same person across consecutive appointments (board member → chair → vice-chair) into one entry; appointments list under `jurisdiction_data._appointments[]`. Default false."

changedInput schema / properties / include_resigned / description

Previous value: -"Include officers who have resigned. Default true. Set to false to get only currently serving officers."New value: +"Include resigned officers. Default true; set false for currently-serving only."

changedOutput schema / properties / officers / items / properties / jurisdiction_data / description

Previous value: -"Full original response fields from the upstream registry, field names unchanged. Shape is jurisdiction-specific — see `list_jurisdictions({ jurisdiction: '<CODE>' })`."New value: +"Full original response fields from the upstream registry, field names unchanged. Shape is jurisdiction-specific - see `list_jurisdictions({ jurisdiction: '<CODE>' })`."

First observedv1.0.3Apr 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations confirm read-only, non-destructive, idempotent behavior. The description adds valuable behavioral details: default include_resigned flag, handling of role labels in native language, birth-date precision variations, corporate officer ID mapping, GDPR masking, and 501 for unsupported jurisdictions. No contradictions.

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 moderately sized but efficiently front-loaded with core purpose and key behavioral details. Each sentence adds value, though could be slightly more structured (e.g., bullet points for limitations).

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 (multiple jurisdictions, officer types, data nuances), the description covers all critical aspects: scope, defaults, language, privacy, id stability, error handling. With full schema coverage, annotations, and an output schema, the description is sufficiently complete.

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% with parameter descriptions. The description adds extra meaning: group_by_person is CZ-only, jurisdiction string refers to full capability via list_jurisdictions, and fresh bypasses cache. This enhances understanding beyond schema alone.

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 the tool returns a company's officers including current and historical, with specific roles enumerated. It differentiates the tool's scope from siblings like get_shareholders or search_officers, making purpose unambiguous.

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?

The description provides usage context like default behavior (include_resigned=true), language handling for role labels, birth-date precision, and id stability. It mentions unsupported jurisdictions returning 501 and directs to list_jurisdictions for details. Lacks explicit when-not-to-use versus siblings.

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

Deploy Server