French companies: dated changes and insolvencies (BODACC), filed accounts by year (INPI). No key.
Scored across 6 tools
Most tools target distinct data surfaces, and the two overlapping pairs (ademe_grants vs state_aid, announcements vs timeline) are explicitly differentiated in the descriptions, including a warning not to sum the two aid sources. However, an agent could still hesitate between announcements and timeline for 'what happened to X', since both draw on gazette publications.
Every tool follows the same get_french_* pattern with a clear resource noun, and get_french_insolvency_barometer sensibly drops 'company' because it is a national aggregate. No mixing of conventions or verb styles.
Six tools is well-scoped for the domain, each covering a distinct data source (ADEME grants, EU state aid, financials, gazette timeline, announcements, insolvency barometer) with no filler. Nothing feels redundant or missing at the count level.
The surface covers the major data domains including both aid registers, financials, lifecycle events, and a market-wide barometer. The notable gap is that it only exposes what changed and offers no way to get a company's current state (officers, address, headcount) or to resolve a name to a SIRET/SIREN, which agents may need.
The grants the ADEME, the French ecological transition agency, awarded to one French company since 2021, from its open dataset of financial aid: date of the agreement, amount in euros, purpose, aid scheme and decision reference, most recent first, with the total count.
Use this to answer "did X receive public aid from the ADEME", "what subsidies did X get for its energy transition".
The dataset covers the ADEME alone: it is not all the public money a company received, and a company with no ADEME grant may have received aid from another body. Grants are matched on the SIRET, never on the name.
| Name | Required | Description | Default |
|---|---|---|---|
| siren | Yes | The nine-digit SIREN of a French legal entity. Spaces, dots and dashes are accepted. This is not a SIRET: drop the last five digits of a SIRET to get the SIREN. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| fait | Yes | |
| source | Yes | |
| empreinte | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, it discloses ordering ('most recent first'), that a total count is included, the 2021 coverage floor, and the matching rule (SIRET, never name). The dataset-boundary caveat is exactly the kind of interpretive context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what is returned and its ordering, then use cases, then the coverage caveat. Every sentence carries distinct information; nothing restates the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Single-parameter read tool with an output schema, so return-value detail is not needed. The description still covers scope, ordering, matching key, and the key caveat that absence of ADEME aid is not absence of aid — nothing an agent needs to interpret results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the siren parameter is already well documented (nine digits, separators accepted, SIRET minus five digits). The description adds meaning the schema lacks by stating that matching happens on SIRET and never on the company name, which explains why an exact identifier is required rather than a name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (grants awarded by ADEME to one French company since 2021) and enumerates the returned fields (agreement date, amount, purpose, aid scheme, decision reference). The scope note that the dataset covers ADEME alone implicitly separates it from the sibling get_french_company_state_aid, which covers wider public aid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger questions ('did X receive public aid from the ADEME', 'what subsidies did X get for its energy transition') plus an explicit exclusion: no ADEME grant does not mean no public aid at all, so the agent knows when this tool is insufficient. That is a clear use/exclusion pair rather than an implied one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the French official gazette printed about companies you already track, since a date. Answers "did anything happen to these companies", "any news on X since my last check".
Up to 20 companies per call. Each one spends one unit of the rate limit (30 per minute per address), so pass them in ONE call rather than one call each.
Entries are filtered on the PUBLICATION date, not the date of the act. The two differ by 16 days at the median, so a window filtered on the act would miss a judgment ruled before your last visit and printed after. An empty list means nothing was published, not that nothing happened.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Publication date to look back to, ISO 8601. Defaults to 30 days ago. | |
| siren | Yes | The companies to look at. One call for all of them, not one call each. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| fait | Yes | |
| source | Yes | |
| empreinte | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses a per-address rate limit (30/minute), that each company spends one unit, and that batching is required. It also explains a critical semantic detail: filtering is on publication date rather than act date, with a median 16-day gap, and that an empty result means nothing was published, not that nothing happened.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then batching, then the publication-date caveat. Every sentence carries useful information, including the empty-list interpretation, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return format need not be described. The description covers the remaining agent-critical context: what the tool queries, how to batch calls, rate-limit implications, date semantics, and how to interpret an empty result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents both parameters fully, including SIREN formatting, SIRET guidance, maxItems, and the 'since' default. The description reinforces the one-call batching constraint but adds little parameter-level meaning beyond what the structured fields already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (French official gazette publications about companies) and the exact question it answers ('did anything happen to these companies', 'any news on X since my last check'). This clearly separates it from sibling tools like financials, grants, state aid, timeline, and insolvency barometer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear triggering contexts ('since my last check', 'any news on X') and a strong batching instruction ('pass them in ONE call rather than one call each'). It does not explicitly name sibling alternatives or state when not to use this tool, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The annual accounts one French company filed with the business register, fiscal year by fiscal year: revenue, gross margin, EBITDA, EBIT, net income, and the thirteen ratios the INPI computes from them (margins, financial autonomy, debt, liquidity, working capital, customer and supplier payment delays).
Use this to answer "what is the revenue of X", "is X profitable", "how has the turnover of X evolved", "how indebted is X".
Accounts of the legal entity under this SIREN and consolidated accounts of its group are listed apart and NEVER add up: a holding files a revenue of zero beside a group revenue in the billions. Quote the perimeter with the figure. Filings kept confidential are not listed, and a missing fiscal year is not a fiscal year at zero. Amounts are in euros as filed.
| Name | Required | Description | Default |
|---|---|---|---|
| siren | Yes | The nine-digit SIREN of a French legal entity. Spaces, dots and dashes are accepted. This is not a SIRET: drop the last five digits of a SIRET to get the SIREN. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| fait | Yes | |
| source | Yes | |
| empreinte | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe, idempotent, read-only open-world call, and the description goes well beyond them: it warns that legal-entity and consolidated group accounts never add up and must be quoted with their perimeter, that confidential filings are absent, and that a missing fiscal year does not mean zero. These are real data-interpretation hazards an agent would otherwise get wrong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is longer than typical but front-loaded with what the tool returns, then usage, then caveats, and every clause carries substantive information. The line breaks are a bit unconventional and the ratio enumeration is dense, but there is no filler to cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description already covers scope, usage triggers, and the key pitfalls (perimeter mixing, confidentiality, missing years, euro denomination). Nothing an agent needs to call and interpret this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, and the schema already explains the nine-digit SIREN format, accepted separators, and the SIRET-to-SIREN conversion. The description adds nothing about the parameter, so the baseline 3 applies when the schema carries the full load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (annual accounts filed with the French business register, fiscal year by fiscal year) and enumerates the exact metrics returned (revenue, gross margin, EBITDA, EBIT, net income, thirteen INPI ratios). It is clearly distinguishable from siblings like get_french_company_announcements or get_french_company_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit trigger questions ('what is the revenue of X', 'is X profitable', 'how has the turnover of X evolved', 'how indebted is X'), which is exactly the when-to-use guidance an agent needs. It also states exclusions: confidential filings are not listed, and consolidated group accounts are separate from legal-entity accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The state aid published for one French company in the European Commission transparency register: grant date, amount or tax-aid bracket, objective, instrument, granting authority (Bpifrance, regions, ministries) and aid scheme, most recent first, with the total count.
Use this to answer "what public aid did X receive", "did the State fund X".
The register lists aid above a publication threshold only. Some ADEME grants are in both this tool and the ADEME one: never add the two. Matched on the SIREN, never on the name.
| Name | Required | Description | Default |
|---|---|---|---|
| siren | Yes | The nine-digit SIREN of a French legal entity. Spaces, dots and dashes are accepted. This is not a SIRET: drop the last five digits of a SIRET to get the SIREN. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| fait | Yes | |
| source | Yes | |
| empreinte | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/open-world safety, and the description goes well beyond them: it discloses the publication threshold that makes the list non-exhaustive, the overlap with the ADEME tool that would cause double counting, and the fact that matching is done on SIREN rather than company name. These are real behavioral constraints not derivable from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what is returned, then usage, then the two critical caveats (threshold, ADEME overlap, SIREN matching). The field enumeration is dense but functional, and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is unnecessary; the description still summarizes the payload and notes the total count. For a single-parameter, read-only lookup, all the caveats an agent needs to call and interpret it are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the siren field already documents the nine-digit format, acceptable separators, and the SIREN-vs-SIRET distinction. The description's "matched on the SIREN, never on the name" adds matching semantics but no format or syntax detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb-and-resource pair (state aid published for one French company in the EU transparency register) and enumerates the returned fields (grant date, amount/bracket, objective, instrument, granting authority, aid scheme). It is immediately distinguishable from the ADEME sibling, which it names explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete question shapes this answers ("what public aid did X receive", "did the State fund X"), states the scope limitation (only aid above the publication threshold), and issues an explicit when-not/alternative rule: ADEME grants appear in both tools, so never add the two. This is exactly the routing guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every dated change the French official gazette recorded for one company: share capital, legal name, legal form, registered office, stated activity, plus insolvency judgments and the current insolvency status.
Use this to answer "when did X change", "how has X evolved", "has X ever been in receivership".
Do NOT use it to get the current state of a company (today's officers, today's address, today's headcount): this server only publishes what CHANGED. A field that never moved is not in the answer. Coverage starts at 2008; a company may exist and have published nothing.
Announcements that merely cite the SIREN without describing the company are excluded; on large franchised networks that is around 40% of what a naive search returns.
| Name | Required | Description | Default |
|---|---|---|---|
| siren | Yes | The nine-digit SIREN of a French legal entity. Spaces, dots and dashes are accepted. This is not a SIRET: drop the last five digits of a SIRET to get the SIREN. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| fait | Yes | |
| source | Yes | |
| empreinte | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/open-world safety, and the description adds substantial context beyond them: coverage begins in 2008, a company may exist with zero published events, unchanged fields are absent from the answer, and announcements that merely cite the SIREN are excluded (~40% of naive search results on franchise networks). That is exactly the kind of behavioral caveat an agent cannot infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource definition, then usage, then exclusions, then coverage caveats. Every sentence carries non-redundant information (what it returns, when to call it, what it never returns, and the data-quality caveat), with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not required, and the description instead covers the things the schema cannot: temporal coverage, absence of unchanged fields, and filtering of SIREN-citing-only announcements. Nothing needed to invoke or interpret the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single siren parameter is fully documented there (nine digits, SIREN vs SIRET, accepted separators). The description adds no format or syntax detail beyond that, so the baseline 3 applies; its only marginal contribution is restating that the unit is the SIREN/company.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a precise resource (dated changes recorded by the French official gazette for one company) and enumerates exactly which fields are covered: share capital, legal name, legal form, registered office, stated activity, insolvency judgments and status. It is immediately distinguishable from siblings like get_french_company_announcements or get_french_company_financials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives literal question patterns the tool answers ("when did X change", "how has X evolved", "has X ever been in receivership") and an explicit when-NOT-to-use case: current state (today's officers, address, headcount), with the reason why (the server only publishes what changed). No named sibling alternative, but the routing condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insolvency openings in France over the last twelve complete months, against the twelve before, with the monthly series and a split by nature (liquidation, receivership, safeguard).
Scope: the whole country by default, or one department, or one trade. Pass at most one of them.
This counts OPENING judgments only, and it counts judgments, not companies. The current month is never included: still running, it would read as a collapse.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | No | Trade, read from the words of the activity declared in the gazette. Omit for all trades. | |
| department | No | French department code. Two digits, 2A and 2B for Corsica, three digits overseas. Omit for the whole country. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| fait | Yes | |
| source | Yes | |
| empreinte | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description earns credit for disclosing non-obvious semantics instead: it counts opening judgments only, counts judgments rather than companies, and deliberately excludes the current month with the reason (an incomplete month would read as a collapse). Those are behavioral facts an agent could not infer from the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the metric and window, then scope, then counting caveats; every sentence carries operational meaning. The closing clause ('would read as a collapse') is stylized but does justify the recency exclusion, so the cost is minor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-shape detail is unnecessary. For a two-optional-parameter, fully-enumerated aggregate query, the description supplies scope, defaults, the mutual-exclusion rule, and the counting methodology — nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully documented in the schema with enums and per-field descriptions, so the baseline is 3. The description adds a constraint absent from the schema itself: at most one of department/trade may be passed, plus the default of whole-country when neither is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (insolvency openings in France) with explicit scope (last twelve complete months vs. the prior twelve), plus the breakdown dimensions (monthly series, nature split). It is clearly an aggregate barometer, distinct from the sibling company-level tools (financials, announcements, timeline) that operate on a single company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: defaults to the whole country, and the caller may narrow to one department or one trade with an explicit 'at most one of them' constraint. It does not name an alternative tool or state when a sibling should be preferred, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_french_company_ademe_grants1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "empreinte": {
+ "type": "string"
+ },
+ "fait": {
+ "type": "object"
+ },
+ "source": {
+ "properties": {
+ "nom": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "nom",
+ "url"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "fait",
+ "source",
+ "date",
+ "empreinte"
+ ],
+ "type": "object"
+}get_french_company_announcements1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "empreinte": {
+ "type": "string"
+ },
+ "fait": {
+ "type": "object"
+ },
+ "source": {
+ "properties": {
+ "nom": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "nom",
+ "url"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "fait",
+ "source",
+ "date",
+ "empreinte"
+ ],
+ "type": "object"
+}get_french_company_financials1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "empreinte": {
+ "type": "string"
+ },
+ "fait": {
+ "type": "object"
+ },
+ "source": {
+ "properties": {
+ "nom": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "nom",
+ "url"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "fait",
+ "source",
+ "date",
+ "empreinte"
+ ],
+ "type": "object"
+}get_french_company_state_aid1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "empreinte": {
+ "type": "string"
+ },
+ "fait": {
+ "type": "object"
+ },
+ "source": {
+ "properties": {
+ "nom": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "nom",
+ "url"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "fait",
+ "source",
+ "date",
+ "empreinte"
+ ],
+ "type": "object"
+}get_french_company_timeline1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "empreinte": {
+ "type": "string"
+ },
+ "fait": {
+ "type": "object"
+ },
+ "source": {
+ "properties": {
+ "nom": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "nom",
+ "url"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "fait",
+ "source",
+ "date",
+ "empreinte"
+ ],
+ "type": "object"
+}get_french_insolvency_barometer13 fields changedOutput schema / properties / by_departmentRemoved value: -{
- "description": "Ranking over the window, largest first. Country scope only.",
- "items": {
- "properties": {
- "code": {
- "type": "string"
- },
- "name": {
- "type": "string"
- },
- "openings": {
- "type": "integer"
- }
- },
- "required": [
- "code",
- "name",
- "openings"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / by_natureRemoved value: -{
- "items": {
- "properties": {
- "nature": {
- "enum": [
- "liquidation",
- "receivership",
- "safeguard"
- ],
- "type": "string"
- },
- "openings": {
- "type": [
- "integer",
- "null"
- ]
- }
- },
- "required": [
- "nature",
- "openings"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / change_percentRemoved value: -{
- "description": "Null when the reference is zero: a place with no failure last year did not explode.",
- "type": [
- "number",
- "null"
- ]
-}Output schema / properties / dateAdded value: +{
+ "format": "date",
+ "type": "string"
+}Output schema / properties / empreinteAdded value: +{
+ "type": "string"
+}Output schema / properties / faitAdded value: +{
+ "properties": {
+ "by_department": {
+ "description": "Ranking over the window, largest first. Country scope only.",
+ "items": {
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "openings": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "code",
+ "name",
+ "openings"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "by_nature": {
+ "items": {
+ "properties": {
+ "nature": {
+ "enum": [
+ "liquidation",
+ "receivership",
+ "safeguard"
+ ],
+ "type": "string"
+ },
+ "openings": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "nature",
+ "openings"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "change_percent": {
+ "description": "Null when the reference is zero: a place with no failure last year did not explode.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "monthly": {
+ "items": {
+ "properties": {
+ "month": {
+ "examples": [
+ "2026-07"
+ ],
+ "type": "string"
+ },
+ "openings": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "month",
+ "openings"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "page_url": {
+ "description": "The page that shows the same thing to a human.",
+ "type": "string"
+ },
+ "reference": {
+ "$ref": "#/$defs/window"
+ },
+ "scope": {
+ "properties": {
+ "code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "kind": {
+ "enum": [
+ "country",
+ "department",
+ "trade"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "description": "In French: a published value, not a label.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "code",
+ "name"
+ ],
+ "type": "object"
+ },
+ "window": {
+ "$ref": "#/$defs/window"
+ }
+ },
+ "required": [
+ "scope",
+ "window",
+ "reference",
+ "monthly",
+ "by_nature",
+ "page_url"
+ ],
+ "type": "object"
+}Output schema / properties / monthlyRemoved value: -{
- "items": {
- "properties": {
- "month": {
- "examples": [
- "2026-07"
- ],
- "type": "string"
- },
- "openings": {
- "type": "integer"
- }
- },
- "required": [
- "month",
- "openings"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / page_urlRemoved value: -{
- "description": "The page that shows the same thing to a human.",
- "type": "string"
-}Output schema / properties / referenceRemoved value: -{
- "$ref": "#/$defs/window"
-}Output schema / properties / scopeRemoved value: -{
- "properties": {
- "code": {
- "type": [
- "string",
- "null"
- ]
- },
- "kind": {
- "enum": [
- "country",
- "department",
- "trade"
- ],
- "type": "string"
- },
- "name": {
- "description": "In French: a published value, not a label.",
- "type": "string"
- }
- },
- "required": [
- "kind",
- "code",
- "name"
- ],
- "type": "object"
-}Output schema / properties / sourceAdded value: +{
+ "properties": {
+ "nom": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "nom",
+ "url"
+ ],
+ "type": "object"
+}Output schema / properties / windowRemoved value: -{
- "$ref": "#/$defs/window"
-}Output schema / requiredPrevious value: -[
- "scope",
- "window",
- "reference",
- "monthly",
- "by_nature",
- "page_url"
-]New value: +[
+ "fait",
+ "source",
+ "date",
+ "empreinte"
+]get_french_company_state_aidget_french_company_ademe_grantsget_french_company_announcementsget_french_company_financialsget_french_company_timelineget_french_insolvency_barometerBODACC MCP — French official business-events bulletin (keyless).
French company data from public registers (Sirene, RNE, BODACC) and French legal notices.
INSEE MCP — France's SIRENE business registry (INSEE).
French Companies MCP — recherche-entreprises.api.gouv.fr
Add one secure layer between your agents and this server.