Skip to main content
Glama

Statutory filing deadlines for a company

company_deadlines
Read-onlyIdempotent

Get the next statutory filing deadlines for a company in Norway or the UK by its official company ID.

Instructions

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).

Pass today (YYYY-MM-DD) for a reproducible answer; it defaults to the server's current UTC date. Quote due_date, not statutory_date. Each deadline's applies_because states where the date came from — quote it rather than presenting a date as unconditional fact: for Norway it names the legal form or flag and any assumption behind a computed date, and for the UK it says whether the date is Companies House's own published figure or one this tool computed from the statutory period. UK dates never roll forward off a weekend or bank holiday, so due_date equals statutory_date there; days_until goes negative for a filing Companies House still shows as overdue rather than rolling it to the next cycle. An empty deadlines list is a real answer — for Norway a bankrupt, deleted or compulsorily-liquidated entity or a branch/sub-unit, and for the UK any company whose status is not active — and notes explains why.

On error, this tool raises with the error text {"error": {"code", "message", "hint"}}. bad_request means today was not YYYY-MM-DD — fix the format and retry. Any lookup_company error code (invalid_id, not_found, unsupported_country, upstream_error, upstream_timeout) can also surface here, since this tool looks the entity up first — follow that code's hint.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe 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.
todayNoDate 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.
countryNoISO-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.NO

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoCaveats 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.
todayYesThe 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.
countryYesISO-3166-1 alpha-2, upper-case.
registryYesRegistry slug, e.g. 'brreg'.
deadlinesNoOne 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_idYesCanonical national identifier the deadlines were computed for.
company_nameNoRegistered name, so the caller can echo it back to a user.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare the tool read-only, idempotent, open-world, and non-destructive, and the description adds substantial behavioral detail beyond that: `due_date` must be quoted rather than `statutory_date`, `applies_because` explains date provenance, UK dates never roll off weekends, `days_until` can go negative, and an empty list is a real answer. It even documents error propagation from `lookup_company` with actionable hints.

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 sentence carries operational weight: country coverage, result-field guidance, edge-case meanings, and error handling are all present with no filler. The top-loaded purpose sentence immediately orients the agent, and the paragraphs follow a logical order from scope to output interpretation to failures.

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?

For a tool with three parameters, an output schema, and complex country-specific behavior, the description is unusually complete. It explains what each country's results mean, how to quote results, when an empty list is legitimate, how errors are structured, and how to recover from `bad_request`. Nothing an agent needs to call and interpret this tool correctly is left unaddressed.

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?

The input schema already covers all three parameters at 100% coverage, so the baseline is 3. The description adds meaningful extra semantics: it maps `country='NO'` to the Norwegian deadline calendar and `country='GB'` to the two Companies House obligations, and it links `today` to reproducibility and `bad_request` format errors. That is more than the schema alone provides, though not a full replacement for the schema's detailed `id` documentation.

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 opening sentence states a specific verb and resource: 'Give the next occurrence of each statutory filing deadline a company faces.' It then distinguishes the two supported country scopes (Norway and the UK) and their registries and obligation types, so the agent can tell exactly what the tool covers and how it differs from sibling lookup/search/validation tools.

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 clear context on when this tool applies, including country-specific obligations, the meaning of an empty `deadlines` list, and the need to pass `today` for reproducible answers. It does not explicitly name alternatives or say 'use X instead when Y', so it falls just short of a 5, but the usage context is strong.

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

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/foretak/registry-mcp'

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