Dataroia Data Trust

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not required to restate safety. It adds useful behavioral context beyond these annotations: matches are conservative, uncertain correspondences are flagged as 'à vérifier (homonyme)', and the tool has a quota limit. This is meaningful additional transparency with no 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?

The description is compact and front-loaded with the core purpose, followed by the input shape, the cautionary result behavior, and access conditions. Each sentence carries useful information, though the quota/plan sentence is slightly tangential to invocation correctness.

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 simple two-parameter tool, the description covers the essential input contract and the key behavioral nuance (uncertain matches are flagged). There is no output schema, but the description gives enough about result caution to prepare the agent. The main missing piece is explicit guidance on when to use this versus siblings, but that is already penalized under usage_guidelines.

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%, so the description must compensate, and it does: it documents the full structure of each person object, including optionality markers and expected formats such as 'YYYY-MM-DD'. The api_key parameter is not elaborated, but its purpose is self-evident from the schema. The description adds far more meaning than the minimal schema provides.

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 action ('Croise une liste de contacts') applied to a precise resource ('le registre INSEE des décès'). This clearly differentiates it from sibling tools like resoudre_siren or verifier_siret, which target SIREN/SIRET data rather than death records.

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 is given on when to prefer this tool over sibling tools, nor are any exclusions or alternative tools mentioned. The only contextual note is plan/quota availability, which does not help the agent decide between croiser_deces and tools like diagnostiquer_echantillon or surveilllance_alertes.

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

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

Annotations already declare readOnly and idempotent. The description additionally discloses privacy guarantees ('Aucun envoi à un tiers, aucun stockage') and an input limit (max 100 lines), which goes beyond the annotations. No contradictions with the readOnlyHint.

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 two sentences, front-loaded with the main action and scope, followed by a privacy/limit note and a pointer to a fuller service. Every sentence adds value, and there is no redundant repetition of schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description does not explain what the diagnostic result looks like (e.g., report format, JSON structure, or summary). It covers input constraints and privacy but leaves the return value unspecified. For a simple single-parameter tool, this is a notable gap that could confuse an agent expecting a certain output type.

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 no description (0% coverage). The description implies that the parameter is the CSV content due to the tool's purpose, but it does not explicitly define expected format, encoding, or delimiter. The mention of 'max 100 lignes, en-tête inclus' provides partial guidance, but the parameter itself remains somewhat ambiguous.

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 ('Diagnostic qualité') and resource ('extrait de fichier CRM/client au format CSV'), with clear scope (max 100 lines, header included). It enumerates the checks performed, which distinguishes it from sibling tools like 'verifier_siret' or 'resoudre_siren' that focus on individual entity lookup.

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 CSV file quality analysis based on the purpose statement, but it does not explicitly state when to use this tool versus sibling tools. The mention of a full diagnostic via an external URL hints at a free-limited mode but does not compare against alternatives within the same API.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds meaningful behavioral constraints beyond annotations: an API key is required, the free plan has access, and only one SIREN is processed per call. This is valuable operational context.

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 two sentences: the first states the core function, the second states constraints. It is front-loaded and every word contributes to the understanding of the tool.

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 adequately conveys purpose, inputs, key limitations, and hints at the output (vital status + score). It does not detail the full return structure, but for a simple retrieval tool with known inputs and constraints, it is sufficiently 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?

The schema provides no descriptions for the two parameters. The description clarifies that 'sirens' is a list of SIREN numbers and that 'api_key' is required, and it adds the free-plan limitation of 1 SIREN per call. This adds some meaning, but it does not specify SIREN format or how multiple sirens are handled if only one is allowed per call.

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 retrieves active directors from RNE (INPI) for a list of SIRENs, cross-referenced with the INSEE death registry. It specifies the resource (directors) and the scope (list of SIRENs), and it implicitly distinguishes from sibling tools like croiser_deces or resoudre_siren.

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 API key requirement and the free plan limit (1 SIREN per call), which provides usage context. However, it does not explicitly compare this tool to alternatives or state when to prefer it over sibling tools, so the guidance is implied rather than explicit.

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

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

Annotations already mark this as read-only/idempotent, and the description adds meaningful behavioral context: ignored legal forms and accents, homonym disambiguation via postal code, per-request response fields, the fiabilité scale, a safety warning about ambiguous SIRENs, and the fact that it is free without an API key. 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 dense but every sentence adds value: purpose, normalization behavior, disambiguation tip, input format, output format, safety guidance, and cost. It is front-loaded with the core purpose and remains readable without fluff.

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 sparse schema and no output schema, the description is remarkably complete. It explains the exact request payload, response fields and reliability levels, the limitation to 10 companies, a critical user-facing guideline, and operational characteristics like cost and keyless access. No important usage aspect is missing for a tool of this complexity.

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 is extremely sparse, offering only an array of objects with no per-field descriptions. The description fully compensates by specifying the expected object structure ({"nom": str, "code_postal": str?, "ref": str?}), the max batch size, and the per-company response fields, enabling correct invocation and response interpretation.

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 a specific action ('Retrouve le SIREN') and resource ('entreprises françaises'), and it distinguishes itself from siblings like verifier_siret by focusing on resolving names from CRM data to SIREN identifiers, not verifying a provided 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?

Provides concrete usage context: when you have company names as written in a CRM, when to include postal code for disambiguation, a batch limit of 10, and the lack of API key. It does not explicitly mention when not to use it or point to alternatives, but the context is clear enough for correct selection.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds value beyond annotations by disclosing the API-key requirement, free-plan access, and the 5-SIREN-per-call limit. This does not contradict the read-only or idempotent hints.

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 front-loaded sentence that opens with the output and then lists relevant sources and constraints. The semicolon-separated source list is dense, but each element contributes meaningful context and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still conveys the core return concept (score 0-100, label A-D) and covers auth, quota, and input scope, which is enough for an agent to select and invoke the tool. Minor gaps remain around output structure and handling of invalid or missing SIRENs, but they are not blocking for invocation.

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 the description must compensate for the sparse schema. It clarifies that sirens are SIREN identifiers, that an API key is required, and that calls are limited to 5 SIRENs. However, it does not specify SIREN format, array constraints, or key handling beyond the schema property names.

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 computes a consolidated health score (0-100, label A-D) per SIREN and enumerates the data sources, making its purpose unambiguous. It does not explicitly contrast it with siblings like dirigeants_entreprise or diagnostiquer_echantillon, so it lacks full sibling differentiation.

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 gives useful operational context: the input is per SIREN, an API key is required, and the free plan allows 5 SIREN per call. However, it never states when to prefer this tool over sibling tools or when not to use it, so usage conditions are only implied.

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

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

Despite annotations already indicating non-read-only behavior, the description adds meaningful detail: setting marquer_lues=true acknowledges alerts so subsequent calls return only new ones. It also discloses the API key requirement, providing useful operational context beyond the schema.

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 three sentences, front-loaded with the core purpose and alert types, followed by the stateful behavior and auth requirement. Every sentence earns its place with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and basic annotations, the description covers purpose, alert categories, stateful acknowledge behavior, and authentication. It lacks details about the return format and leaves non_lues_seulement under-explained, but it is sufficient for an agent to select and invoke the 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 description coverage is 0%, so the description must compensate. It clearly explains marquer_lues and mentions the api_key requirement, but it does not explain non_lues_seulement, which is a parameter with a default true value and non-obvious semantics. Partial coverage earns a middle score.

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 identifies this as an alert-listing tool for a monitored portfolio, enumerating specific alert types (cessation SIRENE, BODACC, dirigeant changes). It positions itself as the 'what's new since my last visit' tool, which distinguishes it from sibling tools like resoudre_siren or verifier_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?

The description provides strong usage context: use this to see new alerts rather than re-checking SIRENs individually. It also explains the stateful behavior of marquer_lues, though it does not explicitly state when not to use the tool or name alternative tools for other use cases.

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

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

Beyond the annotations (idempotentHint=true, destructiveHint=false), the description discloses significant behavioral nuances: the silent reference establishment on first passage, the transition of subsequent changes into alerts, and the fact that the limit is portfolio size per plan (free 10, solo 50, starter 100, business 1000) rather than an API call counter. These details are not evident from annotations or schema. The description does not contradict any annotation.

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 compact, front-loading the core purpose and then adding conditional usage and behavioral notes. It packs necessary details without excess verbosity. The structure is logical: purpose, actions, parameter requirements, behavioral quirks, and limits. It could be slightly tighter but remains 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 the tool has no output schema, the description covers the essential operational aspects: actions, parameter requirements, behavioral state changes, and plan limits. It does not describe the return format or error handling, but for a portfolio management tool these may not be critical. The references to 'surveillance_alertes' provide linkage to the broader context. Overall, the description is sufficiently complete for correct invocation.

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 the description fully compensates. It defines the allowed values for 'action' ('lister' | 'ajouter' | 'retirer'), explains that 'sirens' is required except for 'lister', and confirms that 'api_key' is required. It also clarifies the meaning of the SIREN list in the context of portfolio management. This is essential since the schema lacks enums and descriptions.

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 ('Gère le portefeuille de SIREN surveillés par Dataroia') with a clear resource and scope. It also enumerates the three actions ('lister', 'ajouter', 'retirer'), making the purpose unambiguous. It implicitly differentiates from sibling tools like 'surveillance_alertes' by clarifying its role as portfolio management rather than alert delivery.

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 gives explicit usage guidance: it lists valid actions, states that 'sirens requis sauf lister' (SIRENs required except for listing), and points to 'surveillance_alertes' for alert-related workflows. It also explains that the first passage on a SIREN establishes a silent reference and subsequent changes become alerts, which informs when to use this tool for setup versus when to rely on the alert tool. However, it does not explicitly contrast against other siblings like 'sante_entreprise' or 'dirigeants_entreprise', so it is clear but not exhaustive.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral detail: exact checks, local data source, conditional successor indication, and the free/no-API condition. 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 concise: three sentences, each providing valuable information. It front-loads the action and object, lists checks efficiently, and includes the successor behavior and pricing without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only verification tool with one parameter, the description is complete: it covers purpose, source, limit, checks, successor logic, and cost. Although no output schema exists, the expected result types (existence, closure, cessation, BODACC, successor) are described.

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 the description compensates well by specifying the 14-digit format and the maximum of 10 SIRETs. It implies the array nature through 'jusqu'à 10 SIRET' but does not explicitly name the parameter or state it is an array.

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 identifies the action ('Vérifie'), the resource (SIRET numbers), the data source (local SIRENE INSEE base), and the exact checks performed (existence, closed establishment, ceased legal unit, BODACC collective procedure). This level of detail distinguishes it from siblings like resoudre_siren or dirigeants_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 gives clear usage context: batch size limit (up to 10 SIRET), local base, free and no API key. It implies when to use the tool (verifying SIRETs) but does not explicitly mention alternatives or when not to use it, so it falls short of the full 5.

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