Sirenic

Swiss company bankruptcy publications (SOGC)

get_swiss_company_insolvency

Read-only

Swiss company bankruptcy publications from the SOGC/SHAB (SECO — public API, live, 24 h cache, online since 2021): every publication whose debtor is the company (natural persons never served), newest first — preliminary bankruptcy notice, bankruptcy publication and call to creditors, suspension, schedule of claims and inventory, distribution list, closing, revocation, real-estate auction, recognition of a foreign bankruptcy — with decision date, deadlines, office, canton and the official labels in DE/FR/IT/EN. aucune_procedure: true is a fact bounded by the online archive for a company known to Zefix; bankruptcy and liquidation flags recorded in the register itself come with get_swiss_company_events. Unknown UID = 404 (no charge). Paid via x402 ($0.02 in USDC or EURC).

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Swiss UID (Unternehmens-Identifikationsnummer), CHE-xxx.xxx.xxx, e.g. CHE-102.732.681
`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, and every paid JSON response carries a `provenance` array (all tools since 2026-09-06) — one entry per block served, with the official register, licence, version, `as_of` date and `precision_as_of` (what that date means), plus the common per-block envelope: `etat` in a closed list (servi, absence_mesuree, absence_non_conclusive, partiel, perime, indisponible, sans_objet), `motif` when unavailable, `age_jours` (only for publication or ingestion dates), `couverture` (complete / partielle / non_mesurable with its measure) and `confiance` in bands (faible / moyenne / forte, only where a measure grounds it, never averaged across blocks). Read the states before the numbers: an absence_non_conclusive, indisponible or partiel block is never « nothing to report » — only absence_mesuree asserts an absence. Register codes: GET /v1/provenance/registres ; states, closed lists and reading rules: GET /v1/lecture (both free). The PDF tools carry no JSON envelope (the PDF report prints it).
`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`.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context: live/public API with a 24h cache, online since 2021, newest-first ordering, the bounded meaning of aucune_procedure, 404 behavior for unknown UIDs, and the x402 payment model. 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.

Conciseness4/5

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

Dense but purposeful: every clause contributes either scope, return-content detail, source context, an alternative tool, an error case, or pricing. It is somewhat long and could be structured more visually, but it contains no filler and the most important scoping information appears early.

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 output schema exists and annotations cover safety, the description is complete for invocation: it covers content type, ordering, language labels, archive-bound semantics, the relevant sibling tool, error behavior, and cost. An agent has enough information to call this 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%, so the schema already fully documents id, api_key, and x_payment, including the id pattern and example. The description adds payment context but no meaningful parameter-level semantics beyond what the schema provides, so the baseline 3 is appropriate.

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 states a concrete resource: bankruptcy publications from the SOGC/SHAB for Swiss companies, and enumerates the specific publication types returned. It clearly distinguishes this tool from the Swiss sibling get_swiss_company_events and from other countries' insolvency tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly defines scope (company debtors only, natural persons never served) and names the alternative get_swiss_company_events for register-level bankruptcy/liquidation flags. It also documents the unknown-UID 404 case, helping an agent understand when results may legitimately be empty or when a different tool is needed.

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

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.

Resources

Need Help?