MCP Recherche d'entreprises
MCP 商业搜索
此 MCP(API 连接模块)允许您与 data.gouv.fr 提供的商业搜索 API 进行交互。
描述
商业搜索 API 允许您搜索和查找法国公司。它提供两种类型的搜索:
文本搜索(姓名、地址、领导人和当选官员)
地理搜索
Related MCP server: MCP INPI
特征
MCP 允许您:
按不同标准搜索公司
通过多个参数过滤结果
访问基本公司信息(名称、SIREN、SIRET、NAF 代码)
使用以下参数围绕某个点执行地理搜索:
搜索点的经纬度
搜索半径(最远50公里)
活动过滤器(NAF 代码、活动部分)
结果分页
来源
此 MCP 基于官方 data.gouv.fr API:商业搜索 API
限制
该 API 有一些限制:
不提供对机构前任和继任者的访问权限
不允许访问不可传播的公司
不允许被拒绝在 RCS 注册的公司访问
地理搜索半径最大限制为 50 公里
技术限制
每秒最多 7 次调用
可用性:上个月 100%
访问:向所有人开放
使用
作为用户
使用此 MCP 的最简单方法是通过npx :
npx mcp-recherche-entreprises作为开发人员
安装依赖项:
npm install项目建设:
npm run build此命令将:
将 TypeScript 文件编译为 JavaScript
将它们放在
dist/文件夹中使 JavaScript 文件可执行
启动:
要使用 MCP Inspector 以开发模式启动服务器(推荐用于开发):
npm run dev要不使用 Inspector 启动服务器:
npm startMCP Inspector 提供了一个图形界面,用于实时测试和调试 MCP 请求。
与光标一起使用
要在 Cursor 中使用此 MCP,请将以下配置添加到您的.cursor/settings.json文件:
{
"mcpServers": {
"recherche-entreprises": {
"command": "npx mcp-recherche-entreprises"
}
}
}此配置将允许 Cursor 自动使用此 MCP 进行商业搜索。
为贡献者提供的 MCP 资源
官方文档
开发工具
MCP Inspector - 调试和分析工具
最佳实践
使用 TypeScript SDK 进行实现
遵循项目代码约定
实施强大的错误处理
清晰地记录 API
保持与未来版本的兼容性
测试和调试
使用检查器进行调试
实施单元测试
检查是否符合 MCP 规范
使用适当的工具分析性能
执照
该项目已获得 MIT 许可。有关详细信息,请参阅LICENSE文件。
贡献
欢迎投稿!查看我们的贡献指南以获取有关如何为该项目做出贡献的更多信息。
Available Tools
2 toolsrechercher_entrepriseC
Recherche des entreprises françaises selon de nombreux critères (nom, activité, localisation, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Termes de la recherche (dénomination et/ou adresse, dirigeants, élus) | |
| activite_principale | No | Le code NAF ou code APE, un code d'activité suivant la nomenclature de l'INSEE. Ce paramètre accepte une valeur unique ou une liste de valeurs séparées par des virgules. Il ne s'applique qu'à l'unité légale, et non à ses établissements. | |
| section_activite_principale | No | Section de l'activité principale (A à U) selon la nomenclature NAF. | |
| categorie_entreprise | No | Catégorie d'entreprise de l'unité légale (PME, ETI, GE). | |
| nature_juridique | No | Catégorie juridique de l'unité légale (code INSEE). | |
| etat_administratif | No | État administratif de l'entreprise (A: Active, C: Cessée). | |
| tranche_effectif_salarie | No | Tranche d'effectif salarié de l'entreprise (ex : 10-19, 20-49, etc.). | |
| code_postal | No | Code postal en 5 chiffres. Ce paramètre filtre sur les établissements et accepte une valeur unique ou une liste de valeurs séparées par des virgules. | |
| code_commune | No | Code commune INSEE en 5 caractères. Ce paramètre filtre sur les établissements et accepte une valeur unique ou une liste de valeurs séparées par des virgules. | |
| departement | No | Code de département en deux ou trois chiffres. Ce paramètre filtre sur les établissements et accepte une valeur unique ou une liste de valeurs séparées par des virgules. | |
| region | No | Code de région en deux chiffres. Ce paramètre filtre sur les établissements et accepte une valeur unique ou une liste de valeurs séparées par des virgules. | |
| epci | No | Code EPCI (établissement public de coopération intercommunale). Ce paramètre filtre sur les établissements et accepte une valeur unique ou une liste de valeurs séparées par des virgules. | |
| est_association | No | Uniquement les entreprises ayant un identifiant d'association ou une nature juridique avec mention 'association'. | |
| est_entrepreneur_individuel | No | Uniquement les entreprises individuelles. | |
| est_ess | No | Uniquement les entreprises d'économie sociale et solidaire (ESS). | |
| est_service_public | No | Uniquement les structures reconnues comme administration (service public). | |
| est_bio | No | Uniquement les entreprises ayant un établissement certifié par l'agence bio. | |
| est_rge | No | Uniquement les entreprises ayant au moins un établissement RGE (Reconnu Garant de l'Environnement). | |
| est_finess | No | Uniquement les entreprises ayant au moins un établissement FINESS (établissements sanitaires et sociaux). | |
| est_qualiopi | No | Uniquement les entreprises certifiées Qualiopi (organismes de formation). | |
| est_societe_mission | No | Uniquement les sociétés à mission (article L.210-10 du code de commerce). | |
| nom_personne | No | Nom d'un dirigeant ou élu (personne physique ou morale). | |
| prenoms_personne | No | Prénom(s) d'un dirigeant ou élu (personne physique). | |
| type_personne | No | Type de personne recherchée : dirigeant ou élu. | |
| ca_min | No | Chiffre d'affaires minimum (en euros). | |
| ca_max | No | Chiffre d'affaires maximum (en euros). | |
| resultat_net_min | No | Résultat net minimum (en euros). | |
| resultat_net_max | No | Résultat net maximum (en euros). | |
| page | No | Numéro de page des résultats (défaut : 1). | |
| per_page | No | Nombre de résultats par page (1 à 25, défaut : 10). | |
| minimal | No | Retourne une réponse minimale (sans tous les champs détaillés). | |
| include | No | Champs à inclure avec minimal=true (complements, dirigeants, finances, matching_etablissements, siege, score). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only says 'searches many criteria' without mentioning pagination, rate limits, response format, or any side effects. This is insufficient for an agent to understand the tool's behavior.
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 a single sentence, concise and front-loaded. It conveys the core purpose without extraneous text. However, it could be slightly more informative while maintaining brevity.
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?
Given the tool's complexity (32 parameters) and the absence of output schema, the description is too brief. It lacks details about return values, pagination, and API source. The sibling tool's presence also suggests a need for clearer context on when to use this one.
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?
The input schema has 100% coverage with detailed descriptions for all 32 parameters. The description adds no new meaning beyond 'numerous criteria'. Baseline 3 is appropriate as the schema handles the parameter documentation.
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 clearly states it searches French companies using multiple criteria like name, activity, location. It includes examples, but does not explicitly differentiate from the sibling tool 'rechercher_entreprise_geographiques', which likely focuses on geographic search.
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?
No guidance on when to use this tool versus alternatives. Given the sibling tool exists, explicit context or when-not-to-use instructions are missing. The description does not mention any prerequisites or scenario-specific advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rechercher_entreprise_geographiquesB
Recherche des entreprises autour d'un point géographique (latitude, longitude, rayon, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude du point de recherche | |
| long | Yes | Longitude du point de recherche | |
| radius | No | Rayon de recherche en km (max 50km) | |
| activite_principale | No | Code NAF ou code APE | |
| section_activite_principale | No | Section de l'activité principale (A à U) | |
| page | No | Numéro de page des résultats (défaut : 1). | |
| per_page | No | Nombre de résultats par page (1 à 25, défaut : 10). | |
| minimal | No | Retourne une réponse minimale (sans tous les champs détaillés). | |
| include | No | Champs à inclure avec minimal=true (complements, dirigeants, finances, matching_etablissements, siege, score). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only mentions basic parameters but lacks details on pagination, sorting, error handling, or result behavior (e.g., ordering by distance). The vague 'etc.' indicates incomplete disclosure.
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 a single short sentence, which is concise but lacks structure. It uses 'etc.' which is vague and unprofessional.
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?
Given the tool has 9 parameters, no output schema, and no annotations, the description is insufficient. It omits details on optional filters (activity types, pagination, minimal response) and does not explain the response structure.
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%, so the schema already documents all parameters. The description adds minimal extra meaning beyond mentioning lat, lon, radius, and 'etc.' Baseline of 3 is appropriate.
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 clearly states the tool searches for companies around a geographic point, specifying key parameters (latitude, longitude, radius). It distinguishes from sibling tool 'rechercher_entreprise' which likely lacks geographic constraints.
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?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or context. It merely describes what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Les deux outils ont des finalités clairement distinctes : le premier permet une recherche générale par critères (nom, activité, localisation), le second se limite à une recherche géographique autour d'un point. Il n'y a pas de chevauchement.
Les noms suivent un schéma cohérent : 'rechercher_entreprise' comme base, avec un qualificatif pour la variante géographique. La convention snake_case est uniforme et prédictible.
Avec seulement 2 outils, le serveur est très ciblé. Pour un service de recherche d'entreprises, cela peut suffire si l'objectif est limité à la recherche, mais le nombre est à la limite inférieure de ce qui est raisonnable.
Les deux modes de recherche (général et géographique) couvrent les cas d'usage courants. Il manque peut-être une recherche par identifiant unique (SIRET) ou des opérations CRUD, mais dans le cadre d'un serveur dédié à la recherche, l'ensemble est presque complet.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
French & European company registry for AI agents: KYB, sanctions, annual accounts. x402, no API key.
Search French companies: financials, directors, ownership, M&A and insolvency events.
INSEE MCP — France's SIRENE business registry (INSEE).
French Companies MCP — recherche-entreprises.api.gouv.fr
Related MCP Servers
- FlicenseBqualityDmaintenanceEnables searching companies in the SIRENE database using SIREN, SIRET, or company name via the INSEE API.1
- FlicenseNot gradedqualityBmaintenanceEnables querying French business registers (RNE, BODACC) and trademarks via INPI APIs. Provides tools to search companies, retrieve legal status, directors, beneficial owners, collective procedures, and trademark details.
- FlicenseNot gradedqualityDmaintenanceEnables searching for French companies using the official data.gouv.fr API, with filters for name, location, activity, and certifications.1
- FlicenseNot gradedqualityCmaintenanceEnables AI agents to search and retrieve detailed profiles of 25 million French companies from the official government registry, including directors, activity codes, and establishment data, without requiring an API key.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yoanbernabeu/mcp-recherche-entreprises'
If you have feedback or need assistance with the MCP directory API, please join our Discord server