Skip to main content
Glama

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
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 company ID, from search_companies.
include_resignedNoInclude resigned officers. Default true; set false for currently-serving only.
group_by_personNoCZ only. Dedupe the same person across consecutive appointments (board member → chair → vice-chair) into one entry; appointments list under `jurisdiction_data._appointments[]`. Default false.
freshNoBypass cache; refetch from upstream.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queried_atYesISO-8601 + Europe/London timezone stamp for when the registry was queried.
officersNo
itemsNo
dataNoAdapter returns a bare array; textResult() wraps under `data`.
total_countNo
next_cursorNo
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.

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