Skip to main content
Glama

Rechercher des entreprises et établissements

search_company
Read-onlyIdempotent

Recherche des entreprises et des établissements français dans la base SIRENE (INSEE), par nom, SIREN, SIRET, ville, code postal, code NAF, ou par proximité géographique. IMPORTANT : un résultat est TOUJOURS un ÉTABLISSEMENT (un SIRET), jamais une entreprise — même groupé par entreprise, où le SIREN est représenté par son meilleur établissement (le siège de préférence). 3 établissements d'un même SIREN ne font donc pas « 3 entreprises trouvées ». Par défaut, un résultat par entreprise si query est fourni, un résultat par établissement en recherche par proximité ou par siren ; force ce comportement avec group_by_company. classement_pertinence se lit avant de présenter un « meilleur match » : à false (listing simple ou tri par distance), le premier résultat n'est PAS le plus probable. Un résultat diffusible: false a ses nom et adresse masqués par l'INSEE — c'est la loi, pas une donnée manquante, et rien ne s'y complète de mémoire. Une liste vide fait autorité : aucune entreprise ne correspond. La fiche complète s'obtient ensuite via get_company_details. Plan minimum : Discovery — la recherche par proximité (lat/lon/radius_m) nécessite le plan Growth.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoRecherche par proximité (plan Growth) : latitude WGS84 du centre, avec `lon` et `radius_m`.
lonNoLongitude WGS84 du centre de la recherche par proximité, avec `lat` et `radius_m`.
cityNoFiltre sur la commune (recherche floue) ; exige `query`.
pageNoNuméro de page, à partir de 1.
queryNoNom, dénomination, sigle ou enseigne ; un SIREN (9 chiffres) ou un SIRET (14 chiffres) donne une correspondance exacte.
sirenNoTous les établissements d'une unité légale (SIREN, 9 chiffres).
statusNoFiltre : `active` (établissement en activité) ou `closed` (fermé).
addressNoFiltre sur la voie (recherche floue) ; exige `query`.
naf_codeNoFiltre : code NAF/APE de l'activité, ex. `62.02A`.
per_pageNoRésultats par page (défaut 10, plafond 25).
radius_mNoRayon en mètres autour du centre (jusqu'à 50 km) ; plan Growth.
postal_codeNoFiltre : code postal exact.
group_by_companyNoVrai : un résultat par entreprise (son meilleur établissement, le siège de préférence) ; faux : un par établissement. Absent : défaut de l'API selon la recherche.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changed
    • addedInput schema / properties / address / description
      Added value: +"Filtre sur la voie (recherche floue) ; exige `query`."
    • addedInput schema / properties / city / description
      Added value: +"Filtre sur la commune (recherche floue) ; exige `query`."
    • addedInput schema / properties / group_by_company / description
      Added value: +"Vrai : un résultat par entreprise (son meilleur établissement, le siège de préférence) ; faux : un par établissement. Absent : défaut de l'API selon la recherche."
    • addedInput schema / properties / lat / description
      Added value: +"Recherche par proximité (plan Growth) : latitude WGS84 du centre, avec `lon` et `radius_m`."
    • addedInput schema / properties / lon / description
      Added value: +"Longitude WGS84 du centre de la recherche par proximité, avec `lat` et `radius_m`."
    • addedInput schema / properties / naf_code / description
      Added value: +"Filtre : code NAF/APE de l'activité, ex. `62.02A`."
    • addedInput schema / properties / page / description
      Added value: +"Numéro de page, à partir de 1."
    • addedInput schema / properties / per_page / description
      Added value: +"Résultats par page (défaut 10, plafond 25)."
    • addedInput schema / properties / postal_code / description
      Added value: +"Filtre : code postal exact."
    • addedInput schema / properties / query / description
      Added value: +"Nom, dénomination, sigle ou enseigne ; un SIREN (9 chiffres) ou un SIRET (14 chiffres) donne une correspondance exacte."
    • addedInput schema / properties / radius_m / description
      Added value: +"Rayon en mètres autour du centre (jusqu'à 50 km) ; plan Growth."
    • addedInput schema / properties / siren / description
      Added value: +"Tous les établissements d'une unité légale (SIREN, 9 chiffres)."
    • addedInput schema / properties / status / description
      Added value: +"Filtre : `active` (établissement en activité) ou `closed` (fermé)."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "type": "object"
      +}
  2. Added

TDQS

A3.9/5.0
Behavior1/5

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

The description is rich: it always returns an establishment, explains grouping, diffusible masking, and empty-result semantics. However, it asserts 'Une liste vide fait autorité : aucune entreprise ne correspond', which is a closed-world claim that contradicts the openWorldHint=true annotation. Per the rubric, a contradiction forces a score of 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but efficient: every sentence carries a distinct operational caveat or routing instruction, and the main purpose is front-loaded. There is no filler or repetition of schema text.

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 13-parameter, 0-required tool with an output schema, the description covers search modes, defaults, semantic interpretation of results, legal masking, empty results, plan requirements, and the next-step tool. Nothing needed 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: default result grouping for query vs siren/proximity, how to force it with group_by_company, and plan restrictions on proximity parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: searching French companies and establishments in the INSEE SIRENE base, and it lists concrete search criteria (name, SIREN, SIRET, city, postal code, NAF code, proximity). This clearly distinguishes it from sibling address/locality tools and from get_company_details.

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?

It gives clear usage context: default grouping behavior for query vs proximity vs siren, the Growth plan requirement for proximity search, and the follow-up tool get_company_details for the full record. It does not explicitly state when to prefer sibling search tools such as search_address or search_nearby, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.