French company KYB (SIREN): status, insolvency, VAT, BODACC monitoring alerts. Free preview; x402.
Scored across 9 tools
Each tool targets a distinct check (free preview, full KYB, insolvency, RGE, public contracts, monitoring, name→SIREN, LEI, asset freeze), and every description includes an explicit 'When to use another tool' section that resolves the deliberate overlaps. The tiering of apercu_entreprise vs verifier_entreprise and procedures_collectives vs verifier_entreprise is genuine functional overlap, but the boundary and price difference are spelled out clearly enough that an agent should select correctly.
All names are lowercase snake_case in French, which is readable and consistent in style. However the convention is mixed: some are verb_noun actions (rechercher_entreprise, verifier_entreprise, surveiller_entreprise) while others are bare noun phrases (apercu_entreprise, gel_avoirs, marches_publics, procedures_collectives, qualifications_rge, entite_lei), so the pattern does not predict what a tool does.
Nine tools is well within the sweet spot and each one earns its place: search, triage, full verification, insolvency, RGE, public contracts, monitoring, LEI, and sanctions screening. No redundant or filler tools are present, and the free/cheap/paid tiers are split sensibly rather than duplicated.
The surface covers the full French KYB lifecycle: name→SIREN resolution, free triage, full verification with verdict and attestation, focused insolvency, RGE certification detail, public contracts, ongoing monitoring, plus international LEI and asset-freeze screening. Minor gaps remain (no standalone VAT/VIES-only check, no directors/officers or beneficial-ownership lookup, no historical financial statements), but agents can work around them via verifier_entreprise.
FREE quick check of a French company by SIREN (10 calls per day): official name, active/closed status, head-office city, and the NUMBER of alerts found (insolvency proceedings, closure, closed head office…), without their detail.
Use it first to triage. If alertes > 0, or before paying or onboarding a supplier, call verifier_entreprise ($0.01 via x402) for the verdict, the sourced signals with links to the official notices, the insolvency history (BODACC) and the VAT number checked in VIES.
Optional verdict: true adds the verdict, its summary and the signal list (same computation as verifier_entreprise, without the signed attestation and without links to the official notices), up to 3 per day, with its own quota: the simple preview stays available when it is used up.
For sole traders, only the trade name is returned, never the person's name.
| Name | Required | Description | Default |
|---|---|---|---|
| siren | Yes | SIREN (9 digits, Luhn-valid) or 14-digit SIRET. Spaces, dots and dashes are accepted. | |
| verdict | No | Free trial with verdict (up to 3 per day): adds verdict, resume and signaux to the preview. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent hints: it discloses two distinct quotas (10 simple previews/day, 3 verdict calls/day), that the verdict quota is separate and that the simple preview survives quota exhaustion. It also discloses a non-obvious privacy behavior — sole traders return the trade name, never the person's name — and what the verdict variant deliberately omits (signed attestation, official-notice links).
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 tool's identity and scope, then the triage guidance, then the edge cases — a sensible order. Slightly heavy in the third paragraph, where the verdict variant is explained at length, but every clause carries information an agent would otherwise have to guess.
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?
No output schema exists, so the description carries the return-value burden itself and does so field by field, including what is intentionally withheld. Given a two-parameter read-only tool with quotas and a privacy exception, nothing material 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%, so both parameters are already documented; baseline would be 3. The description adds real meaning on top: the `verdict` flag's own quota, the fact that it reuses the same computation as verifier_entreprise, and its fallback behavior. The `siren` parameter itself gets no extra treatment beyond the schema.
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 and resource ("FREE quick check of a French company by SIREN") and enumerates exactly what comes back: official name, active/closed status, head-office city, and the number of alerts without detail. It distinguishes itself from the paid sibling by contrast (no verdict detail, no sourced links), so an agent can tell the two apart without opening a schema.
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?
Explicit routing instruction: "Use it first to triage" and "If alertes > 0, or before paying or onboarding a supplier, call verifier_entreprise" — with the sibling's price and the extra fields it returns. This is a when-to-use plus a named alternative plus the trigger condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify a legal entity anywhere in the world in the official GLEIF registry of Legal Entity Identifiers (open data, CC0), either by its 20-character LEI, or by country (ISO alpha-2) plus national registration number (for France, a SIREN). Returns the legal name, entity status (ACTIVE or INACTIVE), legal form code, registered address, business register and number, creation date, the LEI registration record (status, issue, update and renewal dates, corroboration level), the declared direct and ultimate parent (LEI, name, country) and stable signal codes with a link to the official record (LEI_ACTIF, LEI_NON_RENOUVELE, ENTITE_INACTIVE, ENTITE_REMPLACEE, DONNEES_PEU_CORROBOREES, GROUPE_PARENT_ULTIME_IDENTIFIE), signed with an Ed25519 attestation. For a French entity with a SIREN it also gives the paid routes to check it. No global verdict: most companies have no LEI, so a missing LEI is not a negative signal. Use exactly one mode: lei, or pays + immatriculation. parents: "non" skips the two parent lookups (default "oui"). If several LEI share a registration number, the most relevant one is returned and correspondances tells how many exist (then pass lei to be exact). No personal data: sole proprietors (natural persons) are excluded, as an entity and as a parent; their LEI answers as not found. When to use another tool: for a French company, verifier_entreprise (full KYB) and procedures_collectives (insolvency) are the reference checks; use this one for foreign counterparties or to map a corporate group. Errors (never charged): invalid input (bad LEI check digits, both modes at once, bad country) is rejected before any payment request; an entity absent from the registry (or excluded) or GLEIF being unreachable returns an error and is not settled. Payment: $0.01 per call via x402 (USDC on Base). No account or API key.
| Name | Required | Description | Default |
|---|---|---|---|
| lei | No | 20-character LEI (ISO 17442). Exclusive with pays + immatriculation. | |
| pays | No | ISO 3166-1 alpha-2 country of the registered office (FR, DE, GB…), used with immatriculation. | |
| parents | No | "non" skips the direct and ultimate parent lookups (default "oui"). | |
| immatriculation | No | National registration number (3 to 40 characters; a SIREN for FR), used with pays. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnly/idempotent/openWorld, but the description adds substantial behavior: $0.01 x402 payment, errors never charged, invalid input rejected before payment, absence is not a negative signal, sole proprietors excluded, Ed25519 attestation, and the stable signal codes returned.
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 purpose and mode selection, then behaviors and alternatives. Dense and long, but nearly every sentence adds operational value; a couple of clauses about return fields could be compressed.
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?
No output schema exists, and the description enumerates returned fields, error/charging semantics, payment mechanics, and data exclusions. An agent has everything needed to call it correctly and interpret the response.
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% so the schema does the heavy lifting, but the description adds real meaning: mutual exclusivity of modes, SIREN-for-FR semantics, the parents="non" effect, and guidance that `correspondances` + a follow-up `lei` resolves multiple matches.
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 and resource (identify a legal entity in the GLEIF LEI registry) plus the two mutually exclusive lookup modes. Clearly separable from siblings like verifier_entreprise and procedures_collectives, 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?
Explicit when-to-use alternatives: French company → verifier_entreprise (KYB) and procedures_collectives (insolvency); use this for foreign counterparties or group mapping. Also states the 'exactly one mode' rule and the parents="non" skip option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a legal entity (company, association, public body) against the official French national asset-freeze register published by the Direction generale du Tresor (open data, Licence Ouverte 2.0), which lists the EU, UN and French national freezes. It does not cover US OFAC or UK lists. Give nom (2 to 200 characters), and/or immatriculation (3 to 40 characters: a SIREN with pays=FR, or any national registration number); pays (ISO alpha-2) is optional and filters and ranks the matches. Legal forms (SA, LLC, OOO, JSC, GmbH...) and word order are ignored. Returns resultat = correspondance_forte (same registration number, or exactly the same words as a name or alias), a_verifier (all the requested words, two at least, are contained in a longer name or alias) or aucune_correspondance, up to 10 matches (name, aliases, registration numbers, countries, sanctions regime and legal acts, EU and UN references, date of the oldest act), the register publication date, source and licence, the limits of the check and a signed Ed25519 attestation. Never a 'not sanctioned' statement: no match means no match among the legal entities of the register published at that date. Limits: natural persons are excluded by design, so a sole trader is not screened; only the Official Journal of the EU and published orders are authoritative; a match by name alone may be a homonym and must be verified. When to use another tool: for the identity, status and insolvency of a French company use verifier_entreprise, which also raises the GEL_AVOIRS_CORRESPONDANCE signal; for a foreign entity and its group use entite_lei. Errors (never charged): missing or invalid input is rejected before any payment request; the register not being loaded yet returns an error and is not settled. The register copy is local and refreshed every hour when DG Tresor publishes a new version; if it could not be confirmed for 7 days, fraicheur is degradee and registre.publieLe gives the real date. Payment: $0.02 per call via x402 (USDC on Base). No account or API key.
| Name | Required | Description | Default |
|---|---|---|---|
| nom | No | Company name (2 to 200 characters; legal forms such as SA, LLC or OOO are ignored). Give nom and/or immatriculation. | |
| pays | No | Optional ISO 3166-1 alpha-2 country (FR, RU, IR...): filters and ranks. | |
| immatriculation | No | National registration number (3 to 40 characters; a valid SIREN when pays is FR). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, but the description goes far beyond them: pricing model ($0.02 via x402, no account), the 'errors never charged' policy, the hourly local register refresh, the 7-day staleness degradation with fraicheur/registre.publieLe, and a signed Ed25519 attestation. It also discloses the interpretive limits of a match (homonym caveat, no authoritative 'not sanctioned' claim).
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 purpose and screening scope, then input rules, then result semantics, then alternatives, then payment — a sensible ordering. It is long and delivered as a single dense block, but nearly every clause carries operational information (result categories, limits, error/payment behavior), so little is genuinely expendable.
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?
With no output schema, the description carries the return-value burden itself and does so fully: it enumerates the three resultat values with their matching logic, the match fields, the 10-match cap, and the publication/source/licence metadata. An agent has everything needed to call and interpret this tool correctly.
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%, so the baseline is 3, and the description largely restates the schema's own constraints (2–200 chars for nom, 3–40 for immatriculation, ISO alpha-2 pays that 'filters and ranks'). It does add the useful rule that legal forms and word order are ignored and that immatriculation pairs with pays=FR as a SIREN, but that is incremental rather than new semantic depth.
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 and resource ('Screen a legal entity ... against the official French national asset-freeze register') and immediately bounds the covered lists (EU, UN, French national) versus excluded ones (US OFAC, UK). The scope is precise enough that an agent can distinguish it from any sibling without opening a schema.
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?
Explicitly routes the agent elsewhere: 'for the identity, status and insolvency of a French company use verifier_entreprise' and 'for a foreign entity and its group use entite_lei', naming the alternative and the condition that selects it. It also spells out input requirements ('Give nom and/or immatriculation') and exclusions ('natural persons are excluded by design, so a sole trader is not screened').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the public contracts awarded to ONE French company, from its 9-digit SIREN (or 14-digit SIRET), in the official DECP open data (Données essentielles de la commande publique, consolidated files on data.gouv.fr, Licence Ouverte 2.0) over the last 24 monthly files. Returns synthese (number of distinct contracts, total notified amount in euros, first and last notification date, number of distinct public buyers), parAnnee (contracts and amount per notification year), parSecteurCpv (top 5 CPV divisions with their French label), marchesRecents (up to 10 latest awards: id, buyer SIRET, subject, CPV code, procedure, amount, date, department), source (name, licence, last update date to cite when reusing the data) and avertissements (reading limits), signed with an Ed25519 attestation. Amounts: negative amounts or amounts above 10 billion euros are excluded from the sums (and counted in avertissements). A contract awarded to a group is counted in full for each member identified by SIRET. Only contractors identified by SIRET are covered; foreign contractors are not. A company with no published public contract returns a valid answer with zeros (nombreMarches: 0): it is charged, because 'no public contract published in the last 24 months' is itself the information. The data is self-reported by buyers and incomplete: no contract does not prove no public business. No personal data: for a sole trader (entrepreneur individuel) the subject of the contracts (objet) is never returned. When to use another tool: for the identity, status, insolvency and verdict of the company use verifier_entreprise; if you only know the name, call rechercher_entreprise first. Errors (never charged): an invalid SIREN is rejected before any payment request; if the DECP copy is not loaded yet (first start of the service) the call returns an error and is not settled, retry a few minutes later. Payment: $0.02 per call via x402 (USDC on Base). No account or API key.
| Name | Required | Description | Default |
|---|---|---|---|
| siren | Yes | 9-digit SIREN of the company (Luhn-valid); a 14-digit SIRET is also accepted. Spaces, dots and dashes are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, and the description goes well beyond them: $0.02 x402 payment per call, no account or key, negative or over-10-billion amounts excluded from sums, group awards counted in full per SIRET member, foreign contractors uncovered, no personal data for sole traders, and an Ed25519 attestation. The self-reported/incomplete nature of DECP data and the error/retry behavior are also disclosed, which is unusually complete for a paid read tool.
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 front-loaded with purpose, then the return shape, then counting rules, then alternatives, errors and price, so a reader can stop early once oriented. It is long and a few clauses (licence restatement, repeat of the zero-contract case) could be trimmed, but nearly every sentence carries decision-relevant information for a paid call.
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?
There is no output schema, so the description must explain the return payload and it does: synthese, parAnnee, parSecteurCpv, marchesRecents, source and avertissements are each enumerated with their fields. Combined with the billing, error and data-quality caveats, an agent has everything needed to call it and interpret the response.
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% for the single SIREN parameter, so the schema already carries the format contract including Luhn validity. The description adds meaning beyond it by stating that a 14-digit SIRET is also accepted and by framing the identifier as company-identifying rather than free text, though it does not restate the space/dot/dash tolerance the schema documents.
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 opens with a specific verb and resource ('List the public contracts awarded to ONE French company') plus the exact data source (DECP) and the scope of the last 24 monthly files. The capitalized 'ONE' plus the SIREN/SIRET input makes it unmistakable which entity is queried, so an agent can separate it from the other company-level siblings without opening any schema.
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 routing rules: use verifier_entreprise for identity, status, insolvency and verdict, and rechercher_entreprise first if only the name is known. It also states the notable edge case that a zero-contract company is still charged and that invalid SIRENs and unloaded DECP copies are never settled, which tells the agent exactly when the call is appropriate and when to retry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a French company is in, or has been through, a collective insolvency proceeding, from its 9-digit SIREN (or 14-digit SIRET), using the official BODACC notices. Returns the company status (active/closed) and its trade name (never a sole trader's personal name), the current proceeding state (none, safeguard, receivership, liquidation, safeguard or receivership plan, closures), the dated court events with the court and a link to each official notice, the deregistration notice when there is one, and the matching stable signal codes (e.g. LIQUIDATION_JUDICIAIRE_EN_COURS, RADIATION_RCS). Same reading of BODACC as verifier_entreprise. When to use another tool: this is the cheap, focused check (before granting credit, paying an invoice in advance or onboarding a supplier). For the full KYB (identity, revenue, EU VAT, overall verdict, signed attestation), call verifier_entreprise. If you only know the name, call rechercher_entreprise first. Errors (never charged): an invalid SIREN is rejected before any payment request; an unknown or non-public company, or BODACC being unreachable (no partial answer is sold), returns an error and is not settled. Payment: $0.005 per call via x402 (USDC on Base). No account or API key.
| Name | Required | Description | Default |
|---|---|---|---|
| siren | Yes | 9-digit SIREN of the company (Luhn-valid); a 14-digit SIRET is also accepted. Spaces, dots and dashes are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this read-only, idempotent and open-world, and the description layers on non-obvious behavior beyond them: cost per call via x402 in USDC on Base, no account/API key needed, and a clear billing policy that errors (invalid SIREN, unknown company, BODACC unreachable) are never charged or partially settled.
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 core purpose and return contents are front-loaded, then usage routing, then errors and pricing, in a logical order. It is dense and long for a one-parameter tool, with a slightly redundant aside ('Same reading of BODACC as verifier_entreprise'), but nearly every sentence carries operationally useful information.
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?
No output schema exists, and the description compensates by enumerating the returned fields (status, trade name, proceeding state, dated court events with notice links, deregistration notice, stable signal codes). Combined with the error and payment behavior, an agent has everything needed to call it and interpret the 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 one parameter at 100% schema coverage, the schema already explains the 9-digit SIREN, Luhn validation, SIRET acceptance and separator tolerance. The description restates SIREN-or-SIRET but adds no new syntax or format meaning, so it lands at the baseline.
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 and resource ('check whether a French company is in, or has been through, a collective insolvency proceeding') keyed to an official source (BODACC) and an identifier (SIREN/SIRET). It also enumerates the payload, so an agent can tell it apart from the broader siblings without opening the schema.
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?
Explicitly names the decision context (before granting credit, paying an invoice in advance, onboarding a supplier) and routes to alternatives by condition: verifier_entreprise for full KYB, rechercher_entreprise if only the name is known. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the RGE (Reconnu Garant de l'Environnement) energy-renovation certifications of ONE French establishment, identified by its 14-digit SIRET, from the official ADEME list. Use it to check a contractor before work eligible for French renovation subsidies (MaPrimeRénov', CEE): each qualification comes with its domains, certifying body, start and end dates, and whether it is valid today; rge.qualifie is true when at least one is currently valid. When to use another tool: verifier_entreprise works on the whole company (SIREN) and only says whether an RGE label exists. Get the SIRET from rechercher_entreprise (siret) or verifier_entreprise (entreprise.siege.siret). Errors (never charged): an invalid SIRET is rejected before any payment request; an unknown or non-public establishment returns an error and is not settled. An establishment without any RGE certification returns qualifie: false and an empty list (this is a valid, charged answer). Payment: $0.01 per call via x402 (USDC on Base). No account or API key.
| Name | Required | Description | Default |
|---|---|---|---|
| siret | Yes | 14-digit SIRET of the establishment. Spaces, dots and dashes are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already mark it read-only, idempotent, open-world, and non-destructive, the description adds substantial behavioral context: valid empty results are charged, invalid SIRETs are rejected before payment, unknown establishments error and are not settled, and payment is $0.01 via x402. It also explains return semantics such as `rge.qualifie` and the fields included.
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 purpose, scope, and sibling differentiation, then covers errors and payment. It is fairly long, but nearly every sentence provides actionable invocation or interpretation guidance, so the length is mostly justified.
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?
For a one-parameter read-only lookup without an output schema, the description supplies what an agent needs: SIRET source, result interpretation, empty-result behavior, error/payment semantics, and sibling alternatives. No material gaps remain.
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 schema already documents the `siret` parameter in detail. The description still adds useful context by emphasizing the 14-digit SIRET and by naming upstream tools that provide it, but it does not add much beyond the schema for the parameter itself.
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 verb and resource: list RGE energy-renovation certifications for ONE French establishment identified by SIRET, sourced from the official ADEME list. It clearly distinguishes the unit of analysis (establishment/SIRET) from sibling tools that operate at company/SIREN level.
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 use cases (checking a contractor before subsidy-eligible work), names the alternative verifier_entreprise and explains its limitation, and tells the agent where to obtain the SIRET via rechercher_entreprise or verifier_entreprise. The when-to-use and when-to-use-another-tool guidance is unusually complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a French company's SIREN when you only know its name (3 to 100 characters). Narrow the results with code_postal (5-digit postcode, e.g. 69003) or commune (5-character INSEE commune code, e.g. 69383 — not a city name); both can be combined. Returns at most 10 matches with siren, siret of the establishment matching the location filter (otherwise the head office), name, status, NAF code, city, postcode and creation date. plusDeResultats: true means more companies match: refine the query. No personal data: sole traders appear under their trade name only. Next step: call verifier_entreprise with the SIREN for a full check, or qualifications_rge with the SIRET for RGE certifications. Errors (never charged): a query shorter than 3 characters or a malformed filter is rejected before any payment request. Payment: $0.002 per call via x402 (USDC on Base). No account or API key.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Company name or part of it (3 to 100 characters). | |
| commune | No | Optional INSEE commune code (5 characters, e.g. 69383 or 2A004), not a city name. | |
| code_postal | No | Optional 5-digit French postcode, e.g. 69003. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only/idempotent, but the description adds substantial context beyond them: a hard 10-result cap, the meaning of `plusDeResultats: true`, which SIRET is returned when a location filter is applied, exclusion of personal data for sole traders, error behavior (validation failures never charged), and the $0.002 x402 payment requirement with no account or API key needed. This is exactly the kind of information an agent needs before invoking a paid tool.
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 core purpose and the filter mechanics are front-loaded, and the operational facts (result cap, next steps, pricing) are ordered sensibly. It is a dense single block, however, and the payment/error sentences could be trimmed without losing anything essential.
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?
There is no output schema, yet the description enumerates the returned fields (siren, siret, name, status, NAF, city, postcode, creation date) and the truncation signal, plus error and payment behavior. Nothing needed to invoke or interpret the result 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%, so the baseline is 3, but the description adds semantic consequences not present in the schema — the location filter changes which establishment's SIRET is returned (otherwise head office), and the filters can be combined — plus a reminder that `commune` is an INSEE code, not a city 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?
The description states a specific verb and resource — find a French company's SIREN by name — and immediately clarifies the precondition ('when you only know its name'), which distinguishes it from siblings that operate on an already-known SIREN or SIRET.
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 conditions for the optional filters ('Narrow the results with code_postal or commune... both can be combined') and explicitly routes follow-up work to verifier_entreprise (SIREN) and qualifications_rge (SIRET), so the agent knows what this tool does and does not cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start monitoring ONE French company for 90 days. BODACC is checked every 3 hours; each NEW notice (safeguard, receivership, liquidation, plan, closure, deregistration) published after the start creates an alert. Notices already published are not alerted: use verifier_entreprise for the current state. Same price: a second alert type, "marche_public", fires when a NEW public contract is awarded to the company (DECP open data, updated nightly; contracts already published at the start are not alerted, at most 20 contract alerts per check, the rest summarized; contract subject withheld for sole traders). Delivery: if webhook (public HTTPS URL) is given, each alert is POSTed as JSON with the header X-Verif-Signature = sha256=HMAC-SHA256(body, jeton). In every case, alerts can be polled at the returned suivi URL (free). Keep the returned jeton: it signs webhooks and gives access to the alerts. Errors (never charged): an invalid SIREN, a non-public webhook or an unknown company returns an error and is not settled. Payment: $0.10 per company via x402 (USDC on Base). No account or API key.
| Name | Required | Description | Default |
|---|---|---|---|
| siren | Yes | SIREN (9 digits) or SIRET (14 digits) of the company to monitor. | |
| webhook | No | Optional public HTTPS URL that receives each alert (signed POST JSON). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: polling cadence (every 3 hours), subscription lifetime (90 days), a throttle ('at most 20 contract alerts per check, the rest summarized'), a data-suppression rule ('contract subject withheld for sole traders'), delivery mechanics (signed POST with X-Verif-Signature = sha256=HMAC-SHA256(body, jeton)), a free polling fallback, debt/payment behavior ($0.10 via x402, USDC on Base), and charged-vs-unsettled error cases. Only mild tension is that readOnlyHint=true while the call starts a paid subscription and registers a webhook, but the description never claims a data mutation of the company record.
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 core action and duration, then organized by concern (what triggers, exclusions, pricing, delivery, errors, payment). Dense but nearly every clause carries operational information; the nested parentheticals around the DECP stream make that section harder to scan in one pass.
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?
No output schema exists, yet the description still explains the returned `suivi` URL and `jeton`, how alerts arrive (webhook vs polling), lifetime, frequency, rate limits and failure modes. For a paid, long-lived subscription tool, everything an agent needs to call it correctly and set expectations afterward is 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 coverage is 100% and both params are documented there, but the description still adds meaning: the webhook must be a public HTTPS URL, its payload is signed JSON with a named header and HMAC scheme, and the returned `jeton` both signs webhooks and grants access to the pollable `suivi` URL. Format details for `siren` (9 vs 14 digits) are left to the schema.
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 and resource with scope: 'Start monitoring ONE French company for 90 days', then enumerates exactly which events generate alerts (safeguard, receivership, liquidation, plan, closure, deregistration) plus the optional 'marche_public' stream. It explicitly contrasts itself with the sibling verifier_entreprise ('for the current state'), so an agent can route between them without opening a schema.
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 a concrete when-not rule ('Notices already published are not alerted: use verifier_entreprise for the current state') and names the sibling to use instead. It also spells out the conditions under which the second alert type applies (a NEW public contract awarded, DECP open data) and that pre-existing contracts are excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a French company (KYB / supplier check) when you already have its 9-digit SIREN. Returns legal identity (with the intra-EU VAT number and whether VIES reports it active), active/closed status, age, headcount band, establishments, revenue and net income when the company publishes its accounts (entreprise.finances), the current insolvency-procedure state parsed from BODACC notices (safeguard, receivership, liquidation, plans, closures), RGE/Qualiopi labels, a verdict (favorable | vigilance | defavorable | indetermine) justified by stable signal codes, each with its source and a link to the official notice, and a signed Ed25519 attestation of the whole result (public key at /.well-known/jwks.json). When to use another tool: if you only know the company name, call rechercher_entreprise first to get the SIREN. This tool only says whether the company holds an RGE label; for the detailed RGE certifications of one establishment (domains, certifying body, validity dates), call qualifications_rge with its SIRET (entreprise.siege.siret in this result). Optional nom: checks whether a name matches the official one (exacte | partielle | aucune) without ever returning the official name — useful for sole traders, whose names are never disclosed. Errors (never charged): an invalid SIREN (wrong length or Luhn key) is rejected before any payment request; an unknown or non-public company returns an error after the payment is verified but before it is settled; if BODACC is unreachable the verdict is indetermine with confidence partielle. Payment: $0.01 per call via x402 (USDC on Base). No account or API key.
| Name | Required | Description | Default |
|---|---|---|---|
| nom | No | Optional name to check against the official name (2 to 100 characters). | |
| siren | Yes | 9-digit SIREN of the company (Luhn-valid); a 14-digit SIRET is also accepted. Spaces, dots and dashes are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnly/idempotent annotations: it discloses the $0.01 x402 payment model with no account needed, the exact billing semantics of failures ('never charged' — invalid SIREN rejected pre-payment, unknown company errors after payment verification but before settlement), and the degraded-mode behavior when BODACC is unreachable (verdict `indetermine`, confidence `partielle`). It also describes the signed Ed25519 attestation and where to fetch the public key.
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?
Purpose and return contents are front-loaded, and the routing, error, and payment details follow in a logical order. It is dense — a single long block with no line breaks — but virtually every sentence carries decision-relevant information for a tool with a very rich result and a payment side effect.
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?
There is no output schema, so the description must enumerate the return payload, and it does so thoroughly: legal identity, VAT/VIES status, status, age, headcount, establishments, finances, BODACC insolvency state, labels, verdict with signal codes and sources, and the attestation. Combined with the error and payment semantics, an agent has everything needed to call it correctly.
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%, so the baseline is 3, but the description adds real meaning the schema lacks: `nom` yields exacte | partielle | aucune, never returns the official name, and exists primarily for sole traders. The SIREN's SIRET fallback is documented in the schema only, so no extra credit there.
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?
Opens with a specific verb+resource ('Verify a French company (KYB / supplier check)') and states the exact precondition ('when you already have its 9-digit SIREN'). It explicitly names the sibling it is not (rechercher_entreprise for name-only lookups) and delineates its RGE scope against qualifications_rge.
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?
Contains an explicit 'When to use another tool' section that routes the agent: rechercher_entreprise when only a name is known, qualifications_rge with a SIRET for detailed certifications. It also explains what the optional `nom` parameter is for (sole traders, whose names are never disclosed), so the agent knows when to supply it.
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.
apercu_entreprise1 field changedInput schema / properties / verdictAdded value: +{
+ "description": "Free trial with verdict (up to 3 per day): adds verdict, resume and signaux to the preview.",
+ "type": "boolean"
+}marches_publicsgel_avoirsentite_leiprocedures_collectivesapercu_entreprisesurveiller_entrepriseverifier_entreprise1 field changedInput schema / properties / siren / descriptionPrevious value: -"9-digit SIREN of the company (Luhn-valid). Spaces, dots and dashes are accepted."New value: +"9-digit SIREN of the company (Luhn-valid); a 14-digit SIRET is also accepted. Spaces, dots and dashes are accepted."qualifications_rge1 field changedInput schema / properties / siret / descriptionPrevious value: -"SIRET, 14 chiffres."New value: +"14-digit SIRET of the establishment. Spaces, dots and dashes are accepted."rechercher_entreprise3 fields changedInput schema / properties / code_postal / descriptionAdded value: +"Optional 5-digit French postcode, e.g. 69003."Input schema / properties / commune / descriptionPrevious value: -"Code commune INSEE."New value: +"Optional INSEE commune code (5 characters, e.g. 69383 or 2A004), not a city name."Input schema / properties / q / descriptionPrevious value: -"Nom de l'entreprise."New value: +"Company name or part of it (3 to 100 characters)."verifier_entreprise2 fields changedInput schema / properties / nom / descriptionPrevious value: -"Nom à vérifier (facultatif)."New value: +"Optional name to check against the official name (2 to 100 characters)."Input schema / properties / siren / descriptionPrevious value: -"SIREN, 9 chiffres (clé de Luhn valide)."New value: +"9-digit SIREN of the company (Luhn-valid). Spaces, dots and dashes are accepted."qualifications_rgerechercher_entrepriseverifier_entrepriseFrench company data: financials, dirigeants, BODACC, INPI filings, PEP checks, alerts.
French company data: SIREN search, legal profile, financials, changes, groups, filings, scores.
French company data by SIREN or search: address, NAF code, directors, VAT and financials
France company checks by SIREN: status, insolvency, LEI and sanctions from official registers.
Add one secure layer between your agents and this server.
