Dataroia Data Trust
Server Details
Vérification B2B française : SIRET, SIRENE, dirigeants RNE, santé d'entreprise. Hébergé en France.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 5 of 5 tools scored.
Each tool addresses a distinct data verification need: death registry cross-check, CRM sample quality diagnosis, company leaders lookup, health score, and SIRET validation. No functional overlap.
Tool names use French and underscores, but mix verb_noun (croiser_deces, diagnostiquer_echantillon, verifier_siret) with noun_noun (dirigeants_entreprise, sante_entreprise), lacking a uniform pattern.
With 5 tools, the server covers essential data trust operations without being bloated or sparse. The count fits the niche scope perfectly.
Covers core verification tasks (death, health, leaders, SIRET validity) and sample diagnostics. A minor gap is the lack of a direct company search by name, but the set is sufficient for typical use cases.
Available Tools
5 toolscroiser_decesARead-onlyIdempotentInspect
Croise une liste de contacts avec le registre INSEE des décès. Chaque personne : {"nom": str, "prenom": str, "annee_naissance": int?, "date_naissance": "YYYY-MM-DD"?, "code_postal": str?, "ref": str?}. Résultat prudent : les correspondances non certaines sont marquées « à vérifier (homonyme) ». Réservé aux plans payants (starter+).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | ||
| personnes | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds valuable behavioral context: the result is cautious, marking uncertain matches as 'à vérifier (homonyme)'. No contradiction with 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?
The description is extremely concise (3 sentences) and front-loaded with the core action. Every sentence adds value without redundancy.
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 no output schema, the description does not specify the return structure, but it provides enough context for usage: input format, plan restriction, and behavioral caution. The tool is a simple cross-reference, so the description is nearly complete.
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 0%, but the description compensates by detailing the expected structure of each person object (nom, prenom, optional fields), adding meaning beyond the bare schema. The api_key parameter is not described, but its purpose is obvious.
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 action (croise) and resource (registre INSEE des décès), and the tool is distinct from sibling tools (diagnostics, directors, etc.).
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 mentions the plan restriction (Réservé aux plans payants) but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
diagnostiquer_echantillonARead-onlyIdempotentInspect
Diagnostic qualité gratuit d'un extrait de fichier CRM/client au format CSV (max 100 lignes, en-tête inclus) : emails et téléphones invalides, SIREN/SIRET à clé fausse, doublons, cellules vides, identifiants détruits par Excel. Aucun envoi à un tiers, aucun stockage. Pour le diagnostic complet gratuit (1000 lignes, croisement SIRENE/BODACC/décès + manque à gagner chiffré) : https://dataroia.com
| Name | Required | Description | Default |
|---|---|---|---|
| csv_texte | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds important behavioral context: the diagnostic is free, no data sent to third parties, no storage. This aligns with and supplements the annotations without contradiction.
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?
Two sentences, no wasted words. The first sentence specifies the tool's function and checks, the second offers a link to a more comprehensive version. Perfectly front-loaded and efficient.
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 a single required parameter and no output schema, the description covers input format, limitations, and behavioral assurances. It fully equips the agent to understand what the tool does and when to invoke it.
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 schema has one parameter 'csv_texte' with only a title. The description adds crucial meaning: it must be a CSV extract (max 100 lines, header included). This compensates well for the 0% schema description coverage.
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 performs a free quality diagnostic on a CRM/client CSV extract, listing specific checks (invalid emails/phones, false SIREN/SIRET, duplicates, empty cells, Excel-damaged IDs). It distinguishes from a more comprehensive paid service, making the purpose explicit.
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 context on when to use (free diagnostic of small CSV extract) and points to an alternative for a more complete diagnostic. It does not explicitly state when NOT to use this tool (e.g., larger files or different data types), but the scope is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dirigeants_entrepriseARead-onlyIdempotentInspect
Dirigeants actifs au RNE (INPI) pour une liste de SIREN, croisés avec le registre INSEE décès (statut vital + score). Clé API requise — le plan gratuit y a accès (1 SIREN par appel).
| Name | Required | Description | Default |
|---|---|---|---|
| sirens | Yes | ||
| api_key | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, destructiveHint; description adds behavioral context about API key requirement and call limitation on free plan, which goes beyond 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?
Two concise sentences that front-load the main purpose and constraints. No unnecessary words.
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?
Covers input (list of SIRENs, API key), output (directors crossed with death registry), and source (RNE/INPI, INSEE). No output schema exists, so description suffices for basic understanding.
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 0%, but description partially explains 'sirens' as 'liste de SIREN' and 'api_key' as 'Clé API requise'. It does not specify format or validation, so only moderate compensation.
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?
Description specifies verb 'dirigeants actifs' and resource 'RNE (INPI)' with cross-reference to death registry. It distinguishes from sibling tools by explicitly stating the data sources and the limitation to 1 SIREN per call on free plan.
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?
Description provides clear context about API key requirement and free plan limitation, aiding when to use. However, it does not explicitly compare with sibling tools like 'croiser_deces' or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sante_entrepriseARead-onlyIdempotentInspect
Score santé consolidé (0-100, label A-D) par SIREN : statut SIRENE, procédures BODACC, comptes annuels INPI, benchmark Banque de France, dirigeants RNE croisés avec le registre INSEE décès. Clé API requise — le plan gratuit y a accès (1 SIREN par appel).
| Name | Required | Description | Default |
|---|---|---|---|
| sirens | Yes | ||
| api_key | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations indiquent readOnlyHint=true, destructiveHint=false et idempotentHint=true, donc l'outil est sûr et en lecture seule. La description ajoute des informations au-delà des annotations : l'exigence de clé API, la limitation du plan gratuit (1 SIREN par appel), et la liste des sources de données utilisées. Ce contexte supplémentaire est utile sans contredire les 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?
La description est concise : deux phrases. La première intègre de manière dense l'essentiel de la fonctionnalité (score, plage, sources). La seconde donne une contrainte d'utilisation. Pas de mots inutiles, l'information importante est placée en début de description.
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?
L'outil a une certaine complexité (combinaison de plusieurs sources, score consolidé). La description couvre bien les sources et le score, mais elle ne décrit pas le format de la réponse (structure JSON attendue), les erreurs possibles (SIREN invalide, clé API manquante), ni la gestion des limites de taux au-delà du plan gratuit. La présence d'un schéma de sortie aiderait, mais il est absent.
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?
Le schéma de paramètres n'a aucune description (couverture 0%). La description compense en partie : 'par SIREN' explique le paramètre sirens (bien qu'il soit un tableau et que la description implique un seul SIREN), et 'Clé API requise' explique le paramètre api_key. Cependant, il manque des détails comme le format attendu des SIREN ou la provenance de la clé API.
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?
La description indique spécifiquement qu'il s'agit d'un 'Score santé consolidé (0-100, label A-D) par SIREN', avec une liste détaillée des sources de données (SIRENE, BODACC, INPI, Banque de France, RNE, INSEE décès). Cela permet de distinguer clairement l'outil des outils frères (croiser_deces, diagnostiquer_echantillon, etc.) qui ont des objectifs plus ciblés.
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?
La description mentionne 'Clé API requise — le plan gratuit y a accès (1 SIREN par appel)', ce qui donne un contexte d'utilisation (authentification requise et limitation du plan gratuit). Cependant, elle ne précise pas explicitement quand utiliser cet outil plutôt que les outils frères, ni les cas où il ne faut pas l'utiliser. Le contexte est clair mais les exclusions ou alternatives ne sont pas mentionnées.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verifier_siretARead-onlyIdempotentInspect
Vérifie jusqu'à 10 SIRET (14 chiffres) sur la base SIRENE INSEE locale : existence, établissement fermé, unité légale cessée, procédure collective BODACC. Si l'établissement est fermé, indique le SIRET successeur quand un lien de succession SIRENE existe. Gratuit, sans clé API.
| Name | Required | Description | Default |
|---|---|---|---|
| sirets | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, and non-destructive hint. Description adds detailed behavioral traits: existence check, closed establishment, ceased unit, BODACC procedure, and successor SIRET. No contradictions found.
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?
Single dense sentence with no wasted words. Front-loaded with action and resource, then lists details. Perfectly concise for the information conveyed.
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?
Covers key features: multiple checks, successor, free. No output schema, so response format is absent. Given the tool's complexity, it is mostly complete but misses potential error handling or pagination details.
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 0%, so description must compensate. It specifies 'jusqu'à 10 SIRET (14 chiffres)', adding limit and format. However, it does not explain array item constraints or error cases, leaving some ambiguity.
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?
Description clearly states the verb 'Vérifie' and resource 'SIRET', specifying checks against SIRENE INSEE for existence, closed status, ceased legal unit, and BODACC procedures. It also mentions successor SIRET. This distinguishes it from sibling tools like 'croiser_deces' or 'sante_entreprise'.
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 implies usage for verifying SIRET numbers but does not explicitly state when to use this tool versus alternatives. It mentions it is free and without API key, but lacks exclusions or context for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!