registry-mcp — national company registries

Statutory filing deadlines for a company

company_deadlines

Read-onlyIdempotent

Give the next occurrence of each statutory filing deadline a company faces.

country="NO" covers the Norwegian calendar (Regnskapsregisteret, Skatteetaten) for a company looked up by organisasjonsnummer (orgnr, org.nr) in Brønnøysundregistrene / Enhetsregisteret (brreg): årsregnskap, generalforsamling, skattemelding, aksjonærregisteroppgaven, mva-melding, a-melding. country="GB" covers the two Companies House obligations for a company number (CRN): the annual accounts filing and the confirmation statement (CS01). country="SE" covers the two Swedish obligations of an aktiebolag (AB) or ekonomisk förening (EK) looked up by organisationsnummer at Bolagsverket: the ordinary general meeting (ordinarie bolagsstämma / årsstämma) at six months from the financial year end, and the annual report (årsredovisning) at seven, where the late-filing fee (förseningsavgift) begins.

Pass today (YYYY-MM-DD) for a reproducible answer; it defaults to the server's current UTC date. Quote due_date, not statutory_date, and quote each deadline's applies_because rather than presenting a date as unconditional fact — that sentence carries the legal form or flag the date rests on, its statute, any assumption still in it, and for the UK whether it is Companies House's own figure or one computed here. days_until goes negative for a filing Companies House still shows as overdue. Swedish dates assume a financial year ending 31 December unless you pass include=["filings"], which substitutes the year end of the last filed annual report where Bolagsverket's document list holds one; the filing date is an outer limit regardless, since a company whose general meeting was earlier must file earlier. An empty deadlines list is a real answer — a bankrupt, deleted or compulsorily-liquidated entity, a branch/sub-unit, or any company whose status is not active — and notes explains why. registry://rules/{country} carries each country's full deadline rules, roll-forward treatment and legal sources. rules_last_reviewed names the date this country's statutes and day-count arithmetic were last checked against the law — a deadline computed long after that date should be re-verified before anyone acts on it.

Errors are the {"error": {"code", "message", "hint"}} envelope this server's instructions set out code by code; hint names the next call. This tool looks the entity up first, so any lookup_company error code can surface here too.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	The company's national identifier, normalised for you — a Norwegian organisasjonsnummer (orgnr), a Companies House company number (CRN), or a Swedish organisationsnummer or personnummer. Spaces, dots, hyphens, a NO...MVA suffix and a short CRN are accepted; list_countries gives each country's exact shape.
`today`	No	Date to compute deadlines from, YYYY-MM-DD; defaults to the server's current UTC date. Anything else is a bad_request naming the format.
`country`	No	ISO-3166-1 alpha-2 — NO Norway, GB United Kingdom, SE Sweden. UK is not a country code here and is rejected. Call list_countries for the live set.	NO
`include`	No	Attachment names that can change a computed deadline — narrower than lookup_company's include. Today only 'filings': one extra upstream request for the entity's filing history, supplying a real financial year end where 31 December would otherwise be assumed. Empty by default; Norway and the United Kingdom accept it and it changes nothing for them today. Any other value — including one lookup_company accepts, such as 'charges' — is a bad_request naming this tool's allowed set.

Output Schema

TableJSON Schema

Name	Required	Description
`notes`	No	Caveats to surface to the user, carried over from the company report: why the list is empty, an unclassified legal form, a status that suspends filing.
`today`	Yes	The date 'next occurrence' was computed from, inclusive. Echoed back so the answer is reproducible and an agent can tell a cached answer from a fresh one.
`country`	Yes	ISO-3166-1 alpha-2, upper-case.
`registry`	Yes	Registry slug, e.g. 'brreg'.
`deadlines`	No	One entry per obligation kind, always the next occurrence, sorted by due_date. An empty list is a real answer, not an error — read `notes` for why.
`company_id`	Yes	Canonical national identifier the deadlines were computed for.
`company_name`	No	Registered name, so the caller can echo it back to a user.
`rules_last_reviewed`	Yes	The date this country's deadline rules — the statutes and their day-count arithmetic — were last checked against the law; a deadline computed long after this date should be re-verified before anyone acts on it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 10, 2026

addedOutput schema / properties / rules_last_reviewed

Added value: +{
+  "description": "The date this country's deadline rules — the statutes and their day-count arithmetic — were last checked against the law; a deadline computed long after this date should be re-verified before anyone acts on it.",
+  "format": "date",
+  "title": "Rules Last Reviewed",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "country",
-  "registry",
-  "company_id",
-  "today"
-]New value: +[
+  "country",
+  "registry",
+  "company_id",
+  "today",
+  "rules_last_reviewed"
+]

Changed5 schema fields changedSep 9, 2026

changedInput schema / properties / country / description

Previous value: -"ISO-3166-1 alpha-2 country code. 'NO' = Norway (Brønnøysundregistrene / Enhetsregisteret), 'GB' = United Kingdom (Companies House), 'SE' = Sweden (Bolagsverket). 'UK' is not a country code here and is rejected. Call list_countries for the current set rather than hard-coding one."New value: +"ISO-3166-1 alpha-2 — NO Norway, GB United Kingdom, SE Sweden. UK is not a country code here and is rejected. Call list_countries for the live set."

removedInput schema / properties / country / examples
```
Removed value: -[
-  "NO",
-  "GB",
-  "SE"
-]
```

changedInput schema / properties / id / description

Previous value: -"The company's national identifier. Norway (country='NO'): a nine-digit organisasjonsnummer (orgnr), e.g. '923609016'; spaces, dots and a 'NO...MVA' VAT suffix are accepted and normalised. United Kingdom (country='GB'): a Companies House company number (CRN), eight characters, e.g. '00445790' or 'OC303675'; a short number is zero-padded for you. Sweden (country='SE'): a ten-digit organisationsnummer, e.g. '5560160680', or a twelve-digit personnummer for a sole trader."New value: +"The company's national identifier, normalised for you — a Norwegian organisasjonsnummer (orgnr), a Companies House company number (CRN), or a Swedish organisationsnummer or personnummer. Spaces, dots, hyphens, a NO...MVA suffix and a short CRN are accepted; list_countries gives each country's exact shape."

changedInput schema / properties / include / description

Previous value: -"Optional attachment names that can change a computed deadline — a narrower set than lookup_company's include argument, which also offers attachments no date depends on. Today this is just 'filings': a second, independent upstream request for the entity's filing history, which supplies a real financial year end where one would otherwise be assumed to be 31 December. Costs one extra upstream request beyond the base lookup, only when asked; empty by default. Norway and the United Kingdom accept it too but it changes nothing for them today — their own dates already come from a published figure or a different computation. An include value this operation does not accept (including one lookup_company does, such as 'charges' or 'financials') is a bad_request naming the allowed set for this tool specifically."New value: +"Attachment names that can change a *computed* deadline — narrower than lookup_company's include. Today only 'filings': one extra upstream request for the entity's filing history, supplying a real financial year end where 31 December would otherwise be assumed. Empty by default; Norway and the United Kingdom accept it and it changes nothing for them today. Any other value — including one lookup_company accepts, such as 'charges' — is a bad_request naming this tool's allowed set."

changedInput schema / properties / today / description

Previous value: -"Date to compute deadlines from, YYYY-MM-DD. Defaults to the server's current UTC date — pass it explicitly for a reproducible answer. A value that is not YYYY-MM-DD is a bad_request naming the required format."New value: +"Date to compute deadlines from, YYYY-MM-DD; defaults to the server's current UTC date. Anything else is a bad_request naming the format."

Changed4 schema fields changedSep 9, 2026

changedInput schema / properties / country / description

Previous value: -"ISO-3166-1 alpha-2 country code. 'NO' = Norway (Brønnøysundregistrene / Enhetsregisteret), 'GB' = United Kingdom (Companies House). 'UK' is not a country code here and is rejected. Call list_countries for the current set rather than hard-coding one."New value: +"ISO-3166-1 alpha-2 country code. 'NO' = Norway (Brønnøysundregistrene / Enhetsregisteret), 'GB' = United Kingdom (Companies House), 'SE' = Sweden (Bolagsverket). 'UK' is not a country code here and is rejected. Call list_countries for the current set rather than hard-coding one."

changedInput schema / properties / country / examples

Previous value: -[
-  "NO",
-  "GB"
-]New value: +[
+  "NO",
+  "GB",
+  "SE"
+]

changedInput schema / properties / id / description

Previous value: -"The company's national identifier. Norway (country='NO'): a nine-digit organisasjonsnummer (orgnr), e.g. '923609016'; spaces, dots and a 'NO...MVA' VAT suffix are accepted and normalised. United Kingdom (country='GB'): a Companies House company number (CRN), eight characters, e.g. '00445790' or 'OC303675'; a short number is zero-padded for you."New value: +"The company's national identifier. Norway (country='NO'): a nine-digit organisasjonsnummer (orgnr), e.g. '923609016'; spaces, dots and a 'NO...MVA' VAT suffix are accepted and normalised. United Kingdom (country='GB'): a Companies House company number (CRN), eight characters, e.g. '00445790' or 'OC303675'; a short number is zero-padded for you. Sweden (country='SE'): a ten-digit organisationsnummer, e.g. '5560160680', or a twelve-digit personnummer for a sole trader."

addedInput schema / properties / include

Added value: +{
+  "default": [],
+  "description": "Optional attachment names that can change a computed deadline — a narrower set than lookup_company's include argument, which also offers attachments no date depends on. Today this is just 'filings': a second, independent upstream request for the entity's filing history, which supplies a real financial year end where one would otherwise be assumed to be 31 December. Costs one extra upstream request beyond the base lookup, only when asked; empty by default. Norway and the United Kingdom accept it too but it changes nothing for them today — their own dates already come from a published figure or a different computation. An include value this operation does not accept (including one lookup_company does, such as 'charges' or 'financials') is a bad_request naming the allowed set for this tool specifically.",
+  "examples": [
+    [
+      "filings"
+    ],
+    []
+  ],
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedSep 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already signal read-only and idempotent, and the description adds meaningful runtime behavior: empty `deadlines` is a real answer for inactive entities, `days_until` can go negative for overdue UK filings, the tool performs an upstream entity lookup first, and `rules_last_reviewed` exposes when the legal rules were last verified. No contradiction with annotations.

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 long but every block earns its place: country coverage, parameter behavior, output interpretation, error handling, and legal-source caveats are all separately and clearly organized. The one-sentence purpose is front-loaded before any country-specific detail.

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 multi-country complexity, the description covers what an agent needs to invoke the tool correctly and interpret results: correct identifier shapes, country differences, how `include` alters Swedish computations, how to quote `due_date` versus `statutory_date`, the meaning of an empty `deadlines` list, error envelope behavior, and the freshness caveat from `rules_last_reviewed`. The output schema covers the remaining return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers 100% of parameters, but the description adds substantial semantics beyond it: `country` spells out what each jurisdiction covers, `include` explains that only 'filings' can change a computed deadline and that Norway/UK accept it without effect, and `today` is tied to reproducibility. It also clarifies that `id` is normalised from several input formats.

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 first sentence names a specific verb and resource: 'Give the next occurrence of each statutory filing deadline a company faces.' It then distinguishes the tool by country and filing type, and the sibling tools (lookup_company, search_company, list_countries) are clearly different operations.

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 gives extensive context on how to call the tool: which country codes are supported, how `today` makes results reproducible, which output fields to quote, and that `include=['filings']` changes Swedish year-end assumptions. It does not explicitly say 'use this instead of lookup_company when you need deadlines,' but the functional separation is clear enough.

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

All registry-mcp — national company registries 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.