Sirenic

Norwegian legal events

get_norwegian_company_legal_events

Read-only

Legal events of a Norwegian company from the official Enhetsregisteret (Brønnøysundregistrene, NLOD 2.0): bankruptcy (konkurs, with the date the register publishes), voluntary winding-up, compulsory winding-up / forced dissolution, and strike-off — plus the current flags, re-checked live at call time. A registered company with no event returns an explicit positive answer (aucun_evenement: true), asserted only when the record was live-verified, no flag is raised, it is not struck off and the journal is current. Coarser than the French BODACC: the Norwegian bankruptcy register is not public, so there is no ruling text, no court and no insolvency practitioner; origine_date tells a register-published date from a Sirenic observation date, and date_au_plus_tard: true marks a date that is only an upper bound (flag already raised when first observed — started on or before). 3-year window (the source's own republication limit), except a still-open procedure, whose opening is always served. Only legal persons are served: natural-person forms (ENK, PERS, TVAM), estates named after one (KBO, BO) and any unrecognised form are refused. Paid via x402 ($0.02 in USDC or EURC).

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	9-digit Norwegian organisasjonsnummer, no spaces, e.g. 923609016
`api_key`	No	Optional Sirenic API key (srn_live_…) to pay with prepaid credits instead of x402 — no wallet needed. Get one at https://api.sirenic.eu/compte. Ignored when x_payment is provided (the signed payment wins). On insufficient balance the tool returns a credits error, not an x402 quote.
`x_payment`	No	Optional signed x402 PAYMENT-SIGNATURE header value. Omit to receive the payment quote.

Output Schema

TableJSON Schema

Name	Required	Description
`hint`	No	How to settle the quote, present when payment_required is true.
`quote`	No	The signable x402 payment requirements when payment_required is true: {x402Version, accepts[]} where each entry carries scheme, network, amount, asset and payTo (USDC and EURC options at the same numeric amount). Sign one entry and call again with `x_payment`.
`resultat`	No	The endpoint's JSON response when payment_required is false. Paid responses carry `source`, `disclaimer` and an Ed25519 signature; KYB, batch KYB, sanctions, intelligence and the five invoicing tools (prepare_french_invoice_file, prepare_european_invoice_file, prepare_french_einvoicing_recipient, verify_iban_bank, validate_eu_vat_number) also carry a `provenance` array — one entry per block served, with the official register, licence, version, `as_of` date and `precision_as_of` (what that date means). Codes are documented at GET /v1/provenance/registres (free).
`payment_required`	Yes	True when this response is an x402 payment quote instead of data: settle one of the quote's `accepts` options and call the tool again with `x_payment`.

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds substantial behavior beyond them: live re-verification at call time, the precise semantics of aucun_evenement (asserted only when live-verified), the origine_date distinction, and the date_au_plus_tard upper-bound flag. It also discloses data coarseness (no ruling text, court, or insolvency practitioner), which sets accurate expectations for return values.

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 dense and long, but every sentence carries a distinct fact — event taxonomy, answer semantics, date semantics, window policy, eligibility, pricing. It is front-loaded with the core purpose and organized so constraints follow the main definition, with no redundant clauses.

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 paid, jurisdiction-specific tool with an output schema and three parameters, the description covers everything an agent needs: source and license, event types, answer semantics, date interpretation, coverage window, eligibility restrictions, and payment method. The output schema covers return structure, so the extra explanation of aucun_evenement and flags is a bonus that aids correct interpretation.

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 coverage is 100%, so the schema fully documents all three parameters including the 9-digit id pattern with an example and the api_key/x_payment trade-off. The description adds only the $0.02 x402 cost relevant to payment parameters, which is genuine but marginal added value; baseline 3 is correct.

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?

Names a specific verb and resource — legal events of a Norwegian company from the official Enhetsregisteret — and enumerates the exact event types (bankruptcy, voluntary winding-up, compulsory winding-up, strike-off) plus current flags. The scope detail (live re-check, 3-year window) clearly separates it from siblings like get_norwegian_company_accounts without needing to inspect the schema.

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?

Provides clear context on scope and eligibility: a 3-year window, a still-open-procedure exception, and an explicit refusal rule for natural-person forms (ENK, PERS, TVAM), estates (KBO, BO) and unrecognised forms. The comparison to the French BODACC hints at where richer data lives, though it never names a sibling tool for explicit routing.

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

All Sirenic tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation2/5

Several French company bundles overlap in purpose (get_french_company_file, get_french_company_kyb_file, get_french_company_intelligence, get_french_company_health_summary) and procurement/competitor tools overlap (get_french_company_public_procurement, get_eu_procurement_awards, get_company_procurement_competitors). Although descriptions try to differentiate, an agent could easily select the wrong tool when looking for a company overview or procurement history.

Naming Consistency4/5

Most tools follow a consistent get_/list_/search_ + country + entity pattern, e.g. get_french_company_profile, list_danish_company_filings, so navigation is predictable. Deviations like check_french_regulator_alerts, suggest_company_names, verify_iban_bank, and the prepare_* verbs are understandable but break the strict verb_noun pattern.

Tool Count1/5

77 tools is excessive for a single server regardless of how broad the domain is; the calibration treats 50+ as an extreme mismatch. While France is well covered and several countries appear, much of the surface is micro-endpoints (list_/get_ filing pairs per country) that could be consolidated.

Completeness3/5

France coverage is impressively complete (identity, financials, legal events, procurement, IP, risk, surveillance, invoicing), and the surveillance lifecycle has create/get/renew/stop. But European coverage is inconsistent: Germany has only insider transactions, Spain only acts, and several major jurisdictions lack accounts/officers/insolvency; an agent expecting 'European company due diligence' will hit dead ends.

Resources

Need Help?