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

With no annotations at all, the description carries the full burden and does substantial work: it discloses that the tool reads the PDF, calls Urssaf to verify the code (an external dependency), and computes an explicit expiry rule (6 months after the analysed period, end of month). It also defines the three verdict tiers and the ALERTE threshold (<30 days). Gaps remain: it does not state that the operation is read-only/side-effect free, nor how Urssaf unavailability or unreadable PDFs are handled.

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 dense but well-formed blocks: the scope of the check first, the possible verdicts second. Front-loaded and free of filler, though the long parenthetical enumeration of checked fields is slightly list-like rather than prose.

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 and no annotations, so the description is the only source of truth. It does define the verdict vocabulary and the validity rule, which is the critical return-value semantics. But it leaves the input contract incomplete ('fichier' format, 'domaine' meaning) and says nothing about side effects, failure modes, or cost/latency of the Urssaf lookup — significant for a tool that performs external verification.

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 does add real meaning for two of the four parameters by explaining that siret_attendu/siren_attendu define the 'cocontractant attendu' and feed the coherence check. But 'fichier' (the only required parameter) is never described — path, URL or base64 is unknown — and 'domaine' is entirely unexplained, which is the most damaging omission.

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 ('Contrôle complet d'une attestation reçue') and enumerates exactly what the check covers: PDF reading, Urssaf code verification, field-by-field coherence, cocontractant matching, validity window. It is clearly a heavier, composite operation than the sibling 'verifier_attestation', but the description never names the siblings or explicitly contrasts with them, so differentiation is only implied by the word 'complet'.

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 phrase 'attestation reçue' and 'Contrôle complet' imply this is the full end-to-end validation path, and the mention of siret_attendu/siren_attendu implies a cocontractant-matching use case. However, there is no explicit when-to-use versus 'verifier_attestation', 'verifier_attestations' or 'lire_attestation_pdf', and no stated preconditions or exclusions.

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?

Because no annotations are provided, the description carries the full disclosure burden. It usefully states that secrets are excluded, which is meaningful security context. However, it does not explicitly state that the tool is read-only, that it has no side effects, or how the output is structured.

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 definition is a single compact sentence that front-loads the key scope 'sans secrets'. The term 'écriture' is slightly ambiguous, but overall there is no wasted text.

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 zero-parameter tool with no output schema, listing the returned fields is a useful substitute for an output description. Missing field-level semantics, such as what 'écriture' and 'version' mean precisely, are a minor gap for a simple configuration-inspection tool.

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 tool has zero parameters, so the schema baseline is 4. The description's list of configuration fields refers to returned content, not input parameters, and therefore does not create ambiguity about how to call the tool.

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 resource: the current connector configuration (without secrets). It also lists the fields returned, which makes the purpose clear and distinguishes it from the sibling attestation and tracking tools. However, it avoids an explicit action verb and instead relies on the email-like noun phrase 'Configuration courante'.

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 no when-to-use guidance, no exclusion criteria, and no mention of alternatives among the sibling tools. An agent can infer that this is a diagnostic or state-inspection call, but that inference is not supported by explicit instructions.

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?

No annotations are provided, so the description carries the burden. It usefully discloses that no network call occurs and enumerates the extracted fields, but says nothing about failure behavior on malformed/non-Urssaf PDFs or whether extraction is lossy.

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 short sentences (a purpose statement plus a return-field enumeration), front-loaded and free of padding. The list of fields earns its place because no output schema exists.

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?

The field enumeration compensates for the absent output schema, and the offline note covers a key behavioral trait. However, the single undocumented parameter's input format and error handling remain unaddressed, leaving gaps for an agent to fill.

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?

Only one parameter exists ('fichier') with 0% schema description coverage, and the description does not clarify whether it expects a file path, uploaded content, or base64. The 'sans appel réseau' note weakly implies a local file, but the input format remains 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?

States a specific verb (extrait) and resource (données d'un PDF d'attestation de vigilance Urssaf), so an agent knows this is a parser, not a verifier. It doesn't explicitly name the sibling verifier/controler tools to draw the boundary, leaving that differentiation implicit.

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 parenthetical '(sans appel réseau)' hints that this is the offline parsing option versus the network-based verification siblings, but the description never says when to choose this over verifier_attestation or controler_attestation explicitly.

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?

With no annotations at all, the description carries the full burden. It does disclose one important behavioral trait — that an existing file will not be overwritten (an error/refusal rather than silent destruction) — which is genuinely useful. It says nothing about permissions, whether parent directories are created, or what the tool returns (e.g. the created path).

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 tight sentences: the first front-loads what is created and where, the second adds the no-overwrite constraint. Nothing is redundant, though the column enumeration is long enough to slightly dilute the core action.

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 one-parameter creation tool with no output schema and no annotations, the description covers the artifact and one safety behavior. It still omits the parameter's path semantics and the return value (does it return the file path?), which an agent calling it blind would need.

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% for the single required parameter 'fichier'. The phrase 'à l'emplacement indiqué' only weakly suggests the parameter is a file path; it does not specify expected format/extension, absolute vs relative path, or whether the directory must already exist. This leaves the agent guessing about the most important input.

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 ('Crée') and a precisely scoped resource ('un classeur Excel de suivi vierge') and even enumerates the columns it will contain, so an agent knows exactly what artifact will exist afterwards. It is clearly distinguishable from siblings like suivi_lister or suivi_verifier, which operate on data rather than creating a blank template.

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 implied use case (produce a fresh tracking template to fill in later) is deducible, and the 'refuses to overwrite' clause effectively states one when-not condition. However, no sibling is named as an alternative and there is no guidance on when to use this versus suivi_lister/suivi_verifier or what to do if the file already exists.

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?

With no annotations, the description must carry the full behavioral burden. It does clarify that this is a read of an Excel file and what the returned entries contain, but says nothing about missing-file behavior, default file location, performance, or whether the read is side-effect free.

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, front-loaded with the resource and the shape of the result before the filter detail. Nothing is padding, though the long parenthetical field list is dense.

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 row fields and the unique-code list. The remaining gap is the unexplained `fichier` parameter and lack of failure-mode context.

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 for both parameters. It explains `seulement_a_verifier` well (keeps only codes whose verification is untraced), but `fichier` is never mentioned — no meaning, format, or default behavior — leaving half the parameters undocumented.

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 ('Lit le tableau Excel « Suivi des attestations par entreprise »') and enumerates the row fields plus the unique-code list, so the agent knows exactly what comes back. It does not explicitly contrast itself with sibling tools like suivi_verifier or verifier_attestations.

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 only usage signal is the filter semantic for `seulement_a_verifier` ('ne garde que les codes dont la vérification n'est pas tracée'), which implies a pre-check workflow. There is no explicit statement of when to call this versus suivi_verifier or verifier_attestations, and no prerequisites (e.g., whether the file must already exist).

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?

With no annotations, the description carries the burden and does well: it discloses that writing requires both `ecrire=True` and `URSSAF_ECRITURE=1`, specifies which columns are updated, and makes clear that omitting `ecrire` performs a simulation. It does not mention error handling or return values.

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 dense but front-loaded sentence that puts the primary action first and layers conditions efficiently. It is somewhat packed with parenthetical detail, but no sentence is wasted.

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 three-parameter mutation tool with no annotations and no output schema, it covers the main write behavior and dry-run semantics but omits the `fichier` parameter and does not say what the verification returns. It is adequate but has clear gaps.

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. It clearly explains `tous` and `ecrire`, but it never defines the `fichier` parameter or its expected format/path, leaving one of three parameters undocumented.

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: verifying Urssaf codes in the tracking table and optionally writing results. It is clearly distinct from the attestation-focused siblings, though it does not explicitly name those alternatives.

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 explains the default mode (only unchecked codes), the `tous=True` override for monthly re-checks, and the simulation behavior when `ecrire` is omitted. Usage is clear, but it does not route the agent against sibling tools or state exclusions.

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?

With no annotations, the description carries the full behavioral burden and does well: it enumerates normalized statuses (valide, perimee, inconnue, incomplete, erreur), explains that inconnue may indicate possible fraud, and lists the fields returned for a valid attestation. It does not mention side effects, authentication, or rate limits, but it substantially describes observable 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 front-loaded with the action, followed by a compact status list and a final domain note. Every part contributes useful information, with only minor density in the status enumeration.

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?

Because there is no output schema and no annotations, the description must explain return behavior, and it does by listing both statuses and valid-attestation fields. It is nearly complete for invocation, missing only explicit sibling differentiation and operational constraints such as auth or rate limits.

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, and it does: it specifies that `code` is a 15-character security code and explains `domaine` with URSSAF as default for employers and ISU for artisans, merchants, and independent workers. This is strong coverage, though the exact code format remains unspecified.

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: verifying a 15-character security code with Urssaf. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling verifier_attestations (plural) or controler_attestation.

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?

There is no explicit guidance on when to use this tool versus the several sibling verification tools. The only orientation provided is about the `domaine` parameter, which is parameter semantics rather than tool-selection guidance.

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?

No annotations exist, so the description carries the full burden. It does disclose two useful traits beyond the schema: a batch limit of 100 codes per API call and one result per code. It says nothing about error handling for malformed or unknown codes, authentication requirements, or whether the operation has side effects.

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 short sentences, no filler, with the batch constraint front-loaded before the return behavior. Every clause conveys distinct 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?

With no annotations and no output schema, the description must explain both safety profile and results. 'Un résultat par code' establishes cardinality but not what a result contains (valid/invalid status, reason codes), leaving a meaningful gap for a verification tool.

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 single 'codes' array parameter is undocumented in the schema. The description partially compensates by identifying the values as security codes and capping batches at 100, but it omits format expectations (length, character set, duplicates) that an agent needs to build valid input.

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 (verify multiple security codes) and makes the batch nature explicit with 'plusieurs codes', which implicitly separates it from the singular sibling verifier_attestation. It never names that sibling, so the differentiation is inferred from plurality rather than stated.

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?

'Lots de 100 par appel API' implies the batch use case and gives a practical batching threshold, which is real usage context. However, there is no explicit statement of when to choose this over verifier_attestation, nor any exclusion or prerequisite.

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