Sirenic

French company collective agreements

get_french_company_collective_agreements

Read-only

Company-level collective agreements of a French company (SIREN) published on Légifrance (ACCO fund, mandatory publication since 2017-09-01): title, nature (accord / avenant), DILA themes (pay, working time, telework, gender equality, profit-sharing…), signature, effect and end dates, collective-agreement code (IDCC) checked against Sirene, signatory unions and the official Légifrance link — metadata only, never the text nor a person's name. Searched by filing SIRET over the establishments known to Sirene (25 at most, the rest counted): an empty list never means « no social dialogue » (headcount threshold, unpublished decisions). A sole proprietorship or restricted-diffusion entity answers 400 and is never charged. Paid via x402 ($0.02 in USDC or EURC).

Input Schema

TableJSON Schema

Name	Required	Description
`siren`	Yes	9-digit SIREN of a legal entity
`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 13, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, but the description goes far further: metadata-only scope (never text nor a person's name), a 400 response for sole proprietorships / restricted-diffusion entities that is never charged, and the paid x402 pricing ($0.02 in USDC/EURC). It also discloses the empty-result semantic and the establishment-cap behavior, all of which an agent needs.

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 clause (source, scope, payment, error behavior) carries real information. It is a single heavily-parenthesized run-on sentence, which is dense but not padded.

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 an output schema exists, the description need not explain return fields, yet it covers scope limits, error/payment behavior, and empty-result interpretation. Nothing material for a correct call is missing.

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 both siren and the two payment parameters are already fully documented in the schema, establishing the baseline of 3. The description adds only the pricing model and confirmation that lookups key on SIREN, not new syntax or per-parameter meaning.

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 (company-level collective agreements of a French SIREN) and pins the data source (Légifrance ACCO fund, mandatory since 2017-09-01). It enumerates the returned fields (title, nature, DILA themes, IDCC, signatories, link), which makes it unmistakably distinct from sibling tools like get_french_company_file or get_french_company_legal_alerts.

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

Usage Guidelines3/5

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

It explains the search mechanics (queried via filing SIRET over establishments known to Sirene, capped at 25) and the crucial interpretation caveat that an empty list never means 'no social dialogue'. However, it never states when to prefer this tool over the many adjacent French-company siblings, so 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?