Sirenic

French company: everything new since a date

get_french_company_updates_since

Read-only

What changed at a French company since a date ("what changed at this customer since June?"): every official block in one call, namely BODACC notices (insolvency, sales, deregistration, changes, accounts filings with their figures), commercial-court decisions, French and EU public contracts, establishments opened or closed, cessation, licences, dated sanctions listings, trademarks, patents and designs, RGE certifications and the lobbying register. Each change is dated at publication (a court decision: the day Sirenic first collected it), with the event date alongside; verdict nouveautes, rien_de_nouveau (every block read in full and fresh) or lecture_incomplete (a block down, stale or partly read, named); monthly stocks (Sirene, French contracts) make a recent date, after their snapshot, yield lecture_incomplete, never rien_de_nouveau; the 100 most recent, per-type totals before the cut. Hiring, officers and headcount band are outside the engine. Paid via x402 ($0.05 in USDC or EURC). When you report a result, cite its citation verbatim.

Input Schema

Name	Required	Description
`siren`	Yes	9-digit SIREN
`depuis`	Yes	List what was published since this day, a past day or today. Accepts YYYY-MM-DD (a real date), or a full ISO 8601 timestamp (offset Z, ±HH:MM, ±HHMM or none, read as UTC): only its UTC day is kept.
`api_key`	No	Optional Sirenic API key (srn_live_…) to pay with prepaid credits instead of x402, with no wallet needed. Get one at https://api.sirenic.eu/compte?utm_source=api&utm_campaign=mcp. 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

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, `empreinte_sha256` (full snapshots), `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).
`free_tier`	No	Free API key offer for this tool, present with a quote.
`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.

Changed1 schema field changedOct 30, 2026

changedOutput schema / properties / resultat / description

Previous value: -"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, `empreinte_sha256` (full snapshots), `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)."New value: +"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, `empreinte_sha256` (full snapshots), `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)."

Changed4 schema fields changedOct 28, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedOutput schema / properties / free_tier / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / quote / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / resultat / propertyNames
```
Added value: +{
+  "type": "string"
+}
```

Changed7 schema fields changedOct 13, 2026

addedInput schema / properties / api_key

Added value: +{
+  "description": "Optional Sirenic API key (srn_live_…) to pay with prepaid credits instead of x402, with no wallet needed. Get one at https://api.sirenic.eu/compte?utm_source=api&utm_campaign=mcp. Ignored when x_payment is provided (the signed payment wins). On insufficient balance the tool returns a credits error, not an x402 quote.",
+  "type": "string"
+}

addedInput schema / properties / x_payment

Added value: +{
+  "description": "Optional signed x402 PAYMENT-SIGNATURE header value. Omit to receive the payment quote.",
+  "type": "string"
+}

addedOutput schema / properties / free_tier

Added value: +{
+  "additionalProperties": {},
+  "description": "Free API key offer for this tool, present with a quote.",
+  "type": "object"
+}

addedOutput schema / properties / hint

Added value: +{
+  "description": "How to settle the quote, present when payment_required is true.",
+  "type": "string"
+}

changedOutput schema / properties / payment_required / description

Previous value: -"Always false on this connector: every call is billed to the connected Sirenic account, never paid by the client."New value: +"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`."

addedOutput schema / properties / quote

Added value: +{
+  "additionalProperties": {},
+  "description": "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`.",
+  "type": "object"
+}

changedOutput schema / properties / resultat / description

Previous value: -"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, `empreinte_sha256` (full snapshots), `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)."New value: +"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, `empreinte_sha256` (full snapshots), `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)."

AddedOct 13, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the payment model (x402, $0.05 USDC/EURC, or an API key), the three possible verdicts (nouveautes, rien_de_nouveau, lecture_incomplete) and their meaning, the monthly-snapshot caveat that recent dates can never yield rien_de_nouveau, and the 100-record cut with per-type totals. These are exactly the failure modes an agent needs to interpret a result correctly.

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 in the first clause, and every subsequent clause carries substantive information. The density is high — one packed paragraph covering coverage, dates, verdicts, truncation, payment and citation — which makes it harder to scan than a lightly structured version, but no sentence is filler.

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 multi-source aggregation tool this is complete: scope, exclusions, date semantics, completeness verdicts, result cap, cost, and the citation obligation are all covered, and an output schema exists so return shapes need no explanation.

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 both required parameters and the two payment parameters are already fully documented in the schema, including the ISO 8601 timestamp rules for `depuis`. The description reinforces the date semantics ('each change is dated at publication ... event date alongside') but adds no new syntax or constraint beyond what the schema states, so the baseline 3 applies.

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?

States a specific verb and resource — everything published/changed at a French company since a date — and enumerates the covered blocks (BODACC, court decisions, public contracts, establishments, IP, certifications, lobbying). It also explicitly scopes out adjacent data ('Hiring, officers and headcount band are outside the engine'), which differentiates it from the single-block siblings such as get_french_company_court_decisions or get_french_company_intellectual_property.

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 quoted example question ('what changed at this customer since June?') gives a clear usage context, and the exclusions tell the agent what not to expect from this call. It stops short of naming which sibling to use instead for hiring/officers or for a single block, so the routing guidance is implied rather than explicit.

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?