Companies House

Get Officers

get_officers

Read-onlyIdempotent

List directors, secretaries, or LLP members for a UK company by company_number (from search_companies). Returns each officer's name, role, appointment/resignation dates, occupation, nationality, country of residence, and date of birth (month/year). Supports register_type filter (directors | secretaries | llp-members) and pagination.

Input Schema

TableJSON Schema

Name	Required	Description
`start_index`	No	Pagination offset (default 0)
`register_type`	No	directors \| secretaries \| llp-members (optional restriction)
`company_number`	Yes	UK company number (e.g. "07098618") OR the company NAME (e.g. "Ocado Group") — a name is resolved here automatically and the match is echoed back as resolved_from_name. Pass whichever you have; do not guess a number from memory, since a plausible wrong one returns a clean officer list for a different company.
`items_per_page`	No	1-100 (default 35)

Output Schema

TableJSON Schema

Name	Required	Description
`total`	Yes	Total number of officers
`active`	No	Number of currently active officers
`officers`	Yes	List of officers (directors, secretaries, etc.)
`resigned`	No	Number of resigned officers
`company_number`	Yes	UK company number

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 13, 2026

changedInput schema / properties / company_number / description

Previous value: -"UK company number, resolved via companies_house_search_companies — NEVER guessed from memory: a plausible wrong number returns a clean empty officer list for a different company."New value: +"UK company number (e.g. \"07098618\") OR the company NAME (e.g. \"Ocado Group\") — a name is resolved here automatically and the match is echoed back as resolved_from_name. Pass whichever you have; do not guess a number from memory, since a plausible wrong one returns a clean officer list for a different company."

Changed1 schema field changedAug 11, 2026

changedInput schema / properties / company_number / description

Previous value: -"UK company number"New value: +"UK company number, resolved via companies_house_search_companies — NEVER guessed from memory: a plausible wrong number returns a clean empty officer list for a different company."

Changed2 schema fields changedMay 22, 2026

addedInput schema / examples

Added value: +[
+  {
+    "company_number": "00006245"
+  },
+  {
+    "company_number": "00006245",
+    "items_per_page": 50,
+    "register_type": "directors"
+  }
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "active": {
+      "description": "Number of currently active officers",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "company_number": {
+      "description": "UK company number",
+      "type": "string"
+    },
+    "officers": {
+      "description": "List of officers (directors, secretaries, etc.)",
+      "items": {
+        "properties": {
+          "address": {
+            "description": "Officer address details",
+            "type": [
+              "object",
+              "null"
+            ]
+          },
+          "appointed_on": {
+            "description": "Appointment date (ISO format)",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "country_of_residence": {
+            "description": "Country of residence",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "dob": {
+            "description": "Date of birth (month and year only)",
+            "properties": {
+              "month": {
+                "type": "number"
+              },
+              "year": {
+                "type": "number"
+              }
+            },
+            "type": [
+              "object",
+              "null"
+            ]
+          },
+          "name": {
+            "description": "Officer name",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "nationality": {
+            "description": "Nationality",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "occupation": {
+            "description": "Officer occupation",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "resigned_on": {
+            "description": "Resignation date (ISO format) if applicable",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "role": {
+            "description": "Officer role (Director, Secretary, etc.)",
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "resigned": {
+      "description": "Number of resigned officers",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "total": {
+      "description": "Total number of officers",
+      "type": "number"
+    }
+  },
+  "required": [
+    "company_number",
+    "total",
+    "officers"
+  ],
+  "type": "object"
+}

First observedMay 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safe-read profile is covered. The description adds useful context on the response fields (name, role, appointment dates, etc.) and the register_type filter, without contradicting annotations. It does not mention automatic name resolution, but that is present in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: purpose, return content, and options. It is front-loaded with the verb 'List', contains no filler, and every sentence adds distinct information.

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 a comprehensive schema (100% coverage), strong annotations, and an output schema, the description covers the essential usage flow (start from search_companies), the data returned, and available filters. It is sufficient for an agent to select and invoke the tool correctly.

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%, with each parameter fully described. The description restates the register_type filter and pagination but adds no new syntactic or semantic details beyond what the schema already provides. The company_number name-resolution behavior is only in the schema, not the description.

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 opens with 'List directors, secretaries, or LLP members for a UK company by company_number', a specific verb, resource, and scope. It clearly differentiates from sibling tools like get_persons_with_significant_control by naming officer roles explicitly.

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 says 'from search_companies', which implies a prerequisite lookup step and provides clear context for when to use this tool. However, it does not explicitly mention alternatives like get_persons_with_significant_control or state when not to use this tool, so it falls short of full alternative guidance.

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

All Companies House tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.