Sirenic

Swiss commercial-register publications (SOGC)

get_swiss_company_events

Read-only

Swiss company commercial-register publications from the Swiss Official Gazette of Commerce (SOGC/SHAB, SECO — public API, live with a 24 h cache, online since July 2018): every registration, change and deletion carrying the company's UID, newest first — date, publication number, canton, office, the company as published (name, UID, seat, eCH legal-form code, purpose, capital, address without the c/o line) before and after the change, and closed-list change flags (name, seat, address, purpose, capital, legal form, bankruptcy, liquidation, suspension, re-entry, other entries). The published free text is withheld (texte_retenu: true): it names persons. Beyond 60 listed publications the most recent are detailed and troncature says so. 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?

With readOnlyHint=true already present, the description still adds substantial behavioral context: the 24h cache, live source, withholding of free text (texte_retenu) because it names persons, troncature behavior beyond 60 publications, and the 404-on-unknown-UID semantics. No contradiction with the readOnlyHint or openWorldHint annotations — this is genuinely additive disclosure.

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 purpose is front-loaded and every sentence carries substantive information (source, ordering, content, withholding, truncation, errors, pricing). It is dense but not padded. It reads as one long run-on paragraph, which slightly hurts scannability, but there is zero waste.

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 payment mechanics, caching, truncation behavior, and an output schema, the description covers every operational aspect an agent needs: what is returned, what is withheld and why, truncation rules, error semantics (404, credits error), and both payment paths. Nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is 100%, so the schema already documents all three parameters well. The description adds value beyond the schema by explaining the payment flow — x402 paid mode, prepaid credits alternative, and that omitting x_payment returns the payment quote — which is contextual meaning not present in the property definitions.

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 a specific verb+resource ('Swiss company commercial-register publications from the Swiss Official Gazette of Commerce (SOGC/SHAB)') and enumerates exactly what is returned — registrations, changes, deletions with UID, newest first. It clearly differentiates from the many sibling tools by being Swiss-specific and events/publications-focused, distinct from get_swiss_company_insolvency and the other country event 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 strong contextual framing: what the source is (SECO public API, live since July 2018), the output ordering, and the closed-list of change flags covered. However, it does not explicitly name alternative tools or state when to prefer another sibling, so exclusions are left implicit rather than stated.

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?