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

Annotations only declare read-only and open-world behavior; the description adds the INPI source, the returned metrics, the two fiscal years, and the account types (complete, simplified, consolidated). It still does not explain response structure or missing-data behavior, so it adds useful but not comprehensive behavioral 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?

Two sentences, front-loaded with the resource, then a compact parenthetical enumeration and account-type qualifier. Every element earns its place, and there is no redundant restatement of the title.

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, two-parameter lookup with no output schema, the description gives the return-field inventory, source, periods, and account scope. It is complete enough to call correctly, though it omits availability caveats.

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 100%, so the baseline is 3; the description adds that results cover the requested exercise and the previous one, clarifying the exercice parameter's effect. It does not add SIREN syntax, but the schema already documents that fully.

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 names the exact resource: key figures from annual accounts filed with INPI, and enumerates the financial metrics and periods covered. It is clearly distinguishable from company identity and document 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?

There is no explicit when-to-use or when-not-to-use guidance, nor any named alternative among the sibling tools. An agent can infer this is for financial key figures, but the description does not route between this, fiche_entreprise, and the document-download tools.

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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about the official INPI source and the fields included, but it does not describe behavior for missing patents, response format, rate limits, or auth requirements.

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 immediately identifies the tool and then lists the returned fields. The field list is long but useful given the absence of an output schema, and there is no redundant 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 appropriately enumerates the kinds of data returned by the patent record, covering title, dates, parties, classifications, and events. It is largely complete for a read-only lookup tool, though it omits usage routing and edge-case behavior.

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%, and the single 'numero' parameter is fully documented in the schema with examples. The description does not add any further meaning about the parameter format or validation beyond what the schema already 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 clear resource ('Fiche d'un brevet') and enumerates the patent data it returns, so the agent can tell it retrieves a detailed patent record. It does not explicitly distinguish itself from the sibling 'rechercher_brevets', which keeps it from a 5.

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 the tool is for obtaining a full patent record from an INPI notice, but it gives no explicit when-to-use guidance, prerequisites, or comparison with alternatives such as 'rechercher_brevets'. The agent must infer the routing decision.

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 the safety profile (readOnlyHint, openWorldHint), so the description's real contribution is disclosing the restricted scope: bénéficiaires effectifs are not accessible. It also compensates for the absent output schema by enumerating the returned fields, though it says nothing about behavior when the SIREN is unknown or invalid.

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, the core purpose front-loaded followed by the scope limitation. The long field enumeration earns its place because there is no output schema, though it could be tightened slightly.

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 usefully enumerates return fields and flags the restricted data. Gaps remain on failure behavior (unknown SIREN, nonexistent company) and on how a SIREN is obtained, but the essential calling information is present.

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 100% and the schema already specifies the 9-digit SIREN format and that spaces are tolerated. The description adds nothing about the parameter, so the baseline 3 applies.

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?

Names a specific resource (fiche d'une entreprise) and its authoritative source (Registre national des entreprises), then enumerates exactly which fields it returns. That enumeration distinguishes it implicitly from rechercher_entreprises, but it never explicitly states the relationship to that sibling, which keeps it from a 5.

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?

Usage is only implied: the field list suggests it is a detail lookup by SIREN and the note on bénéficiaires effectifs excludes one data need. There is no explicit 'call this when you already have a SIREN' guidance, no mention that rechercher_entreprises should be used first to obtain one, and no error-case 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: the data provenance (official INPI notice) and the depth of what is returned, including the complete history of inscriptions such as assignments, name changes, partial surrenders and post-limitation wordings. It does not say what happens for an unknown or malformed number, which keeps it short of a 5.

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?

Front-loaded with the purpose and provenance, then a dense enumeration of returned fields. The field list is long but each item earns its place because there is no output schema to convey the payload shape. Slightly list-heavy but free of 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 carries the burden of describing the return payload and does so thoroughly, enumerating every field family an agent could need. The remaining gap is error behavior for invalid or unknown numbers, which matters for a lookup tool but is minor against the otherwise complete picture.

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?

There is a single parameter at 100% schema description coverage, and the schema itself already explains the prefix conventions (FR4020655, EU019023157, WO1234567, and that bare 7 digits default to FR). The description adds no format, validation or resolution detail beyond that, so the baseline 3 applies.

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+resource: fetching the complete record of a trademark from the official INPI notice, and enumerates the exact content domains (name, type, status, dates, holder, Vienna codes, BOPI publications, full inscription history). The resource noun 'marque' cleanly separates it from sibling fiche_brevet and fiche_modele, so an agent can route without opening the schema.

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?

Usage is only implied: the required 'numero' parameter signals this is a lookup-by-identifier tool, and 'd'après la notice officielle de l'INPI' implies an authoritative single-record fetch. The description never says when to prefer it over rechercher_marques, nor that a number must first be obtained via search, and gives no 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that data comes from the official INPI notice and enumerates the sections returned (including inscription history), which is useful context, but it says nothing about failure modes (invalid or unknown numero) or response size.

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?

A single front-loaded sentence identifying the resource and its source, followed by a compact field list with no filler. The enumeration is long but each item earns its place by telling the agent what data is available.

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 carries the return-value burden by listing the record's sections, which it does well; the parameter is documented in-schema and safety is in annotations. Only error/invalid-identifier behavior is missing.

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% and the schema already gives concrete numero formats (FR20140182, FR20140182-002, WODM071720-001), so the description adds nothing beyond it. Baseline 3 is appropriate for a single fully documented parameter.

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-resource pair ('Fiche d'un dessin ou modèle') and enumerates the record's scope (dépôt, pays, statut, Locarno, historique), so an agent can tell it apart from the sibling search tool rechercher_modeles. It stops short of explicitly naming the search-vs-fetch distinction, which keeps it from a 5.

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?

Usage is only implied: the single required 'numero' parameter signals this is a follow-up lookup after obtaining an identifier, presumably from rechercher_modeles. There is no explicit when-to-use/when-not statement or named alternative.

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=true and openWorldHint=true, so the safety profile is covered. The description adds that results carry a download identifier and clarifies what statuts_seulement keeps, but says nothing about auth, coverage limits, or return shape.

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 front-loaded sentences with no filler; the core purpose leads and the filter note follows. The second sentence largely echoes the schema's own wording for statuts_seulement, a minor 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?

A simple read-only, three-parameter tool with full schema coverage and safety annotations; the description covers what is returned (documents plus download id) and the filter behavior. No output schema exists, but the mention of the download identifier gives enough of the return contract.

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 all three parameters (including the enum type and the SIREN format) are already documented. The description restates the statuts_seulement semantics without adding format or interaction details, so the baseline 3 applies.

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 (Liste) and resource (actes et comptes annuels déposés au RNE) scoped to one entreprise, plus what each item carries (identifiant de téléchargement). An agent grasps the purpose without the schema, but no sibling is named for 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?

Usage is only implied: it lists documents and returns a download identifier, which hints that telecharger_document_entreprise consumes that id. There is no explicit statement of when to use this versus chiffres_cles_comptes or the download sibling, and no prerequisites.

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=true and openWorldHint=true, so the safety profile is covered. The description adds that the search spans four INPI collections and that criteria are AND-combined, which is useful behavior. It says nothing about result shape, pagination ceilings, or cost/latency of broad queries (position max 500, taille max 100 only live in 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?

Two sentences, front-loaded with the scope statement before the field list; the AND-combination rule is placed last where it belongs. The field enumeration is long but earns its place as a quick scan of searchable axes.

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 19-parameter, fully self-documented search schema with no output schema and no required params, the description covers collections, searchable axes and filter combination. The main residual gap is that return format and pagination behavior are left entirely to the schema, and no sibling routing is offered.

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% and each of the 19 parameters is documented in the schema (formats, defaults, SIREN pattern, wildcards, requete_avancee field codes). The description's field enumeration largely mirrors the schema, adding the CIB/CPC hint and the title/abstract scoping for keywords, but no syntax or interaction rules beyond that. Baseline 3 applies.

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 ('Recherche') plus the exact resources covered: FR, EP, WO patent applications and CCPs, in the INPI database. The enumeration of searchable fields further pins down scope. It does not name the sibling fiche_brevet to distinguish list-vs-detail, so it stops short of a 5.

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?

'Les critères se cumulent' tells the agent filters combine as AND, which is real usage guidance, and the field list implies which queries are possible. But there is no explicit when-to-use / when-not / alternative routing, e.g. that fiche_brevet should be used once a number is known or that an empty result should be broadened.

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=true and openWorldHint=true, so safety is covered. The description adds value beyond that by disclosing the return content (SIREN, forme juridique, siège) and the substring matching behavior, which an agent needs to interpret results; only pagination semantics are left to 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?

Two tight sentences with zero filler; the search scope and matching mode are front-loaded before the filter and return details.

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 responsibly names the returned fields, and the schema covers defaults and limits for paging. Only the search-vs-detail routing relative to fiche_entreprise is missing, which is a minor gap for a straightforward lookup 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 description coverage is 100%, so both the required denomination and the postal-code/page/size parameters are already documented with patterns and bounds. The description's note that matching is « contient » and the postal code acts as a filter adds only marginal meaning, so baseline 3 applies.

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 (recherche d'entreprises dans le RNE) plus the matching mode (« contient ») and the optional filter. It is clearly a search tool, distinguishable from the fiche_* detail siblings, though no sibling is named explicitly.

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: search by name fragment, optionally narrowed by postal code. But it never states when to prefer it over fiche_entreprise or what happens when a search returns an ambiguous list — the agent must infer the search-then-detail workflow.

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=true and openWorldHint=true, so the description need not carry the full safety burden. It adds useful behavior: criteria are cumulative, and results are returned as a paginated list, with fiche_marque recommended for detail.

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 tightly written sentences with no waste. The primary search scope is front-loaded, followed by the cumulative-criteria behavior and the follow-up detail 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?

For a 14-parameter search tool with 100% schema coverage, the description plus annotations and schema are enough to call it correctly. It states pagination and the fiche_marque handoff, though it does not describe returned fields or rate-limit behavior.

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 all 14 parameters are already documented in detail. The description summarizes the main criteria categories but adds little per-parameter meaning beyond what the 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 verb and resource: searching French, EU, and international trademarks in the INPI database. It also names supported criteria and explicitly routes detail requests to fiche_marque, distinguishing it from the detail sibling.

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 clearly indicates this tool is for searching and that fiche_marque should be used afterward for detail. It does not spell out when not to use it or compare it with the other recherche_* siblings, but the resource scope makes those alternatives clear.

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=true and openWorldHint=true, so the safety profile is covered. The description adds the source scope (INPI, FR and WO collections) but says nothing about pagination behavior, result ordering, or what a result record contains.

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?

One front-loaded sentence naming the action and source, followed by a compact field enumeration. Every element earns its place, though the trailing list is close to restating the schema.

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 17-parameter search tool with no output schema, the definition covers what can be searched but not what comes back or how results are paged/ordered. Annotations and the rich schema carry most of the load, but the return-value gap remains notable given no output schema exists.

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 all 17 parameters are already documented in the schema, including defaults, ranges, and date formats. The description's field list mirrors the parameter names without adding syntax or usage detail beyond the schema.

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 (Recherche) plus resource (dessins et modèles) and scopes it to the INPI FR/WO collections. The enumerated searchable fields make it clearly distinct from sibling tools like rechercher_marques or rechercher_brevets.

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 search intent is implied by the verb and field list, but there is no explicit when-to-use guidance, no mention of when to prefer this over fiche_modele, and no note about using requete_avancee for cases the structured filters don't cover.

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 declare readOnlyHint=false with destructiveHint=false and idempotentHint=true; the description usefully explains that gap by disclosing the real side effect — a PDF written into the configured download folder via INPI_DOSSIER_TELECHARGEMENTS — and that the file path is returned. It stops short of stating prerequisites (API credentials, directory existence), overwrite behaviour, or failure modes for unavailable documents.

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, both earning their place: the first states the action, source, and destination; the second states the return value. Front-loaded and free of preamble or repetition of structured fields.

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 tool with no output schema, the description covers the action, the persistent side effect, the destination configuration, and the return shape (file path). What is missing is modest but real: access prerequisites and behaviour when the document is unavailable or the file already exists.

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 100%, so each parameter already carries its own description, including the enum values for 'type' and the pointer to lister_documents_entreprise for 'identifiant'. The description adds only that the content is 'un acte ou des comptes annuels déposés au RNE', which is minor reinforcement rather than new semantics.

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 names a specific verb and resource set: downloading in PDF an 'acte' or annual accounts filed with the RNE, plus saving it locally. This is clearly distinguishable from the sibling 'lister_documents_entreprise' (which enumerates rather than fetches content). The parenthetical file-path outcome further pins down what the tool delivers.

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?

Usage is implied rather than stated: an agent infers this is the retrieval step after obtaining a document identifier, and the schema's 'identifiant' description points to lister_documents_entreprise. However, the description itself offers no explicit when-to-use, when-not-to-use, or named alternative for choosing between downloading and merely listing documents.

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=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context: it depends on a configured data.inpi.fr account and checks access across two API families. It does not describe failure behavior or return format, but the added context is meaningful.

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 tight sentences with no waste. The core purpose is front-loaded, followed immediately by the key usage instruction.

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 no-parameter diagnostic tool with annotations covering read-only and open-world behavior, the description is nearly complete. It could say more about what the result looks like, but the purpose and usage are sufficiently clear without an output schema.

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 there are no parameter semantics to explain. The baseline for a no-parameter tool is 4, and the description does not need to compensate for any schema gaps.

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: it verifies which INPI accesses work using the configured data.inpi.fr account. It also enumerates the covered domains (trademarks, patents, designs, RNE), making it clearly distinct from the sibling search and record-lookup tools.

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 explicitly says to use this tool first in case of doubt or access error, which gives clear usage context. It does not name when not to use it or point to specific alternatives, but the diagnostic role is unambiguous.

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