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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the caveat about false negatives, which is useful behavioral context beyond the annotation. However, it does not disclose other behaviors like result limits or return format, so it adds only modest value.

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 with the core action front-loaded and the caveat following. No wasted words; every sentence earns its place.

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 read-only search with two simple parameters and no output schema, the description covers the essential behavior and a key caveat. However, it omits details like return format, pagination, or whether both title and DOI can be combined, which an agent might need 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 must compensate. It mentions 'exact title or DOI', clarifying that both parameters are search keys and that matching is exact. This adds meaning beyond the bare schema, but it does not explain parameter formats, defaults, or edge cases, so it only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for records ('notices') by exact title or DOI, which is a specific verb+resource. It implies a duplicate-checking purpose but does not explicitly differentiate from siblings like search_publications, so it loses a point for lack of sibling distinction.

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 a usage caveat ('no result does not guarantee absence of duplicates') but does not state when to use this tool versus alternatives. The context implies it is for duplicate verification, but no explicit when/when-not guidance is given.

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=true, and the description does not contradict that. The description adds useful behavioral detail like the max 100 rows and allowed formats, but it does not disclose output behavior or pagination. With the read-only annotation already covering safety, this is adequate but not rich.

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: one purpose line followed by a terse argument list. Every element adds value, including defaults and constraints, with no filler or redundant restatement.

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 low-complexity read-only export tool with an output schema present, the description covers all parameters and core behavior. It could mention when to use it or prerequisites, but given the annotations and output schema, the gap is minor.

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 carries parameter semantics. It explains query as search terms, enumerates fmt values with the default 'bibtex', and states rows max at 100. This compensates completely for the missing schema 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 opens with a specific verb ('Exporte') and a clear resource ('publications') plus the bibliographic formats (BibTeX, EndNote, CSV, TEI). This cleanly distinguishes it from sibling search/get/deposit tools, which involve different actions.

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 states the export use case but gives no guidance on when to prefer this tool over search_publications, get_publication, or other siblings. There are no explicit alternatives, exclusions, or contextual signals such as 'use this after searching'.

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, covering the safety profile. The description adds valuable behavioral context: it reveals the include_coauthors parameter returns frequency counts, explains the default sort order and its alternatives, and discloses the pagination limit. These are traits beyond the read-only flag and enrich the agent's understanding of the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: it leads with purpose, provides a brief narrative on the IdHAL benefit, includes a clear pagination pointer, and then lists parameters in a compact 'Args' block. Every sentence adds value; there is no fluff or redundancy, and the critical pagination note is front-loaded.

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 7 parameters, no schema descriptions, and an output schema available, the description is complete. It covers every parameter's meaning and usage, explains the pagination workaround, and does not need to detail return format since an output schema exists. No gaps that would hinder correct invocation remain.

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?

With schema description coverage at 0%, the description carries the entire burden of parameter explanation. It does so thoroughly: id_hal format is given as 'prenom-nom' with an example, year_from/year_to are marked as inclusive, doc_type lists valid examples, sort explains both options and default, rows notes the max of 100, and include_coauthors describes its output. This adds meaning far beyond the bare 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?

The description starts with a clear verb+resource: 'Récupère une page de la production d'un chercheur via son IdHAL'. It specifies the unique identifier and its purpose (avoiding homonyms, listing publications). It also differentiates itself from search_publications by explicitly naming it in the pagination context, making the tool's scope unmistakable.

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 guidance is explicit: it states when to use this tool (ideal for listing a person's publications) and provides a concrete alternative for pagination beyond 'rows' — 'search_publications(query='authIdHal_s:"prenom-nom"', start=...)' — with a specific query pattern. This gives clear when-to-use and when-to-switch 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?

The readOnlyHint annotation already marks the operation as safe, and the description adds meaningful behavioral context beyond it, notably that passwords returned by HAL are filtered. The status mapping also clarifies that the tool exposes authenticated SWORD lifecycle states rather than raw data.

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 each sentence carries a distinct piece of information: the status mapping and the password-filtering behavior. The status legend is front-loaded and easy to scan, though the opening phrase 'Statut SWORD authentifié' is slightly ambiguous.

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 with no output schema, the status mapping gives useful response semantics and readOnlyHint covers the safety profile. However, the description omits a clear statement of the tool's function, parameter meaning, and the exact response format, leaving notable gaps for the agent to infer.

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%, and the description makes no mention of hal_id or environment. It does not explain that hal_id identifies the deposit or how preprod versus production affects the response, so the agent must infer parameter meaning entirely from names and defaults.

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 provides a useful status-code legend ('accept=en ligne, verify=validation, update=corrections, delete=refus') and identifies the SWORD domain, but it never states the action with a specific verb such as 'retrieves' or 'returns.' It also does not differentiate this from siblings like inspect_deposit or validate_deposit, so the agent must lean on the tool name for core purpose.

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 guidance on when to use this tool versus alternatives; siblings like inspect_deposit could plausibly also report deposit status. The description neither states prerequisites nor gives when-not-to-use conditions, leaving usage context entirely implicit.

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 the description adds the context that it returns a 'proposition' (proposal) and performs no deposit. This is consistent with the read-only nature and adds a small behavioral nuance, but the description does not disclose error handling, format details, or any limitations beyond the annotation. The bar is lower due to annotations, and the description provides some value 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?

The description is extremely concise, consisting of two short phrases. It front-loads the purpose and includes the key distinguishing factor ('Aucun dépôt'). Every word earns its place with no redundancy or unnecessary detail.

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

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

Given the tool's simplicity (one parameter, no output schema, read-only annotation), the description provides the core purpose and a distinguishing feature. However, it does not describe the return value's structure, possible failure modes (e.g., invalid DOI), or whether the metadata is complete. While adequate for a basic tool, it could be more complete for an agent to confidently call it in complex workflows.

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%, and the description does not mention the 'doi' parameter at all. While the parameter is self-explanatory (a DOI string), the description fails to add any meaning beyond the schema field name. For a tool with a single parameter and 0% coverage, the description should compensate, but it does not, leaving the agent to infer that the DOI is a standard Crossref DOI.

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 ('Récupérer') and resource ('proposition de métadonnées Crossref à partir du DOI'), and explicitly notes 'Aucun dépôt' to distinguish it from deposit-related siblings. This allows an agent to immediately understand what the tool does and how it differs from submit/validate deposit 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?

The phrase 'Aucun dépôt' provides a clear exclusion (when not to use), but the description does not explicitly state when to use this tool versus alternatives. The intended use case (retrieving metadata before deposit) is implied by the tool name and sibling context, but not explicitly spelled out, so it falls short of a 4 or 5.

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, so the description need not repeat safety. It adds useful context about what is fetched and the identifier format, but does not discuss not-found behavior, permissions, or response specifics. This is acceptable but not rich.

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, front-loaded sentences: the purpose comes firstchen, then the argument explanation. No filler or 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?

For a single-parameter read-only lookup tool with an output schema already present, the description is complete enough. It tells the agent what to pass and what outcome to expect.

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 naming the parameter and providing concrete valid formats ('hal-00001234' or 'tel-00987654'). This adds meaning beyond the bare schema, though not exhaustive.

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 uses a specific verb ('Récupère') and resource ('fiche détaillée d'une publication') plus a precise lookup key (HAL identifier), distinguishing it from sibling tools like search_publications or get_publication_stats. The example identifier formats further clarify the intended input.

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 usage context is clearly implied: use this when you already have a HAL ID and need the detailed record. It does not explicitly name alternatives or exclusion criteria, but given the one-parameter design and sibling names, the intended use is evident.

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, so the description need not state it is read-only. The description adds that it returns counts per facet and lists valid group_by values, which is useful context. It does not describe output structure or potential limits, but given the annotation coverage, a 3 is appropriate.

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 and well-structured: a one-sentence summary, a use-case list, and a clear Args section. No superfluous content; every sentence earns its place.

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 tool is simple with only two parameters, and an output schema exists, so the description need not detail return values. It covers purpose, parameters, and usage context adequately. A minor gap is the lack of any mention of result ordering or limits, but overall it is complete for the tool's scope.

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 explain the parameters. It clearly defines query as search terms defining the set to analyze and group_by with allowed values ('annee', 'type', 'motscles', 'auteur'). This fully compensates for the sparse schema, providing meaning beyond the bare field 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 provides aggregated statistics on publications (counts by facet) and lists concrete use cases (lab production by year, document type distribution, dominant keywords, top authors on a theme). This distinguishes it from sibling tools like search_publications or get_publication, which focus on individual records or searches.

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 includes a 'Utile pour' section that gives explicit use cases, making it clear when to call this tool. However, it does not explicitly state when not to use it or name alternative tools for other scenarios. It provides context but lacks exclusion criteria.

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 description does not contradict the readOnlyHint annotation; actually, 'Relire' (re-read) aligns with a read-only operation. It goes beyond the annotation by specifying what is read: 'brouillon exact, son empreinte, son test et le journal d'envoi' (the exact draft, its fingerprint, its test, and the sending log). This provides useful context about the type of data involved, but it is not exhaustive. With the annotation covering read-only behavior, the description adds detail on the outputs, which is a plus.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence in French, which is concise and front-loaded with the purpose. It is efficient with no wasted words. However, it is in French, which might be appropriate if the system expects French, but it could be a barrier for English-based agents. Still, length is appropriate and structure is clear.

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 description is a single sentence in French, which is concise and front-loaded with the purpose. It is efficient with no wasted words. However, it is in French, which might be appropriate if the system expects French, but it could be a barrier for English-based agents. Still, length is appropriate and structure is clear.

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 only one parameter, draft_id, with no description, and the schema description coverage is 0%. The description does not mention draft_id at all, so it does not add any meaning to that parameter. However, with only one parameter and a clear name 'draft_id', the agent can infer it's an identifier for the draft. Since the parameter is obvious, a baseline of 3 is appropriate because the schema itself is minimal and the description doesn't hinder understanding.

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 is a French sentence: 'Relire le brouillon exact, son empreinte, son test et le journal d'envoi.' Translated, it means 'Re-read the exact draft, its fingerprint, its test, and the sending journal.' It uses a specific verb ('Relire' - re-read) and resource ('brouillon' - draft). It indicates the tool inspects a draft, which is distinct from validate, submit, etc. However, it is vague about what 'inspect' entails and does not clearly name the action in English or connect to the tool's name. It could be interpreted as just viewing the draft, but the mention of fingerprint, test, and sending log clarifies it's an inspection of those artifacts. Still, the purpose is not fully clear because it doesn't state what the output is or the exact scope.

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 siblings like validate_deposit or prepare_deposit. The description implies it's for checking a draft before submission, but does not state when to inspect versus when to validate. Given the context of sibling tools (validate, submit, prepare), it would be helpful to specify that this is for reviewing the exact state before actions like validate or submit, but this is missing.

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 provided, the description carries the full behavioral burden and does so well. It discloses that the tool creates a local immutable draft, makes no network calls, does not invent licenses, and that metadata_update is a full replacement rather than a patch. These are meaningful behavioral traits beyond what the schema could express.

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 efficient: it front-loads the core purpose, then adds workflow preconditions, operation semantics, and a key behavioral constraint ('Aucun appel réseau') without filler. Every sentence contributes information needed to invoke the tool correctly.

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 complex tool with nested publication metadata and no output schema, the description is unusually complete: it states preconditions, operation-specific behavior, no-network behavior, and the required user-facing step before submission. It does not explicitly mention validate_deposit in the workflow or describe the returned draft structure, but the absence is minor given how clearly the tool's role is scoped.

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 adds real meaning to operation, pdf_path, target, license_url, and structure_ids. Portal and environment are not explained, but their enum values and defaults make them largely self-explanatory, so the description covers the parameters that genuinely need semantic clarification.

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 opens with a specific verb and resource: 'Créer un brouillon local immuable ART/COMM' (create an immutable local ART/COMM draft). It clearly differentiates this from siblings by framing it as the local preparation step before submit_deposit, and it explicitly defines the three operation modes. An agent can tell what this tool does and how it relates to the deposit workflow.

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 actionable workflow guidance: resolve structure_ids in AuréHAL before preparing, verify check_duplicates, and present the full result to the user before submit_deposit. It also explains when each operation variant applies. It does not explicitly mention validate_deposit as an alternative or state when not to use this tool, so it falls just short of full routing 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?

With readOnlyHint already declaring the operation safe, the description adds useful behavioral context: filtering to open access or file-only deposits, a row maximum of 100, pagination via start, portal case sensitivity, and default sort behavior. It does not describe error or rate behavior, but the output schema covers the 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?

The description is front-loaded with a clear purpose line, followed by a compact Args block where each parameter gets one terse, informative line. There is no filler, repetition, or unnecessary nuance; every sentence earns its place given the tool's 10 parameters.

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 search tool with 10 parameters, zero schema-level parameter descriptions, and an output schema, the description is remarkably complete. It documents all parameter semantics, defaults, limits, pagination, and filtering behavior, while the readOnlyHint and output schema cover safety and return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full parameter-documentation burden. It explains every one of the 10 parameters with concrete meaning, inclusive year ranges, accepted doc_type values, sort options, max rows, pagination offset, and portal case conventions. This goes well beyond the bare schema names and defaults.

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 opens with a specific verb and resource: 'Recherche des publications dans l'archive ouverte HAL.' This clearly identifies the tool as a publication search on HAL and distinguishes it from structure or reference search siblings. However, it does not explicitly differentiate it from get_publication or explain that it returns multiple results rather than one record.

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 detailed parameter list implies the tool is used for criteria-based publication search, but the description does not state when to prefer it over siblings such as search_references or get_publication. There is no explicit when-to-use, when-not-to-use, or alternative routing, so usage guidance is only implicit.

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 provide readOnlyHint=true, covering the safety profile. The description adds a note about Solr syntax and a cryptic instruction to check valid_s and affiliation dates, which hints at filtering or validation steps but remains vague. It does not disclose return format, pagination, or any other behavioral details, but given the annotation, a 3 is reasonable for the minimal extra 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 concise (two sentences) and front-loaded with the action, but the second sentence is cryptic and unstructured. 'Vérifier valid_s et les dates des affiliations' is ambiguous and adds little clarity. It is appropriately short but not well organized for agent comprehension.

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 tool has 3 parameters, no output schema, and no enums, so the description is the only source of context. It fails to explain the purpose of the 'kind' parameter, how 'rows' works, or what the output contains. The hint about valid_s and dates is too vague to be actionable. This is incomplete for an agent to call 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 explains that the query parameter accepts Solr syntax, but it does not explain the 'kind' parameter at all, nor does it mention the 'rows' parameter. The list of facets is not explicitly linked to parameters, leaving two of three parameters under-documented. This is a significant gap.

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 (Rechercher dans AuréHAL) and lists the searchable facets (author, structure, domain, journal, doctype, instance), giving a specific resource and scope. It avoids tautology and distinguishes itself from a generic 'search' by naming multiple fields, though it does not explicitly differentiate from sibling tools like search_publications or search_structures.

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 guidance on when to use this tool versus alternatives. It mentions that query accepts Solr syntax and hints at checking valid_s and dates, but provides no context for when to prefer this over search_publications or search_structures. No exclusions or alternative conditions are given.

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 readOnlyHint annotation already indicates a safe read operation daten The description adds useful behavioral context: the search targets HAL structures and rows is capped at 50 results. No mutation, auth, or unexpected side effects are implied.

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 short, front-loaded with the purpose, and uses a structured Args section for parameter details. Every sentence adds value with no redundant phrasing.

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 search tool with two parameters and an output schema, the description covers the search scope, parameter semantics, valid examples, and result limit. Nothing essential is left unexplained for an agent to 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?

Input schema description coverage is 0%, so the description fully compensates. It explains that query accepts names or acronyms with examples like 'LIP6' and 'physique quantique', and rows means number of results with a max of 50. This goes well beyond the bare schema definitions.

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 and resource: search for a laboratory or research structure in HAL. It distinguishes itself from sibling tools like search_publications and search_references by naming the target entity type.

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 makes clear that this tool is for finding structures/laboratories, which gives an agent context for when to choose it over publication or reference search tools. It does not explicitly list exclusions or alternative tool names, but the context is unambiguous.

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 indicate destructiveHint=true and idempotentHint=false. The description adds behavioral context beyond annotations: it states that an attempt is logged and cannot be replayed automatically, and that production requires HAL_ALLOW_PRODUCTION=1. It also implies a one-shot, non-reversible action. This enriches the agent's understanding of side effects and constraints without contradicting the 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 a compact block of text, front-loaded with the core purpose ('REAL SUBMISSION'). It is not overly verbose and each sentence adds relevant information (when to call, prerequisites, environment, logging). The structure is logical and efficient, though it could be slightly more organized with bullet points for clarity.

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

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

Given the tool's destructive nature and lack of output schema, the description covers the essential operational context: when to invoke, what to provide, environment requirements, and the one-shot behavior. It does not describe the return value or post-submission status, but that is not critical for an agent to correctly invoke the tool. Overall, it is sufficiently complete for a destructive submission action.

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 explicitly mentions 'Provide the reviewed checksum' (mapping to expected_sha256) and 'confirm=true' (mapping to confirm). It does not explain draft_id, but that is self-explanatory. It adds meaning to two of three parameters, but does not specify the exact format of the checksum or the implications of confirm=false. This is a partial but useful compensation for the missing schema 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 and resource: 'REAL SUBMISSION of the tested draft.' It clearly distinguishes itself from siblings like validate_deposit and prepare_deposit by emphasizing that this is the actual submission step, not a validation or preparation step. The purpose is unambiguous.

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 explicitly states when to call: 'only on explicit user instruction after presentation of the file, authors/affiliations, license, and embargo.' It also lists prerequisites (provide checksum, confirm=true) and an environment requirement (HAL_ALLOW_PRODUCTION=1). It warns that an attempt is logged and cannot be replayed, which is crucial for an agent to avoid accidental double submission. This provides clear usage context and conditions.

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 provided, the description carries the full burden. It discloses that no deposit occurs ('sans dépôt'), that PDF and metadata are transmitted, and that environment credentials are required. This covers the most critical behavioral traits, though expected outcomes and response format remain unspecified.

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?

Three short sentences, each contributing distinct information: the test action, the transmitted payload, and the credential requirement plus sequencing. 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?

The description covers the core purpose, non-deposit behavior, and credential requirement, which is decent for a one-parameter tool. However, it leaves 'X-test: 1' undefined, does not explain the draft_id parameter, and gives no indication of expected result or error behavior, which is especially noticeable given the absence of 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 schema has 0% description coverage for draft_id, and the description does not explain what draft_id is or how to obtain it. It refers to 'PDF et métadonnées' and the package, but does not link these to the single required parameter, leaving the parameter's meaning to be inferred entirely from its name.

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: testing the package with HAL using X-test: 1, explicitly without depositing ('sans dépôt'). It also distinguishes itself from submit_deposit by positioning the tool as a pre-submission step, making it easy to tell apart from siblings.

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 'À effectuer avant submit_deposit' (to be done before submit_deposit), which gives clear timing relative to the main sibling. It does not mention when not to use the tool or alternatives like inspect_deposit, so some routing guidance is missing.

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