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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely new behavioral fact — that the operation is gated on the school permitting comments — but says nothing about failure behavior when comments are disabled or whether the comment is attributed to the caller.

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 zero filler; the action and its precondition come first, the validation requirement second. Every clause 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 two-parameter mutation with no output schema and annotations covering the safety profile, the description supplies the action, the authorization precondition, and a confirmation step. It falls short only on error/permission-denied behavior and on how the new comment is returned or identified.

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 50%: 'texte' is documented in the schema as plain text, while 'id' has no description at all. The phrase 'sous une actualité' weakly implies that id is the news-item identifier, but the description adds no format, type, or validity detail beyond that inference, so the baseline of 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 pair ('Publie un commentaire sous une actualité'), which cleanly separates it from actualites_lire and actualites_lister. It does not name or contrast with the analogous sibling blog_commenter, so sibling differentiation is only 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 'si l'école autorise les commentaires' gives a real applicability precondition, and 'Faire valider le texte par l'utilisateur' prescribes a workflow step. However, no alternatives (e.g. blog_commenter for blogs) or explicit when-not guidance are offered, leaving usage largely implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful structural fact that feeds are scoped one per school or theme, but says nothing about the shape of a feed entry or whether results are paginated.

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 short sentence with the resource stated first and its scoping qualifier second; no filler. It is arguably too terse rather than padded, so the brevity is not the problem.

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 list tool, the description is minimally sufficient, and annotations cover the read-only nature. Still missing is any hint of what distinguishes this feed enumeration from actualites_lister, which matters in a sibling set this dense.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The parenthetical about school/theme scoping is contextual rather than a parameter, which is fine here.

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 resource (news feeds) and clarifies its granularity ('un par école ou par thème'), so the agent knows it enumerates feeds rather than articles. However, it never distinguishes itself from siblings like actualites_lister or fil_nouveautes, which an agent could easily confuse with it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as actualites_lister or fil_nouveautes. The agent must infer from the name alone that this is the discovery step before reading articles.

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=false, so the safety profile is covered. The description adds that the result includes the article's comments ('avec ses commentaires'), which is useful return-content context not present in structured fields, but it says nothing about truncation or comment volume.

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 short sentence, front-loaded with the action and resource, with no padding or redundancy. Every element 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 single-parameter read tool whose annotations already carry the safety profile, the description covers what is retrieved (full article plus comments). With no output schema, a bit more on the returned shape would help, but nothing essential 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?

With a single parameter at 100% schema description coverage, the schema fully documents the numeric article identifier. The description adds no additional syntax or format guidance, so the baseline 3 is appropriate.

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 gives a specific verb ('Lit') and resource ('actualité') plus a scope qualifier ('en entier, avec ses commentaires'), which distinguishes it from list/feed siblings like actualites_lister and actualites_fils. It stops short of naming those siblings explicitly, so it is clear but not maximally differentiating.

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: read one news item in full. There is no statement of when to prefer this over actualites_lister or actualites_fils, and no preconditions or exclusions. Adequate but leaves routing to inference.

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=false, so the safety profile is covered. The description usefully signals recency ('Dernières') and the kind of content returned, but says nothing about pagination behavior, ordering guarantees, or how many items come back — gaps the schema only partly fills.

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 compact sentence with zero filler, front-loading the resource and its scope. It is a noun phrase rather than a full statement of action, but nothing in it 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 simple read-only, three-parameter listing tool with safety already covered by annotations and no output schema, the description is minimally adequate. It omits pagination/return-volume context and any routing signal toward sibling tools, which would help an agent decide between this and actualites_lire or actualites_fils.

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 67%: fil_id and taille are documented in the schema (including a cross-reference to actualites_fils), while page is undocumented everywhere. The description adds no parameter-level meaning at all, so it neither compensates for the page gap nor improves on 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 specific resource ('Dernières actualités publiées par l'école') and even enumerates content types (sorties, réunions, informations générales), so an agent knows what the tool returns. It does not, however, distinguish it from siblings like actualites_lire (read one item) or actualites_fils (threads), leaving the boundary 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?

There is no explicit when-to-use guidance: nothing says to call this to browse news versus actualites_lire for a single article or actualites_fils for thread lists. The word 'Dernières' weakly implies a recency-ordered browse, but no alternatives or conditions are named.

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=false, covering the safety profile. The description adds only that it returns public information; it does not disclose auth needs, rate limits, or other behavioral traits. With annotations present, 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?

A single, front-loaded sentence with no filler. Every element (detailed, person, function, establishments, public information) contributes useful information. Nothing 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 simple one-parameter read-only tool, the description conveys the return content (role, establishments, public info) and annotations cover safety. Missing usage guidance is a minor gap, but the definition is otherwise sufficient 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 100%, and the single id parameter is fully documented in the schema. The description does not mention the id or its expected format, so it adds no meaning beyond what the schema already provides. 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?

The description states it returns a detailed directory record for a person, listing function, establishments, and public information. The verb 'retrieve' is implicit, but the resource and scope are clear. It implicitly distinguishes itself from the sibling annuaire_rechercher (search) by being a detailed fiche.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use, prerequisites, or alternatives are mentioned. The agent must infer that this is for fetching details after obtaining an id, likely from annuaire_rechercher. There is no explicit guidance on context 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: results are permission-filtered to contacts the user may reach, and the payload is identifiers intended to feed a messaging call. It still omits pagination or result-size behavior, keeping 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?

Two sentences, front-loaded with the action verb, and both carry weight — one defines scope, the other defines the return intent. The parenthetical contact list is a slight expansion but usefully bounds the scope rather than padding.

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 with no output schema, the description covers purpose, scope, and what comes back (identifiers for messaging) plus the permission boundary. Nothing critical for correct invocation is missing, though pagination/output shape is left implicit.

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 the single 'recherche' parameter is fully documented in the schema (name, class, function, empty = all). The description adds no query-syntax or matching details beyond what the schema already provides, 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 (Recherche) plus resource (annuaire) and narrows scope to people and groups the caller is authorized to contact, with examples of contact types. It also names the outcome (identifiers for sending a message), which separates it from siblings like annuaire_fiche and the messagerie_* family.

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 context is implied: the reader infers this is the lookup step before composing a message. However, there is no explicit when-to-use/when-not guidance and no mention of annuaire_fiche as the detail-lookup alternative, so routing between the two directory tools must be guessed.

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=false, so safety is covered. The description adds two real behavioral facts beyond the annotations: results are ordered newest-first and include post content, which helps the agent anticipate the payload. It does not describe pagination behavior or result limits.

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 with no filler; sorting and payload hints are packed in efficiently. It is arguably too terse given the undocumented parameters, but as pure conciseness it is strong.

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 two-parameter read tool with no output schema, the description covers what is returned (posts with content) but omits pagination semantics and the required blog_id's role. Annotations cover the safety profile, so the gap is moderate rather than severe.

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 burden, yet it says nothing about either parameter. The meaning of blog_id (format/source) and the paging semantics of page (with its default of 0 and apparent lack of a page-size parameter) are left entirely 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 names a specific resource (published posts of a blog) and adds scope detail (newest-to-oldest order, content included), which distinguishes it from sibling blog_commentaires (comments) and blog_lister (blog list). However, it never states an explicit retrieval verb, so it reads as a description of data rather than an action.

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 when-to-use guidance, no prerequisite (e.g. needing a blog_id), and no mention of any alternative tool such as blog_commentaires for the comments attached to these posts. The agent must infer usage entirely from the name.

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=false, so the safety profile is covered. The description adds nothing beyond that: no ordering, pagination, whether comments are threaded or flat, or whether the caller needs access to the blog. It restates the resource and stops.

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 five-word sentence with no filler and a front-loaded resource, so there is nothing to trim. However, the brevity is under-specification rather than discipline — it is concise at the cost of being informative.

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, so the description is the only place that could tell an agent what a 'commentaires' result looks like (author, body, timestamp, threading), and it says nothing. Combined with undocumented required parameters, the definition is too thin 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% and both parameters are required, yet the description explains neither blog_id nor billet_id — it only echoes 'billet de blog'. The parameter names are somewhat self-describing, which keeps this above a 1, but with zero schema documentation the description should have compensated and does not.

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 identifies the resource (a blog post's comments) and, combined with the readOnlyHint, an agent can infer a retrieval operation. But it is a bare noun phrase with no verb (list/get/fetch), so the action itself is only implied, and it makes no attempt to distinguish itself from the near-named siblings blog_commenter and blog_supprimer_commentaire.

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 when-to-use guidance at all: no mention of alternatives (blog_billets for posts, blog_commenter for writing comments), no preconditions, no note on when this tool is appropriate versus sibling blog tools. The only usable signal comes from the name and annotations, not the description.

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

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false, and destructive=false, so the safety profile is covered. The description adds one useful behavioral rule beyond annotations – requiring user validation of the text – but says nothing about effects, errors, or return 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?

Two short, front-loaded sentences with no wasted text; the core action leads. It is efficient, though arguably too terse given the parameter gaps.

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 write tool with annotations covering safety and no output schema, the description is minimally adequate but omits how to obtain blog_id/billet_id and any error or confirmation details. The 50% parameter coverage gap is not compensated.

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 only 50%: 'texte' and 'en_reponse_a' are documented, but blog_id and billet_id have no description anywhere. The description adds no parameter meaning at all, leaving the two identifier 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+resource: 'Publie un commentaire sous un billet de blog' (publishes a comment under a blog post). This distinguishes it from siblings like blog_supprimer_commentaire and blog_commentaires, though it does not explicitly name them or clarify against actualites_commenter.

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?

'Faire valider le texte par l'utilisateur' gives a workflow instruction (get user approval before publishing) but no explicit when-to-use/when-not guidance or alternatives relative to sibling comment tools. Usage is implied rather than specified.

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=false, so safety is covered. The description adds only the scoping notion of 'accessibles' (blogs the user can reach), but says nothing about ordering, pagination, or what identifies each returned blog.

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 short fragment with no padding. It is appropriately sized, though the parenthetical examples ('blogs de classe, d'école…') add marginal value over just 'blogs accessibles'.

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 parameterless list tool with annotations covering safety, the description is minimally adequate but omits scope detail an agent would want — what qualifies as 'accessible' and what the listing returns.

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 takes zero parameters, so the schema baseline of 4 applies; there is nothing for the description to clarify.

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 the resource ('blogs') and implies listing via the tool name, but the description itself contains no verb and gives only a fragment ('Blogs accessibles'). It does not distinguish this listing tool from sibling blog tools (blog_billets, blog_commentaires) except through the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use this tool versus alternatives, no prerequisites, and no mention of how to proceed afterward (e.g., to read a blog's posts via blog_billets).

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation profile is covered. The description adds one useful behavioral detail beyond annotations: that only the caller's own comment is deleted. It says nothing about reversibility, effects on replies, or confirmation 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?

A single efficient sentence with the action and resource front-loaded and no filler. It is appropriately sized, if minimal.

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 destructive three-parameter tool with zero parameter documentation and no output schema, the description is too thin. It omits ownership requirements, error behavior, and any indication of what a successful deletion returns or whether it can be undone.

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 none of the three required parameters (blog_id, billet_id, commentaire_id) are documented in the description. The parameter names are largely self-explanatory, but the description does nothing to compensate for the coverage 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 states a specific verb (supprime) and resource (commentaire sur un billet de blog) with the scope qualifier 'un de vos'. It is clear what the tool does, though it does not explicitly distinguish itself from sibling read/list tools like blog_commentaires or blog_commenter.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The phrase 'un de vos commentaires' hints at an ownership restriction but does not state it as a rule or explain what happens when the comment is not yours.

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=false, so the safety profile is covered. The description adds genuine behavioral value beyond that by disclosing the shape of the result: day-by-day entries with each work's identifier and whether it is marked done. No output schema exists, so this return-content disclosure 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?

A single front-loaded sentence that states the resource first, then the scope, then the per-item payload. It is dense but earns its length by conveying both scope and return content.

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 tool with no output schema, the description covers the resource, optional date filtering, and the essential return shape. It omits only minor details such as ordering or handling of empty date bounds, which the schema's 67% coverage partly absorbs.

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 67%: "id" is well described, and depuis/jusqu_au carry format (AAAA-MM-JJ) documentation in the schema. The description's contribution is limited to signalling that the date range is optional ("éventuellement"), which partially overlaps the schema's default:null. Baseline 3 is appropriate.

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 clear verb+resource ("Lit un cahier de texte") and specifies the scope of what is returned (work per day, optional date range, identifier and done-status per item). It is distinguishable from siblings like cahier_lister and cahier_marquer, though it never names those alternatives directly.

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 guidance and no mention of alternative tools such as cahier_lister (listing notebooks) or cahier_marquer. The phrase "éventuellement entre deux dates" hints at the optional filter but frames a parameter, not a tool-selection rule.

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=false, so the safety profile is covered. The description adds only the scope qualifier "accessibles"; it says nothing about result volume, ordering, pagination, or what happens when no cahiers are available. With annotations carrying the main burden, this is adequate but thin.

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 short sentence that front-loads the verb and resource with no filler. Nothing could be trimmed without losing meaning.

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, read-only listing tool with no output schema, the description covers the essentials but does not indicate what the listing returns (e.g., a collection of cahiers with their identifiers) or how to proceed afterward (cahier_lire). It is minimally sufficient rather than complete.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies a no-argument listing operation.

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 ("cahiers de texte"), with a parenthetical gloss ("devoirs et travail à faire") that clarifies what a cahier de texte contains. It is clearly distinguishable from the write-oriented siblings cahier_marquer and the single-item cahier_lire, though it never names them 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?

"accessibles" hints at the scope of the listing, implicitly contrasting with reading a single cahier via cahier_lire, but the description gives no explicit when-to-use/when-not guidance or prerequisite conditions. Usage is inferable but not stated.

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 carry the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description's added value here is the checkbox-style toggling behavior, which is a modest disclosure. It does not state permissions required, what happens to items not listed, or any partial-success behavior on a mutation tool.

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, each earning its place: the first defines the action and its semantics, the second gives the ID source. No padding or repetition of the tool name.

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 3-required-parameter mutation with no output schema and annotations covering safety, the description is nearly complete — the ID provenance and toggle semantics are the key missing pieces and the ID provenance is supplied. Only the etat value mismatch and absence of auth/failure context leave a small gap.

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?

Description adds one real semantic hint — travaux ids originate from cahier_lire — but does not name or map the etat values precisely: it says 'fait (ou à refaire)' while the schema enum only offers 'fait' and 'a_faire', a naming mismatch that could confuse an agent. With 33% schema coverage, the description partially but not fully 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?

States a specific verb (marquer) and resource (travaux du cahier de texte) plus the effect (faits / à refaire), which is clear enough for an agent to distinguish this mutation from read siblings like cahier_lire and cahier_lister. The checkbox analogy reinforces the intent, though the purpose is not differentiated from any other mark/toggle tool 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?

It supplies one actionable prerequisite — that the identifiers come from cahier_lire — which is genuinely useful routing information. However, it states no when-to-use condition, no when-not-to-use, and no alternative to this mutation, so guidance remains 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 openWorldHint=false, so the safety profile is covered. The description adds the optional date-scoping behavior, but says nothing about pagination, ordering, or result volume for a listing tool that could return many events.

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 that covers resource, examples, and the optional filter with no filler. The word 'éventuellement' is slightly vague but costs almost nothing in length.

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 listing tool with full schema coverage and no output schema, the essentials are present. Still, it never hints at what an event entry contains or how results are scoped/limited, so it is adequate but not fully self-sufficient.

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%: depuis, jusqu_au and calendrier_id are each documented in-schema, including the 'Absent = tous les calendriers' default. The description's date-range clause merely echoes the schema, adding no format or boundary semantics beyond it.

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 concrete resource ('Événements des calendriers') and gives concrete examples (réunions, sorties, vacances), so an agent knows it retrieves calendar events rather than calendars themselves. It is distinguishable from the sibling calendrier_lister by resource, though it never names that sibling 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?

'éventuellement entre deux dates' implies the date filter is optional, which is real usage guidance for the temporal scope. However, there is no explicit when-to-use vs calendrier_lister (which lists calendars) and no stated prerequisites or exclusions, leaving the choice to inference.

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=false, so the safety profile is covered by structured data. The description adds the useful scope detail that the returned set is the user's accessible calendars rather than arbitrary ones, but says nothing about ordering, count, 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?

A single front-loaded sentence with no filler; the examples are parenthetical and compact. It is appropriately sized for a simple list tool, though extremely terse.

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, read-only list tool with no output schema, the description conveys what the call returns (accessible calendars, with the categories exemplified), which is the main thing an agent needs. Missing only return-order/format nuance, which is minor here.

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 takes zero parameters, so there are no parameter semantics to explain; the baseline for a no-parameter tool applies. Nothing in the description conflicts with the empty 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 names a specific resource — the calendars the user can access — and its examples (school, class, personal) clarify the kind of data returned. It implies a listing operation via its name and content, and is naturally distinct from calendrier_evenements, though it never explicitly names that 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?

There is no when-to-use guidance, no prerequisites, and no mention of the alternative tool for reading events inside a calendar (calendrier_evenements). The agent must infer routing from the tool name alone.

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=false, so the safety profile is covered. The description usefully adds that results are ordered newest-to-oldest and include signature status and existing replies, but it says nothing about pagination, total counts, or how many entries come back despite exposing a page parameter.

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 compact sentence with no filler, and the resource is front-loaded. Efficient, though the parenthetical ordering detail could be integrated more cleanly.

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 annotated read-only list with no output schema, the description conveys what the entries contain and their ordering, which is the core of what an agent needs. It stops short of covering pagination/result-set size, which is the main remaining gap for a paged listing 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 50%: enfant_id is documented in the schema and page is not. The description adds no parameter-level meaning at all, so the undocumented page parameter is not compensated for anywhere, and even the enfant_id scope is only clarified by the schema, not the description.

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 specific resource ('Mots du carnet de liaison') and adds scope details (ordered newest-to-oldest, includes signature status and existing replies), which distinguishes it clearly from the write siblings carnet_signer and carnet_repondre. It does not use an explicit list verb, but the ordering statement makes the read/listing behavior 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?

There is no explicit when-to-use statement and no alternative named. The agent can infer it is for reading the logbook, but nothing tells it how this relates to carnet_signer or carnet_repondre, nor when to prefer this over those. No prerequisites are stated.

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 the write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the safety profile is covered. The description adds behavior the annotations cannot convey: the action can fail if the entry does not accept replies, and the text must be user-validated before sending. It omits required permissions (parent vs. teacher) and any rate or moderation constraints.

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 zero filler, and the core action is front-loaded ahead of the conditional and the workflow caveat. Nothing could be removed without losing 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?

For a three-required-parameter mutation with no output schema, the description covers the precondition and the validation workflow but leaves one parameter (enfant_id) unexplained and says nothing about failure modes or what a successful send returns. Adequate as a minimum, but incomplete.

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 only 33%, so the description must carry more weight than it does. It gestures at 'texte' via the validation instruction and at mot_id via 'un mot du carnet', but it never clarifies that enfant_id identifies which child's carnet the entry belongs to, nor the expected format of the reply body. The $defs descriptions partially compensate, but the description itself adds little.

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 in French: it writes a reply to a 'mot du carnet de liaison', which is clearly distinct from carnet_lister (listing) and carnet_signer (signing). The parenthetical condition '(si le mot accepte les réponses)' adds useful scope. It does not name any sibling explicitly, so it lands at 4 rather than 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?

It specifies a precondition for use ('si le mot accepte les réponses') and a mandatory workflow step ('Faire valider le texte par l'utilisateur avant l'envoi'), which is real operational guidance. It stops short of naming alternatives (e.g. carnet_signer) or stating when not to reply, so it is clear context without 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=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the mutation/idempotency profile is covered. The description adds no behavioral context beyond the act itself: it doesn't say whether signing notifies a teacher, whether it can be undone, or what permissions are required.

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 with no filler. It is efficient, though the parenthetical could have been used for behavioral or parameter detail instead of restating the resource.

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 two-required-param mutation tool with no output schema and no permission or side-effect disclosure in annotations or description, the definition is thin. An agent knows what to call but not under what authority, with what side effects, or how failure modes behave.

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?

Although measured schema coverage is 0%, the $defs entries for MotId and UtilisateurId do define both referenced parameters. The description maps loosely onto them ('un mot', 'un enfant') but adds no id format, ownership, or validation detail beyond what the schema refs already convey.

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 gives a specific verb+resource ('Signe un mot du carnet de liaison') and clarifies what signing means via '(accusé de lecture)', so the action is unambiguous. It does not, however, differentiate from the nearby sibling carnet_repondre, which an agent could plausibly confuse with it.

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 when-to-use guidance, no prerequisites (e.g. that it requires an authenticated ENT session or a parent role), and no mention of the alternative carnet_repondre. The usage context must be inferred entirely from the tool name.

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 the mutation profile (readOnly=false, idempotent=false, destructive=false), so the bar is lower. The description adds genuinely new behavioral facts beyond the annotations: the 10 MB size limit, the base64 encoding requirement, and an explicit user-confirmation step before committing.

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

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

Two sentences, no filler, purpose front-loaded ahead of the constraint and the confirmation instruction. Slightly terse given the absence of any param-level detail for nom_fichier.

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?

There is no output schema, and the description covers encoding, size cap, and confirmation, which are the key operational facts for a deposit tool. It omits error/failure behavior and the meaning of nom_fichier, leaving small but real gaps for a multi-recipient write operation.

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 only 33% – nom_fichier and contenu_base64 are undocumented in the schema. The description compensates partially by stating the base64 format and 10 MB cap for the content, but adds nothing for nom_fichier, leaving one required parameter explained only by 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 pairs a specific verb ("Dépose") with a specific resource and destination ("un fichier ... dans le casier d'une ou plusieurs personnes"), which clearly separates it from casier_lister, casier_telecharger, and casier_supprimer. It does not explicitly name or contrast against the closest sibling, documents_deposer, so differentiation relies on the agent knowing the casier namespace.

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 second sentence prescribes a workflow step ("Faire valider le fichier et les destinataires par l'utilisateur"), giving implied usage context. However, it gives no when-to-use-vs-alternative guidance and does not clarify casier_deposer versus documents_deposer or messaging attachment 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds domain context that these are recipients eligible for file deposit, but it does not disclose return format, pagination, or other operational behavior beyond what the annotations provide.

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 short sentence with no wasted words, and it is front-loaded with the core resource definition. However, as a sentence fragment it lacks a clear action structure, which slightly weakens its usefulness.

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 tool with one optional filter and no output schema, the description is minimally adequate: the annotations and schema cover safety and filtering. The main gap is that it never explicitly states the tool returns a list, leaving the agent to infer the action from the name and 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 description coverage is 100% and there is only one optional parameter ('recherche'), which the schema fully documents as a name filter. The description does not mention or add meaning to this parameter, so the baseline of 3 is appropriate when the schema carries the full burden.

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 resource domain (people and groups eligible to receive a file in the casier), but it is a noun phrase without an action verb such as 'list' or 'retrieve'. It partially distinguishes from siblings like casier_deposer, but does not clearly state that this tool returns recipients.

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 alternatives such as casier_deposer or casier_lister. The phrase 'à qui vous pouvez déposer un fichier' implies a context, but the description does not state prerequisites, exclusions, or routing 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description contributes extra context by identifying the documents as ones received for your attention from a teacher or parent. It does not disclose return format, ordering, or pagination behavior, so it adds only moderate 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?

A single, compact sentence that front-loads the resource ('Fichiers reçus dans le casier') before the explanatory parenthetical. No filler or redundancy, though the sentence is short enough that structure is a minor factor.

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 read-only list tool with annotations already covering the safety hints, the description provides enough to know what is being listed and why. Return format details are not provided, but there is no output schema obligation to document them.

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 takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify beyond the resource itself. Schema coverage is 100%.

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 identifies the resource precisely — 'Fichiers reçus dans le casier' — and adds the source context ('documents déposés à votre intention par un enseignant ou un parent'), which helps an agent understand what the listing contains. The verb 'lister' comes from the tool name rather than the text, and it does not explicitly distinguish the output from siblings like casier_destinataires or documents_lister, 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?

Usage is implied by the read-only listing nature and the clarifying parenthetical about who deposited the documents. However, there is no explicit when-to-use statement, no prerequisites, and no routing to alternatives such as casier_destinataires or casier_telecharger, leaving gaps.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description does add one piece of context beyond the annotations: the operation is a soft-delete to the corbeille rather than permanent erasure. It says nothing more about restoration, permissions, or 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?

A single short sentence with no waste and the operation stated up front. It is terse to the point of under-specification rather than verbose, but structurally clean.

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 destructive tool whose annotations already disclose the safety profile, the description is barely adequate: it conveys the core action but omits the meaning of the id parameter and any note on recovery from the trash.

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 single required parameter "id" has 0% schema description coverage and is never explained in the description — it is unclear whether it identifies a file, a folder, or a recipient entry. With low coverage, the description was expected to compensate but does not.

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+resource in French: moving a casier file to the trash ("Met un fichier du casier à la corbeille"). This clearly separates it from casier_deposer (deposit) and casier_telecharger, though it never names those siblings 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no note about whether the action is reversible or requires specific rights. The agent must infer usage entirely from the name.

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=false, so safety is covered. The description usefully adds two behavioral facts beyond the annotations: the payload is returned as base64 and is capped at 10 Mo, which directly affects how the agent must handle the result and what inputs are viable.

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 short sentence that front-loads the action and appends the two constraints as a parenthetical. Nothing is wasted and nothing important is buried.

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 download with no output schema, the description covers the essential contract: what comes back (base64) and the size ceiling. The remaining gap is provenance of the id, but the tool is otherwise complete enough to invoke.

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 sole required parameter 'id' is a bare string with no documentation anywhere. The description never says this id identifies a casier file entry (presumably from casier_lister), leaving the agent to infer it. With one undocumented parameter, the description should compensate but does not.

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 (télécharge) and resource (un fichier du casier), so the agent immediately knows this is a file-retrieval tool for the casier store. It does not, however, distinguish itself from the sibling documents_telecharger or messagerie_telecharger_piece_jointe, which appear to do similar things for other stores.

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 versus documents_telecharger or how to obtain the required id. The scope (casier rather than documents or messagerie) is only implied by the name and the word 'casier' in the description.

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?

Adds meaningful behavior beyond the annotations: despite the name 'deconnexion', it logs out AND immediately re-authenticates with configured credentials. That re-login side effect is not implied by readOnlyHint=false or idempotentHint=true. It does not describe failure behavior if stored credentials are 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?

A single front-loaded sentence with the action first and the trigger condition after the colon. No filler; every clause carries 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?

For a zero-parameter, no-output-schema tool, the description covers what it does and when to invoke it. It omits what the caller should do if reconnection fails or how success is signaled, a minor gap.

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 takes zero parameters, so per the rubric the baseline is 4. There are no argument semantics to clarify, and the description correctly implies no inputs are needed.

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 compound action: closing the current ENT session and immediately reopening one with configured credentials. The verb+resource are precise, and no sibling tool touches session lifecycle, so differentiation is trivial.

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?

Gives an explicit trigger condition: 'to call when the ENT responds with a redirect or an expired session.' This tells the agent exactly when. It does not name a 'when-not' or alternative tool, keeping it just short of a 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=false, destructiveHint=false, openWorldHint=false, and idempotentHint=false. The description usefully adds the base64 encoding requirement and a 10 MB maximum size limit, which are not in the annotations. It does not explain duplicate/overwrite behavior, but the annotation bar is lower and the added constraints are valuable.

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 with no waste: verb, resource, encoding constraint, size limit, and destination are all packed efficiently.

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 three-parameter upload tool with annotations covering the safety profile and no output schema, the description provides the key missing constraints (base64, 10 MB max, destination). The only notable gap is the lack of naming conventions or duplicate-handling behavior for nom_fichier.

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 only 33% (only dossier_id is documented). The description adds meaning for contenu_base64 by specifying base64 encoding and a 10 MB maximum, partially compensating. However, nom_fichier receives no explanation, and dossier_id semantics are already in 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?

The description states a specific verb ("Dépose") and resource ("un fichier") plus the destination ("dans « Mes documents »"), making the operation clear. It does not explicitly distinguish itself from siblings like documents_lister or documents_telecharger, so it falls 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?

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The agent must infer that this is the upload action from the verb alone, with no routing context provided.

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=false, so safety is covered. The description adds the notable fact that the listing includes the trash (corbeille), which is useful behavioral context, but says nothing about pagination, ordering, or result 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?

A single compact sentence-fragment with the scope front-loaded and no filler. It is efficient, though the nominal phrasing ('Contenu de...') is less actionable than a verb-led phrasing would be.

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 listing tool with no output schema, the description omits any hint of return values, pagination, or result ordering, which an agent calling it would benefit from. Annotations carry the safety profile, but the informational side is thin.

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 50%; both parameters do carry descriptions (dossier_id: 'Dossier à ouvrir (absent = racine)'). The description's enumeration of the four spaces largely restates the espace enum rather than adding meaning, and it says nothing about dossier_id semantics, so it does not compensate for the coverage gap. Baseline 3.

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 resource (l'espace documentaire) and enumerates the four scopes it covers (mes documents, partagés, applications, corbeille), so an agent understands it retrieves documents from a space. It stops short of naming an explicit verb ('lister') and does not distinguish itself from siblings like documents_deposer or documents_telecharger.

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 parenthetical list of spaces hints at what can be browsed, but there is no explicit when-to-use statement, no mention of the alternatives (documents_deposer, documents_telecharger), and no prerequisites. An agent can infer this is the read/browse counterpart but must guess.

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 only declare readOnlyHint and openWorldHint; the description adds genuinely new behavioral context: the return is base64-encoded and the document is capped at 10 MB. This directly informs how the agent should handle the payload, which the annotations do not cover.

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 that states action, resource, encoding, and limit with zero 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 usefully discloses the base64 form and 10 MB ceiling, but it omits error behavior (missing/oversized document) and the id's origin, leaving gaps for an agent to call it reliably.

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 'id' parameter, so the schema gives no hint about what identifies a document. The description mentions 'un document' but never clarifies the id's form or where to obtain it, leaving the one required parameter effectively 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 ('Télécharge') and resource ('un document de l'espace documentaire'), and the qualifier 'espace documentaire' scopes it apart from the messaging/casier download siblings. It does not explicitly name those alternatives, but the resource is clear enough to distinguish from documents_deposer and documents_lister.

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 when-to-use guidance, no prerequisite (e.g. obtaining the id from documents_lister), and no routing against messagerie_telecharger_piece_jointe or casier_telecharger. The purpose is implied but the agent is left to infer selection.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully clarifies the aggregated nature and content categories, but says nothing about pagination, ordering, or volume, adding only modest context beyond the structured fields.

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 resource and its content scope are front-loaded, then a short usage hint. The category list is an efficient way to convey scope, and there is no filler.

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

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

For a two-parameter, fully-documented, annotation-covered read tool with no output schema, the description conveys what it aggregates and when to use it. It could still note ordering/pagination semantics, but nothing essential for correct invocation 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%: page ('0 = la plus récente') and types ('vide = toutes') are fully documented in the schema, and the enum values are self-explanatory. The description's category list loosely maps to the types parameter but adds no syntax or format detail beyond the schema, so the baseline of 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?

The description names a specific resource (the ENT 'Quoi de neuf ?' feed) and enumerates the categories it aggregates (messages, carnet, devoirs, actualités, billets de blog…), which distinguishes it from per-domain siblings like actualites_fils or messagerie_lister. It stops short of explicitly naming those siblings, so it doesn't fully earn 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?

It gives a clear use case — 'Idéal pour un résumé de ce qui s'est passé' — telling the agent this is the aggregated overview tool. There are no explicit exclusions or named alternatives (e.g. when to prefer actualites_fils), so it does not reach the when/when-not/alternative bar of a 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 and openWorldHint=false, so the safety profile is covered. The description adds useful output context (questions, choices, response link) but says nothing about behavior on an unknown or invalid formulaire_id, nor about permissions on restricted forms.

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 that identifies the subject and enumerates the returned content with no filler. Every clause of the description 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?

With no output schema, the description usefully sketches the return shape, which is a real contribution. However, for a lookup-by-id tool it omits how to obtain the id (presumably from formulaires_lister) and what happens on a missing form, leaving a meaningful gap.

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 schema gives only a bare unsigned integer named formulaire_id. The description never mentions the parameter, where the id comes from, or its expected form, so it fails to compensate for the coverage 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?

Names the resource (un formulaire) and states the operation is retrieving its detail, enumerating what the detail contains (description, questions, choix, lien de réponse). This contrasts with the sibling formulaires_lister, which lists rather than details, though the sibling is never 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?

There is no when-to-use, when-not-to-use, or alternative routing. Nothing tells the agent to call formulaires_lister first to obtain an id, or to prefer this tool over the listing tool when the user wants a single form's content.

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=false, covering the safety profile. The description adds only that the items are 'reçus' (received) and come 'avec leur statut' (with their status), which gives a little context about what is returned, but nothing about volume, ordering, or pagination.

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 that names the resource, gives examples, and notes the status field, with no redundant or filler 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 no-argument, read-only list tool with no output schema, the description is essentially complete. It could optionally note ordering or result scope, but nothing an agent needs to call it correctly 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?

The tool takes zero parameters, and the schema is empty with 100% coverage, so there is nothing for the description to compensate for. Baseline 4 applies since no parameter interpretation is needed.

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 the resource clearly – received forms/surveys – and adds concrete examples (exit authorizations, school surveys) plus the fact that status is included. The verb 'list' is only implied by the name, and it doesn't explicitly distinguish itself from the sibling formulaires_lire, but an agent can grasp the tool's 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 when-to-use or when-not-to-use guidance. The description does not point to formulaires_lire for reading a single form versus this tool for enumerating them, leaving the agent to infer the choice from the name alone.

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=false and idempotentHint=false, so the mutating, non-idempotent nature is covered. The description adds only the word 'personnel', and says nothing about duplicate-name behavior, whether nesting under parent_id is allowed, or response/permission requirements. For a create mutation the disclosure is thin.

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 short, front-loaded sentence with no waste. It earns its place but is minimalist rather than rich.

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 create tool with annotations covering the safety profile and no output schema, the description is minimally sufficient to call it correctly. However, it leaves naming rules, parent-folder semantics and error behavior entirely unaddressed.

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 description contains no parameter information at all, and schema description coverage is only 50% (nom is undocumented). This is weaker than the MID calibration where the description at least enumerated fields, so it does not compensate for the coverage 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?

States a specific verb ('Crée') and resource ('un dossier personnel dans la messagerie'), so the agent knows exactly what is produced. It does not explicitly differentiate itself from siblings like messagerie_dossiers or messagerie_deplacer, but the create action 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?

No indication of when to use this vs messagerie_dossiers (which presumably lists folders) or prerequisites such as needing an existing parent. The agent must infer all usage context. No alternatives or exclusions are named.

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 the full safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description only needs to add context. It contributes the destination constraint (inbox or personal folder), which is modest added value — it says nothing about behavior with invalid ids or partial failures. No contradiction with annotations.

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

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

A single short sentence, destination constraint front-loaded and no filler. However, brevity here borders on under-specification for a mutation tool rather than true economy.

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 two-parameter mutation tool with no output schema and rich annotations, the description is minimally adequate but omits error/edge-case handling and the relationship to sibling operations. Nothing critical is missing to invoke it, but coverage is thin.

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 50% and both parameters carry descriptions in $defs, but the description echoes the destination semantics of `vers` without adding format or syntax detail. It doesn't clarify the multi-message nature of `ids` beyond implying plural. Baseline 3 given the schema does most of the work.

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 (déplacer) and resource (messages) plus the destination scope (inbox or personal folder), so the action is unambiguous. It does not differentiate itself from nearby siblings such as messagerie_marquer or messagerie_restaurer, leaving the agent to infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use, when-not-to-use, or alternative routing is provided. An agent must guess how this differs from messagerie_marquer (mark) or messagerie_restaurer (restore-to-inbox), which are adjacent concepts in the sibling list.

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=false, so the safety profile is covered. The description adds genuinely useful context beyond them: the result is hierarchical ('arborescence') and carries unread counts per folder. It does not discuss ordering, depth, or empty trees, but with annotations present this is adequate.

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 parenthetical sentence that front-loads the resource and then lists the returned fields. No padding, though it is terse enough to leave some questions open.

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 parameterless read-only listing with annotations covering safety and no output schema, the description states what is returned clearly enough to invoke correctly. The absence of an output schema is a minor gap given the fields are already enumerated.

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 takes zero parameters, so the baseline is 4. There is nothing for the description to compensate for, and it correctly implies the tool returns all folders without filtering.

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 resource - the personal mail folder tree - and enumerates its payload (identifiers, names, unread counts). That distinguishes it from siblings like messagerie_creer_dossier (creates a folder) or messagerie_lister (lists messages). It lacks an explicit verb, but the noun-and-contents phrasing makes the read/list intent 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?

There is no statement of when to call this versus alternatives. Siblings such as messagerie_non_lus or messagerie_lister are never referenced, and no prerequisite or context is given. Usage must be inferred purely from the resource it describes.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds one meaningful behavioral fact — the draft is stored, not sent — but says nothing about permissions, whether re-saving with the same brouillon_id overwrites, or what identifier is returned.

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 sentence, front-loaded with the primary action, with the workflow detail parenthesized rather than padding a second paragraph. Every clause carries 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?

For an 8-parameter mutation with no output schema and annotations covering the safety profile, the description covers purpose and the create/attach/send lifecycle adequately. It leaves the return value unspecified, though the parenthetical implies the created draft ID is what `brouillon_id` feeds into.

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 75%, so most parameters (`a`, `cc`, `cci`, `corps`, `objet`, `en_reponse_a`, `transfert_de`) are already documented in the schema. The description only adds meaning for `brouillon_id` by tying it to the subsequent messagerie_envoyer call; it adds nothing about the other seven parameters.

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 pair and resource ('Crée ou met à jour un brouillon') and immediately differentiates it from the send path ('sans l'envoyer'), naming the related siblings messagerie_joindre_fichier and messagerie_envoyer. An agent can tell this is the draft-staging tool and not the sender without opening any 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?

Gives concrete workflow guidance: use it to hold a draft, attach files via `messagerie_joindre_fichier`, then send via `messagerie_envoyer` with `brouillon_id`. It names the sequencing context but offers no when-not guidance (e.g. when to just call messagerie_envoyer directly, or how it relates to messagerie_supprimer/restaurer).

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 flag this as a non-read-only, non-idempotent, open-world write, so the safety profile is covered. The description adds genuine behavioral value beyond that: the recipient-ID sourcing requirement and the mandatory user-validation-before-send step for a real outbound message. It stops short of describing failure handling or whether attachments are sent inline.

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 tight sentences, front-loaded with the action and immediately followed by the two operational constraints. 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 send tool with no output schema, it covers modes, recipient sourcing, and a pre-send validation requirement, which is enough for correct invocation. Minor gaps remain around attachment handling (a sibling, messagerie_joindre_fichier, exists) and send-vs-draft 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 75%, so the schema already documents `a`, `cci`, `brouillon_id`, `en_reponse_a` and `transfert_de`. The description reinforces the recipient-ID semantics and ties objet/corps to user validation, but adds little beyond the schema on the reply/forward/draft parameters.

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 ('Envoie un message') and even enumerates the three modes it supports (new, reply, forward), so the agent knows the tool covers all three. It does not, however, contrast itself with the sibling messagerie_enregistrer_brouillon, even though brouillon_id is a parameter here.

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?

Gives clear context: recipients are identifiers obtained via `annuaire_rechercher` or read from an existing message, which tells the agent where to source them. Adds a workflow constraint (have subject, body and recipients validated by the user before sending) but no explicit when-not guidance or alternative-tool routing.

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 disclose readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context (base64 encoding, 10 MB cap), but omits behavior on repeated attach, whether existing attachments are affected, and permission 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?

A single front-loaded sentence with zero filler; the key constraint (10 MB) is included without padding. Efficient, though very terse.

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 mutation tool with no output schema and partial parameter coverage, the description covers encoding and size but leaves prerequisites (draft must exist) and post-attach behavior unaddressed. Adequate but with visible 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 only 33% (only brouillon_id documented), so the description must compensate. It adds the base64 encoding hint for contenu_base64 and the 10 MB size limit, but nom_fichier remains undocumented and format details for the file name are absent.

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 (joindre/attach), resource (fichier), and target (brouillon), so the agent can tell it apart from siblings like messagerie_telecharger_piece_jointe or messagerie_enregistrer_brouillon. It is clear but does not explicitly contrast itself with any 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?

The description gives no when-to-use vs when-not guidance, no prerequisites beyond the implicit need for a draft, and names no alternative tool. It only states the operation and its limits.

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 discloses a non-obvious side effect that the annotations alone only signal indirectly: it marks the message as read, which explains readOnlyHint=false. This is genuinely useful context beyond the structured fields, though it does not clarify reversibility or whether the read state can be reset.

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 compact sentences, front-loaded with what is returned and followed by the side effect. 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?

With no output schema, the description usefully lists the delivered content and the read-marking behavior, which is enough for an agent to call it correctly. It could still note failure cases (invalid id) but the essentials are covered.

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 and schema description coverage is 100%, so the schema already carries the full meaning of 'id'. The description adds no format, valid-range, or sourcing detail for the identifier, 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?

The description states a specific verb and resource ('Lit un message complet') and enumerates the returned content (corps, destinataires, pièces jointes), which distinguishes it from listing tools like messagerie_lister. It is clear but does not explicitly name a sibling alternative.

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 by the verb: read a specific message by id. There is no explicit when-to-use guidance, no exclusion of alternatives, and no mention of prerequisites relative to siblings such as messagerie_marquer or messagerie_lister.

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=false, so the safety profile is covered. The description adds only the sort order (newest first) and default folder; it says nothing about pagination behavior or what a page of results 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?

A single tight sentence with the resource first and the default/sort qualifiers second; 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 read-only list tool with annotations covering safety and mostly-documented parameters, the description is adequate but thin: with no output schema, the agent gets no hint of the returned message shape or pagination semantics.

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 80% and the schema already documents dossier, taille, recherche and non_lus_seulement. The description merely reiterates the default folder, adding no syntax or filtering detail beyond the schema, 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?

Specific verb (Liste) plus resource (messages d'un dossier de la messagerie), with the default folder and ordering stated up front. It does not explicitly distinguish itself from nearest sibling messagerie_non_lus, but an agent can identify the operation 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?

States a sensible default (réception) and implies use for browsing a folder, but offers no when-to-use/when-not guidance and never names the alternative tools (messagerie_non_lus for unread, messagerie_lire for a single message, messagerie_dossiers for folder ids). Usage is left to inference.

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=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond restating the operation: no mention that it is idempotent, non-destructive, requires valid message ids, or what happens on partial failure.

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 with no filler or redundancy. It is efficient, though its brevity is as much under-specification as conciseness.

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 two-parameter state-toggle tool with annotations covering safety and no output schema, the description is minimally adequate. It omits return behavior, error handling for invalid ids, and the scope of the batch update, leaving gaps an agent would want covered.

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?

Reported schema description coverage is 0%, so the description must carry the load. It conveys the two possible states ('lus ou non lus'), which maps to the 'etat' parameter's enum, and the plural 'des messages' hints that 'ids' is a collection. It does not explain id format or batch behavior, 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 states a specific verb and resource ('Marque des messages') plus the state being set ('lus ou non lus'), which clearly separates it from siblings like messagerie_lire or messagerie_lister. It stops short of naming any sibling or the batch scope explicitly, so it is clear but not maximally differentiated.

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 related siblings such as messagerie_lire, messagerie_non_lus, or messagerie_deplacer. The agent must infer the use case purely from the single declarative sentence.

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=false, so the safety profile is covered. The description adds the scoping detail that the count is limited to the inbox (boîte de réception), which is useful given the sibling messagerie_dossiers exists. It does not disclose the return shape or whether it counts all folders.

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 short sentence with zero filler, and the scope (inbox) is front-loaded into the resource phrase. Nothing to trim.

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 trivial zero-parameter count tool whose annotations cover the safety profile, this is nearly sufficient. However, with no output schema, the description does not confirm the return type (a number) or whether folders other than the inbox are excluded, leaving minor ambiguity.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no syntax or format guidance is needed.

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 resource and quantity: the count of unread messages in the inbox. It is clearly distinguishable from messagerie_lister (which lists messages) and messagerie_lire (which reads one), since this is a scalar count. It does not explicitly name a sibling, so it falls 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?

There is no when-to-use guidance and no mention of alternatives. An agent must infer that this is for a lightweight badge/count check rather than fetching messages. Usage is only implied by the noun phrase.

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 destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral information in the form of the 60-minute eligibility window, but it does not say what recall actually does to the message (removed from recipients? replaced?), what permissions are required, or what happens past the 60-minute mark.

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, tightly written sentence with the action front-loaded and the qualifying condition appended. 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 one-parameter tool with no output schema and annotations that already declare the destructive/idempotent profile, the description supplies the key scoping constraint an agent needs. It is slightly thin on outcome and failure behavior (what recall returns or what error occurs after 60 minutes), but nothing critical is missing 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?

There is a single parameter with 100% schema description coverage ('Identifiant du message'), so the schema already carries the semantics. The description adds nothing about the id's expected format or source, which is the correct baseline when the schema does the heavy lifting.

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 gives a specific verb ('Rappelle/annule') and a specific resource ('un message envoyé'), and the parenthetical '(annule)' disambiguates 'rappeler' from its other French sense of 'to remind'. It also scopes the operation with a 60-minute window, which helps separate it from a plain delete, though it never names the sibling tools (messagerie_supprimer, messagerie_restaurer) it is adjacent to.

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 60-minute limit is effectively an implied precondition for when this tool can be used, but there is no explicit when-to-use versus when-not-to-use guidance and no routing to alternatives such as messagerie_supprimer for older messages. Usage must be inferred from the timing constraint.

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=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the meaningful constraint that restoration is from the trash (implying state dependency) but says nothing about permissions, failures, or effects on message folders.

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 short front-loaded sentence with no wasted words, but it is arguably over-terse for a mutation tool with an undocumented required parameter — conciseness here borders on under-specification.

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 state-changing, non-readonly tool with no output schema and no parameter documentation, the description omits preconditions (message must be in trash), identifier format, and return/error behavior. The trivial operation keeps this from being a total gap.

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 on the top-level 'ids' property and the required array is the only signal. The description never mentions that one or more message identifiers must be supplied or what their format is, so it adds no meaning over 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 and resource ('Restaure des messages') plus the source state ('depuis la corbeille'), which cleanly separates it from messagerie_supprimer and messagerie_lire. It does not, however, explicitly name or contrast with any sibling tool.

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 when-to-use guidance: nothing says the message must currently be in the trash, nor whether messagerie_supprimer is the inverse operation. The agent must infer usage from the single sentence and sibling names.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuine context beyond that: the default path is recoverable (trash) and permanent deletion is gated on the message already being trashed. It stops short of explaining permissions or what happens on invalid mode/ids.

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 sentence, front-loaded with the verb and resource, then the two modes in order of default-to-explicit. No filler or repetition.

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 two-parameter destructive tool with no output schema, the description covers the decision-relevant facts (recoverability, precondition for permanent deletion) and annotations cover the safety flags. Minor gap: nothing about failure behavior or permissions.

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 0% reported schema coverage, the description must carry parameter meaning, and it does explain the mode parameter's two values and their precondition. The required ids parameter is left entirely to its name/type, so the compensation is only partial.

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 (Supprime) and resource (messages) and enumerates both effect modes (corbeille vs definitive). It is clearly distinguishable from read/list siblings, but it does not name the adjacent operations (restaurer, deplacer) that an agent would need to disambiguate against.

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 gives a real conditional rule for the mode parameter: definitive only applies to messages already in the trash, and trash is the default. However, it never states when to prefer this tool over messagerie_restaurer or messagerie_deplacer, so alternative-selection guidance is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. On top of that, the description discloses two non-obvious behavioral traits the annotations do not: the returned content is base64-encoded, and there is a 10 MB size ceiling. That is genuine added value beyond structured fields.

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 with no filler. The output format (base64) and the hard limit (10 MB) are packed in without obscuring 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 read-only retrieval tool with no output schema, the description covers the essential contract: what is fetched, how it is returned, and the size constraint. It omits failure modes (missing attachment, exceeding the limit) and the id-acquisition workflow, but those are relatively minor for this tool type.

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

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

Effective schema description coverage is essentially zero for piece_jointe_id (message_id has only a $defs one-liner), so the description carries the burden of explaining parameters but adds nothing. It never clarifies what a piece_jointe_id is, where to obtain it, or how it relates to message_id.

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: 'Télécharge une pièce jointe d'un message'. This clearly distinguishes it from the upload sibling messagerie_joindre_fichier and the unrelated documents_telecharger/casier_telecharger tools. However it does not explicitly name those adjacent tools to reinforce the distinction, 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?

No when-to-use guidance, preconditions, or alternatives are given. The agent must infer from the name alone that this is for retrieving an attachment rather than for viewing the message (messagerie_lire) or attaching a new file (messagerie_joindre_fichier).

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=false, so the safety profile is covered. The description adds that it scopes to the connected account (session/auth context) and lists the returned fields, but says nothing about failure modes or what happens without a session.

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 sentence, front-loaded with the resource and its returned fields, ending on the actionable directive. No filler.

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

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

There is no output schema, so the description carries the burden of describing return contents, and it does so by enumerating the exposed fields. Adequate for a trivial 0-param read tool, though the exact shape of nested items (e.g. child identifiers) is left implicit.

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 takes zero parameters, so the schema has nothing to document and there is no parameter semantics to add. Baseline of 4 applies for a 0-param 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 names the exact resource ('Profil du compte connecté') and enumerates what it exposes (nom, type de compte, enfants rattachés, établissements, classes). No sibling tool covers profiles, so an agent can immediately tell what this returns.

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 closing directive 'À appeler en premier' gives an explicit ordering rule, telling the agent to invoke this before other tools. It does not name a when-not case, but no alternative profile tool exists among the siblings.

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=false, covering the safety profile. The description adds no behavioral context beyond restating the name—no auth requirements, no return format, no pagination or error behavior. It adds essentially zero value beyond structured fields.

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 short, front-loaded sentence with zero waste. It is efficient, though its extreme brevity contributes to gaps in other dimensions rather than being a structural flaw itself.

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

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

For a tool with 0% schema description coverage and no output schema, the description is too sparse. It omits parameter explanations and any return or permission context, leaving the agent with little beyond the annotations and parameter names.

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 two required parameters (wiki_id, page_id). The names are somewhat self-explanatory, offering a faint implicit mapping, but the description does not compensate for the missing schema documentation.

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: 'Lit une page de wiki' (reads a wiki page). It clearly distinguishes from the sibling 'wiki_lister' (which lists wikis) and from other 'lire' tools by naming the wiki domain. However, it does not explicitly contrast itself with alternatives beyond the resource noun.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer that this tool is chosen when a specific wiki page ID is known, but the description offers no routing context.

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=false, so the safe read-only nature is covered. The description adds the scoping detail that only accessible wikis and their pages are returned, which is useful context, but it omits any behavioral details like pagination, ordering, or whether pages are nested.

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 concise sentence with no filler, and it front-loads the resource. However, its terseness borders on under-specification, and it could have used a few more words to clarify the action without becoming verbose.

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, zero-parameter list tool with annotations covering safety and no output schema, the description states the content returned (accessible wikis and their pages). Still, it does not clarify whether the result is nested, ordered, or paginated, nor does it explain the term 'accessible' (e.g., permission-based), leaving gaps for an agent to interpret.

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 and schema coverage is 100%, so there is no parameter semantics to explain. The baseline for zero parameters is 4; the description adds no parameter information, but none is needed.

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 resource (wikis) and indicates it returns a list of pages, but it is a noun phrase with no explicit verb and does not distinguish this listing operation from the sibling wiki_lire_page, which reads a specific page. An agent can infer it is a list tool from the name, but the description alone leaves the action somewhat vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance or alternatives are mentioned. The description does not say when to call this versus wiki_lire_page or any other tool, leaving the agent to infer usage from the name.

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