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

With no annotations, the description carries the full burden, and it does add one valuable behavioral fact: cancelling does not modify Discord ('sans modifier Discord'), signalling a non-destructive, bookkeeping-only operation. However, it says nothing about whether the plan is deleted or merely marked cancelled, whether cancellation is reversible, or what happens when the plan is already executed or the id is unknown.

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, and the scope restriction sits immediately after the action. It is efficient, though its brevity contributes to the omissions noted in other dimensions.

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

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

The tool is simple (one required parameter, no output schema, no nested objects), so a short description is defensible, and the 'sans modifier Discord' clause covers the main safety concern. Still, for a state-mutating cancel operation with no annotations, the definition should say what the return looks like and what happens on invalid or already-executed plan ids.

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 parameter plan_id has 0% schema description coverage and the description adds no meaning: it never says what a plan id is, where to obtain one (e.g., from preparer_plan or consulter_plan), or what format it takes. The only signal is the tool's own context, which is thin compensation 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 and resource ('Annuler un plan') and narrows scope to plans 'en attente', which separates it from executer_plan or consulter_plan in the sibling list. It does not explicitly name those siblings, so differentiation is inferable rather than stated.

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

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

The qualifier 'en attente' implies the usage condition (only pending plans can be cancelled), but there is no explicit when-to-use/when-not-to-use guidance and no mention of alternatives such as executer_plan or ouvrir_approbation. An agent must infer the routing from the word 'pending'.

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

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

With no annotations, the description carries the full burden and does disclose that the calculation is local, has no network access, and performs no modification. However, it does not explain determinism, error behavior, required permissions, or what the return value represents, leaving meaningful gaps for an unannotated 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?

The description is two short sentences with no wasted wording. It front-loads the purpose and follows with the most important safety constraint.

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 only input parameter is undocumented. For a calculation tool, the description should clarify what 'noms' represents and what result the agent should expect; it omits both, so the agent cannot confidently invoke it.

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 never explains the sole required parameter 'noms'. An agent cannot tell whether these are role names, user names, permission labels, or something else, so the description adds no meaning beyond the bare array-of-strings 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 action (calcul) and resource (permissions usuelles Discord), and qualifies it as local. It does not differentiate this tool from sibling permission tools such as permissions_salon or role_membre, 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?

There is no guidance on when to use this tool instead of permissions_salon, role_membre, or other permission-related siblings. The only usage context is implied by 'calcul local', with no exclusions or alternatives 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?

With no annotations, the description carries the full disclosure burden, and it does little beyond the bare statement that it reads data. It does not state that the operation is read-only and side-effect free, nor whether the catalogue is static, filtered, or permission-dependent. The only behavioral hint is the shape of the returned content (actions, parameters, plan format), which 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 sentence that front-loads the verb and enumerates the three things returned. Nothing is wasted, though the terseness leaves little room for routing context.

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, output-schema-less listing tool the description covers the essentials of what comes back. However, it does not clarify whether the catalogue is exhaustive or filtered by permissions, nor how the results relate to the execution/preparation siblings in this toolset.

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 is 4. The description correctly implies no inputs are required.

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 ('Lire') and a concrete resource: available actions, their parameters, and the format of grouped plans. An agent can tell it is a discovery/lookup tool rather than an execution tool. It stops short of distinguishing itself explicitly from siblings such as consulter_plan or preparer_plan, so it is clear but not 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: the reading of the action catalogue suggests calling it before preparing or consulting a plan, but the description never says when to use it versus those siblings or what conditions favor it. No exclusions or alternatives 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?

With no annotations, the description carries the full burden; 'Lire' implies a non-mutating operation and the sentence usefully discloses one return attribute (local approval status) that would otherwise be unknown given there is no output schema. It does not cover behavior when the plan_id is unknown, what 'localement' means in terms of scope, or the shape of the returned plan.

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

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

One front-loaded sentence with no filler or repetition. It is efficient, though its brevity contributes to the gaps in usage and parameter guidance.

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 read tool this is close to adequate, but with zero annotation coverage and no output schema the description must carry safety, return-shape, and error semantics, and it only partially does so. A note on plan_id provenance and failure behavior would close the 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% for the single required parameter plan_id, and the description only indirectly implies it identifies a saved plan. It adds no information about where the id comes from (e.g., the output of preparer_plan) or its expected format.

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

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

Names a specific verb ('Lire') and resource ('un plan enregistré'), and adds a distinct secondary purpose ('savoir si l'utilisateur l'a approuvé localement'). This lets an agent tell it apart from executer_plan or annuler_plan, though no sibling is named explicitly.

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

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

Usage is only implied: the word 'enregistré' suggests this applies to plans previously created via preparer_plan, and 'approuvé localement' hints at checking state before executer_plan. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer the lifecycle position.

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

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

No annotations are supplied, so the description carries the full behavioral burden. 'APERÇU' is the only behavioral hint and it is ambiguous — the agent cannot tell whether the role is actually persisted, whether a confirmation/approval step follows, what permissions are needed, or whether creation is reversible.

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

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

Three short fragments, zero filler, with the operation named up front and the two non-obvious parameter formats attached. The compressed telegraphic style leaves the 'APERÇU' marker under-explained, but 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 4-parameter mutation tool with zero annotation coverage, no output schema, and 0% schema description coverage, this is thin. It never addresses the missing parameter semantics, the preview/commit model, or the interaction with the prepare/approve/execute siblings.

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

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

Schema description coverage is 0%, so the description must compensate, and it does partially: it explains that 'permissions' is a text-encoded decimal mask and 'couleur' is an integer RGB value, which is genuinely valuable for otherwise opaque fields. It says nothing about 'nom' or 'affiche_separement', and does not explain how the permission mask bits map to permissions.

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 ('Créer un rôle'), which is distinguishable from siblings like modifier_role, supprimer_role and role_membre. It does not however name those siblings or clarify where role creation sits relative to the plan/approval tools.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no routing to alternatives such as modifier_role or the plan/execution siblings. The leading word 'APERÇU' implies a preview mode but never explains what triggers a real creation versus a preview.

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

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

With zero annotations, the description carries the full safety burden and does so on the decisive point: it explicitly states no change occurs before human approval, so an agent will not assume the channel exists afterwards. It leaves unstated what the preview returns (a plan reference?), whether prepared previews expire, or what permissions are required, which keeps it below 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?

Three short fragments with the most important qualifier (APERÇU) front-loaded and zero filler. It is efficient, though the second and third sentences could be merged into one clause without loss.

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 four-parameter tool with no annotations, no output schema, and no parameter descriptions, the definition is too thin. An agent knows it is a safe preview but not what it produces, how the result feeds the approval step, or how to populate type/sujet/categorie_id.

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% across four parameters, so the description must compensate and it adds nothing about any of them. Only "salon" hints that nom is the channel name; type, sujet and categorie_id (all with defaults) are completely undefined in both the schema and 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?

"Préparer la création d'un salon" pairs a specific verb (prepare) with a specific resource (salon), and "APERÇU" immediately signals that this is a staging step rather than the creation itself, which cleanly separates it from modifier_salon/supprimer_salon. It stops short of naming the sibling that actually commits the change, so an agent must infer the link to executer_plan/ouvrir_approbation.

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?

"Aucun changement avant approbation humaine" implies this belongs to a prepare-then-approve flow, which is the right usage context. However, no sibling is named: it does not say to follow with ouvrir_approbation or executer_plan, nor does it exclude scenarios where modifier_salon is more appropriate.

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

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

No annotations are supplied, so the description carries the full burden of behavioral disclosure. It reveals only a coverage limitation — the check is server-scoped and misses channel overrides for invisible channels — but says nothing about permissions required to run it, how results are reported, or whether the bot's token must be valid.

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

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

Two short sentences, with the core purpose stated first and the scoping caveat immediately after. No filler and nothing that could be cut 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?

This is simple to call, but it is a diagnostic that an agent would likely use for troubleshooting, and no output schema exists to explain what a result looks like. The description never says what the check returns or how to interpret a failure, which is the main gap remaining.

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 no parameters, so there are no argument semantics to explain and the schema achieves 100% coverage by default. The baseline for a parameterless tool is 4.

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 pair: checking the bot's connection and permissions at server level. That is meaningfully distinct from sibling tools such as 'calculer_permissions' or 'etat_serveur', although it never states explicitly how it differs from those siblings.

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

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

It names one concrete exclusion (channel-level overrides and invisible channels are not verified), which usefully implies when the tool is incomplete. However, it gives no positive guidance about when to choose this tool over 'etat_serveur' or 'calculer_permissions', or what to do after the check fails.

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

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

With no annotations, the description carries the full burden, and it does disclose three useful behaviors: a preview/APERÇU mode, automatic mentions being disabled, and mandatory human validation. It omits the permission requirements, whether state changes persist, message-length or rate limits, and what the result looks like.

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?

Four short fragments that lead with the most important signal (APERÇU) and stay free of filler. The telegraphic fragment style is efficient but sacrifices connective detail that could have clarified intent, for instance around the preview mode.

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-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. An agent still cannot determine the required permissions, the ID format for the channel, or the embed shape, so this is not enough to call the tool 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%: 'salon_id' and 'contenu' have bare titles, and 'embeds' is an untyped array of free-form objects. The description only echoes that a message and/or embeds are supplied and explains no parameter formats, ID conventions, or embed structure, so it fails to compensate for the schema 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 names a specific verb and resource: 'Publier un message et/ou des embeds' clearly identifies the action as posting a message with optional embeds. It does not differentiate from siblings, but the surrounding tool list is mostly role/guild management, so ambiguity is low. The leading 'APERÇU' (preview) slightly muddies whether posting actually occurs.

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 named alternatives are given, so it is unclear how this relates to the plan/approval siblings (preparer_plan, ouvrir_approbation, executer_plan). The phrase 'Validation humaine obligatoire' implies an approval workflow but never states whether this tool can be called directly or only after approval.

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

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

With no annotations at all, the description carries the full burden, and it does make the central safety claim: the server is not modified. However, it says nothing about required bot permissions/intents, whether the call is rate-limited or expensive on large servers, or how state is scoped — meaningful gaps for a snapshot tool with zero annotation coverage.

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 with no filler, and the read-only constraint is placed at the end where it qualifies the whole action. Nothing is wasted, though the sentence is arguably under-packed rather than optimally structured.

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 tool with no output schema, the description usefully enumerates the returned surface (server, channels, roles, permissions), which is what an agent needs to know before calling. Missing only operational detail (auth requirements, response shape specifics) to reach full completeness.

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 an empty object, so there is no parameter semantics to explain. Baseline 4 applies; the description correctly makes no claims about inputs.

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

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

Names a specific verb ("Lire") and enumerates the resources returned: serveur, salons, rôles, permissions. The clause "sans le modifier" implicitly separates it from the many mutating siblings (creer_salon, modifier_role, supprimer_role), though it never names an alternative explicitly.

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

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

The read-only framing implies this is the inspection entry point before acting, but the description never states when to prefer it over siblings such as permissions_salon or calculer_permissions, nor any precondition. Usage is inferable rather than 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?

No annotations are supplied, so the description carries the full burden, and it delivers unusually strong safety context: a pre-mutation backup, single-use approval, a 10-minute freshness window, and refusal when targets drift. It stops short of describing failure modes, atomicity, or what the caller receives on success.

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?

Four short sentences, zero waste, with the core execution constraint front-loaded ahead of the safety and refusal rules. Every sentence adds a distinct operational fact.

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 mutating executor with no annotations and no output schema, the description covers preconditions, safety behavior and refusal semantics well. The main omission is the return side — with no output schema, the agent does not know what an execution result looks like.

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 one parameter (plan_id) with 0% schema description coverage, so the description must compensate. 'Un plan approuvé' implies plan_id points at an approved plan, but it never says where that identifier comes from (presumably a preparer_plan/consulter_plan result), so an agent must guess.

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

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

The description names a specific verb and resource ('Exécuter ... un plan approuvé') and constrains it with 'uniquement', which distinguishes it from the plan-lifecycle siblings such as preparer_plan, consulter_plan and annuler_plan. It does not explicitly point at a sibling, but the 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?

Preconditions are explicit: the plan must already be human-approved in the local window, be under 10 minutes old, and have unchanged targets. What it does not do is name the sibling that produces the approval (ouvrir_approbation) or state which tool to call first, leaving the workflow order 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?

No annotations are supplied, so the description carries the full burden. It never states that this is a read-only listing, whether results are scoped to the local server ('locaux' hints at it but is unexplained), how results are ordered, or whether the output is paginated or truncated by 'limite'.

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, front-loaded with the verb and resource list, with no filler or redundancy. Its brevity is close to under-specification, but nothing is wasted or 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?

With no annotations, no output schema, and 0% parameter description coverage, the definition is too thin for a two-parameter history tool. An agent still lacks the result shape, ordering/pagination behavior, and any hint of access prerequisites or scope limits.

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

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

Schema coverage is 0% and no enums are declared, but the description does add real meaning by naming the three accepted values for 'type' (runs, backups, plans) — information the schema does not supply. It says nothing about 'limite' (default 20), leaving the second parameter undocumented anywhere.

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 verb is specific ('Lister') and the enumerated resource set is explicit: runs, backups, or plans, with French/English glosses that remove ambiguity. However, it does not distinguish itself from nearby siblings such as 'journal_execution' or 'consulter_plan', so an agent cannot tell from the description alone when this listing differs from those lookups.

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, and no alternatives are named despite several plausible overlapping siblings (journal_execution, consulter_plan, diagnostic). At best the reader infers that the 'type' argument selects which category is listed, which is implication rather than guidance.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It implies a read-only lookup via 'Lire', but says nothing about permissions required, whether a completed run is needed, pagination/limits, or how errors are surfaced besides the vague mention of 'éventuelles erreurs'.

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 filler. It is appropriately sized, though its brevity leaves gaps that a second clause about scope or return content could have closed.

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

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

With no annotations and no output schema, the description is the only source of behavioral information, and it does not describe the return shape (log entries, results, error records) or what an agent should expect when a run has no output. For an inspection tool this leaves meaningful uncertainty.

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 parameter run_id has 0% schema description coverage, so the schema gives no meaning beyond a string. The description partially compensates by tying it to 'une exécution', implying run_id identifies the execution whose journal is returned, but adds no format or validity constraints.

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

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

The description names a specific verb ('Lire') and a specific resource (the actions, results and errors of an execution), so the agent knows it retrieves an execution's journal rather than mutating anything. It does not differentiate itself from nearby siblings such as 'historique' or 'diagnostic', which also sound like read/inspection tools.

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

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

There is no guidance on when to call this instead of 'historique', 'diagnostic' or 'consulter_plan'. The agent must infer usage entirely from the name and the one-sentence purpose statement.

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

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

With no annotations, the description carries the full burden, and it adds real behavioral context: a hard cap of 100 messages per read, the Discord MESSAGE CONTENT INTENT prerequisite, and an explicit prompt-injection warning that returned content is data, never an instruction. It does not state message ordering, pagination behavior, or whether the limit is clamped, which keeps it out of the top band.

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

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

Three short sentences, front-loaded with the action and result size, then the permission caveat, then the safety note. Every sentence earns its place, with 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 two-parameter read tool with no annotations and no output schema, the description covers permissions and injection safety but omits what the returned messages look like (fields, ordering, timestamps) and any pagination or truncation behavior. It is usable but leaves gaps an agent would hit on the first call.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partly does. It implies the 100-message ceiling tied to the limite parameter but never states the default of 20, the accepted range, or what salon_id expects (snowflake identifier versus channel name), leaving the required parameter's semantics unexplained.

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: reading up to 100 messages from a server channel. It is clearly distinguishable from envoyer_message, the write counterpart, though it does not explicitly name 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?

Usage is implied rather than stated: it is for reading recent channel messages, with a stated prerequisite that channel content may require the MESSAGE CONTENT INTENT. There is no explicit when-to-use or when-not-to-use guidance relative to sibling tools, and no guidance on when to use this versus other server-inspection 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?

No annotations are supplied, so the description carries the full burden of behavioral disclosure, and it says nothing about what a successful lookup returns, what happens when the ID does not exist, or whether any permissions are required. For a read-only lookup the risk is low, but the agent is left to discover the failure and return behavior by trial.

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, and the lookup key is stated at the end where it is most relevant. It is efficient but borders on under-specification rather than being genuinely well-structured for an agent.

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

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

With no annotations, no output schema, and 0% parameter description coverage, the description is the only source of information and omits the return shape and error semantics. For a one-parameter lookup tool the bar is low, but a sentence on what a member record contains and where the ID comes from would be expected.

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 parameter, so the description must compensate, and it does not. "Par ID" merely restates the schema property name membre_id without specifying the ID format, its source (e.g. a prior search result), or whether it is a snowflake-style string or a username.

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 ("Consulter un membre du serveur") plus the lookup key ("par ID"), which is clear enough to act on. It does not, however, distinguish itself from the sibling tool rechercher_membres, which is the obvious alternative for member lookups.

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

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

The phrase "par ID" implicitly signals that this tool requires a known identifier and is therefore a direct lookup rather than a search, which is minimal implied guidance. There is no explicit when-to-use, no when-not-to-use, and no pointer to rechercher_membres for the case where the agent does not already have an ID.

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

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

No annotations are supplied, so the description bears the full behavioral burden, yet it does not disclose what mutation actually occurs, whether the change is applied immediately or only previewed, whether it is reversible, or what permissions are needed. The word 'APERÇU' actively raises a behavioral question the description never answers.

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?

Very short and front-loaded, but it is two fragments rather than a structured sentence, and the 'APERÇU' prefix consumes attention without conveying clarified meaning. Nothing is padded, yet the brevity comes at the cost of substance.

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 annotations, no output schema, and no parameter descriptions, the definition is far too thin. An agent cannot tell whether to expect a preview artifact, what a successful result looks like, or how to format the permissions value.

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 all three parameters lack documentation. The description names 'nom' and 'permissions' but says nothing about the required 'role_id' or the expected format of the permissions string (list, bitfield, JSON?), leaving half the surface undocumented.

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

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

States a specific verb and resource ('Modifier ... un rôle') and names the two editable fields (nom, permissions), which distinguishes it from creer_role and supprimer_role in the sibling list. The leading token 'APERÇU' is left unexplained, adding ambiguity about whether the operation is real or simulated.

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

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

The description implies usage (change a role's name or permissions) but gives no explicit when-to-use guidance, no prerequisites such as required privileges, and no pointer to alternatives like creer_role or supprimer_role. The 'APERÇU' prefix vaguely hints at a preview mode without stating its condition.

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

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

No annotations exist, so the description carries the full behavioral burden, yet "APERÇU" is never defined — an agent cannot tell whether this applies changes, stages them, or merely previews. Nothing is said about permissions required on the salon, whether the change is reversible, or whether it is visible to members, which is a serious gap for 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?

Three short sentences with the mode marker and action front-loaded, then the escape hatch. Nothing is padded, though the terse fragment style leaves the preview semantics unexplained rather than crisp.

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 4-parameter mutation tool with no annotations, no output schema and zero parameter documentation, the description is far too thin. An agent still cannot answer whether calling it mutates state, what permissions it needs, or what nom and salon_id mean — all of which must come from the description 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?

Schema description coverage is 0% and the schema supplies only bare titles, so the description must compensate. It obliquely references sujet and the categorie detach case via parent_id, but never explains nom or salon_id, nor the semantics of an empty-string value versus an omitted one for a patch-style update.

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?

"Modifier un salon" names a specific verb and resource, and the sibling set (creer_salon, supprimer_salon, modifier_role) makes the modification role unambiguous. The leading token "APERÇU" hints at a preview mode without ever explaining what it means, which is the one blur on an otherwise clear purpose.

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

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

It explicitly routes a non-obvious edge case to an alternative tool: to empty a topic or detach a category, use preparer_plan with an empty topic or null parent_id. That is real when-to-use guidance, but it covers only that narrow case — there is no statement of general prerequisites, what happens with the other parameters, or when this should be preferred over the plan/execute 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?

With no annotations, the description must carry the full burden, and it does disclose the key safety trait: the user alone clicks Approve and Discord is not modified. It leaves out whether the call blocks until the user acts, what happens on rejection or timeout, and what the call returns.

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

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

Three short sentences with the precondition front-loaded and the non-mutation guarantee last for emphasis. No filler, though the sentences could tie the approval step to the surrounding plan workflow more tightly.

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 annotations, no output schema and one undocumented parameter make this a workflow tool that relies on the description; it conveys the human-in-the-loop intent and non-destructive nature. Missing: what an approval yields and how it hands off to executer_plan, which keeps it short of 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 single parameter plan_id has 0% schema description coverage and is never mentioned in the description. The phrase 'l'aperçu' loosely implies the id refers to a previously previewed plan, but no meaning, source, or format is established.

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 concrete verb and resource: opening a local approval window that shows the exact actions. The closing sentence 'Ne modifie pas Discord' separates it from executer_plan, though it does not explicitly name 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?

Gives a sequencing precondition ('Après accord de l'utilisateur sur l'aperçu'), which implies this follows the preview step. However, it never says which tool to use before (consulter_plan/preparer_plan) or what to call after approval succeeds, nor any exclusion case.

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

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

No annotations are supplied, so the description carries the full burden. 'Remplacer' usefully signals that existing channel overrides are overwritten rather than merged, but nothing covers required permissions, reversibility, defaults for autoriser/refuser, or what a call returns.

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?

It is short with no padding, but it reads as three telegraphic fragments rather than complete sentences, and the ambiguous 'APERÇU' occupies the front-loaded position where the actual action should lead.

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 five-parameter overwrite operation with no annotations, no output schema, and no parameter descriptions, the definition is far too thin. An agent cannot determine the target-type vocabulary or the mask encoding well enough to call it confidently.

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% across five parameters with bare titles. 'Masques décimaux texte' genuinely clarifies that autoriser/refuser are decimal-string bitmasks, but cible_type's allowed values, cible_id format, and the interaction between the two masks remain 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 verb and resource ('Remplacer les permissions spécifiques d'un rôle ou membre dans un salon'), which clearly separates it from sibling mutation tools like modifier_salon and modifier_role. The leading 'APERÇU' fragment is unexplained and slightly muddies whether this acts or only previews.

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 over calculer_permissions or modifier_role/modifier_salon, nor any stated prerequisites or exclusions. 'APERÇU' hints at a preview-only context but never states it, leaving selection 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?

With no annotations, the description does disclose the most important behavioral trait: nothing is changed on Discord, yet a plan is persisted ("enregistrer"). It does not say what is returned (a plan identifier needed for later execution), whether repeated calls create duplicate plans, or how long a saved plan stays valid.

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?

Four short sentences with the critical constraint ("APERÇU SEULEMENT") front-loaded. "Voir catalogue_actions" is telegraphic but efficient; nothing is padded.

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 no annotation coverage, so the description must carry the return contract and parameter shape; it supplies neither. For a tool whose whole purpose is to hand back a reviewable plan, omitting what the caller receives is a material 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 coverage is 0% for both required parameters. The description says nothing about "titre" or what the elements of "actions" must contain, and "actions" is a free-form object array with additionalProperties=true, which is the riskiest possible gap. The pointer to catalogue_actions partially compensates for the action shape but leaves the rest 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?

"Valider et enregistrer un plan groupé sans aucun changement Discord" states a specific verb (validate/save) and resource (grouped plan) plus the key scope boundary (no Discord mutation), which separates it from executer_plan. The French name/title pairing is slightly ambiguous (prepare vs. save), but an agent can still tell what it produces.

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?

"Afficher ce plan à l'utilisateur avant de demander sa validation locale" prescribes a workflow step, implying this is the dry-run phase preceding approval/execution, but no sibling tool (executer_plan, ouvrir_approbation, consulter_plan) is named as the alternative and no preconditions are given. Usage is therefore implied rather than explicitly routed.

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

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

With no annotations supplied, the description carries the load itself and does reasonably well: it discloses that later additions are preserved, that non-targeted role assignments and deleted messages are not restored automatically, and that human approval is required. It stops short of stating explicitly whether preparing this preview mutates state.

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?

Four short sentences, purpose front-loaded, followed by preservation behavior, exclusions, and the approval gate. No filler and no repetition of the tool name or schema.

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

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

For a preview operation with no output schema, the description should say what the aperçu actually returns (a plan? a diff?) and how it leads to approval, since that is the whole point of the tool. The destructive-change scope is well covered, but the output and follow-up path are not.

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 adds no meaning about backup_id beyond what the name implies. Since there is only one obviously-named required parameter, the practical risk of mis-invocation is low, but no compensating detail (where the id comes from, format) is provided.

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 first clause states a specific verb and resource: 'Préparer un aperçu de restauration d'une sauvegarde', which tells an agent this is a preview/dry-run step rather than an execution. It does not explicitly contrast itself with the sibling preparer_retour_arriere or preparer_plan, so differentiation is only partial.

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

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

The description implies the workflow position through 'Approbation humaine requise', suggesting this preview precedes an approval and execution step (ouvrir_approbation / executer_plan). However, it never names those alternatives or states when to choose restauration over retour arrière, leaving the 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?

With no annotations, the description carries the full burden and does meaningful work: it warns that the rollback 'Peut écraser les modifications postérieures des mêmes éléments', discloses that partial/uncertain runs are refused, and points to a preview step. It stops short of stating permission requirements or clarifying that this only builds a plan rather than executing it, leaving some behavioral gaps.

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?

Dense but well-structured: purpose first, then the overwrite warning, then the refusal/alternative clause. Every clause carries information, though the warning and preview instruction could be tightened.

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 or annotations, the description covers purpose, destructive-risk warning, refusal conditions, and the sibling alternative. It lacks permission/auth context and does not explain what the generated plan/preview contains, but the core decision-relevant information is present.

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

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

Schema coverage is 0% and the single run_id parameter is undocumented in the schema. The description only implicitly conveys that run_id refers to 'cette exécution' whose prior backup is restored, adding modest meaning but not resolving format or which executions are eligible.

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: 'Préparer un plan pour restaurer la sauvegarde avant cette exécution et supprimer ses créations connues.' It distinguishes itself from the sibling preparer_restauration and journal_execution, so an agent can tell this apart from the generic preparer_plan/preparer_restauration tools.

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

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

Explicitly names the exclusion ('Refuse les exécutions partielles/incertaines') and routes the agent to the correct alternative ('consulter le journal et utiliser preparer_restauration'). It also directs the agent to read the preview before proceeding, leaving little 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?

With no annotations, the description carries the full burden, and it does disclose one genuinely useful operational prerequisite: the SERVER MEMBERS INTENT must be enabled in the Discord portal. It does not say what happens when that intent is missing (empty results vs. error), nor that the call is a non-mutating read with pagination or a default cap.

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, front-loaded with the core action and followed by the prerequisite. Nothing is wasted, though the prerequisite could have been placed after a brief note on what results look like.

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, non-mutating lookup with no output schema and no annotations, the definition covers the action, the matching rule, and the key Discord permission prerequisite. The missing piece is any mention of 'limite' or result behavior, which keeps it from being fully 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?

Schema description coverage is 0%, so the description must compensate; it explains that 'recherche' is matched by prefix of name or nickname, which is real added meaning over a bare string field. However, the 'limite' parameter (integer, default 20) is never mentioned, leaving half the parameters undefined.

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 ('Rechercher les membres') plus the matching mechanism ('par préfixe de nom/surnom'), which distinguishes it from the singular sibling 'membre'. It stops short of naming that sibling explicitly, but the prefix semantics make the scope 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 or when-not-to-use guidance, and no reference to alternatives such as 'membre' for a single known member. Prefix matching implicitly signals it is a lookup rather than a full roster dump, but that is inference rather than stated guidance.

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

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

No annotations are supplied, so the description carries the full burden, yet it does not state whether the change is immediate or a preview, what permissions are required, whether removal revokes inherited permissions, or what is returned. The word 'APERÇU' alongside an explicit mutation verb leaves the side-effect profile genuinely unclear.

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 compact sentence with no wasted filler, but leading with the ambiguous 'APERÇU' rather than the action itself misplaces emphasis and forces the agent to reinterpret the tool's nature.

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?

This is a mutation tool with no annotations, no output schema, no parameter documentation beyond one enum-like hint, and an unresolved preview-versus-execute ambiguity. For a three-required-parameter write operation, substantially more context is needed.

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 all three parameters are required, so the description must compensate. It does document the two expected values for 'action' (ajouter/retirer), which the schema lacks, but 'membre_id' and 'role_id' receive no format or sourcing information at all.

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 core verb+resource is identifiable: adding or removing a role from a member. However, the leading token 'APERÇU' (preview) muddies whether this is a dry-run or an actual mutation, and the description does not differentiate it from siblings such as supprimer_role or modifier_role.

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 modifier_role, supprimer_role, or the plan/approval flow siblings. The only routing hint is the 'action: ajouter ou retirer' phrase, which describes a parameter value rather than a usage condition.

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

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

With no annotations, the description must carry the full burden. It does disclose key behavior: the operation is read-only with respect to Discord and does not capture full message history. It omits where the backup is stored, whether existing backups are overwritten, permission prerequisites, and what the call returns.

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 zero filler. The scope statement comes first and the limitation clause second, so an agent can parse it instantly.

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-optional-parameter tool this is close to sufficient, but with no annotations and no output schema the description should say where the snapshot lands and what the response contains. The behavioral scope is well covered; the mechanics are not.

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 never mentions the single 'nom' parameter. The default value ('Sauvegarde manuelle') implies it is a label, but the description adds no meaning about its purpose, format, or effect on the stored backup.

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 and resource: 'Créer une sauvegarde locale de la structure actuelle (salons, rôles, paramètres)'. This clearly distinguishes a local configuration snapshot from mutating siblings like modifier_salon or preparer_restauration. No explicit sibling is named, 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?

'Aucun changement Discord, aucun historique intégral de messages' signals what the tool is NOT for, which implicitly steers agents away from expecting message archives or Discord-side mutations. However, no alternative tool is named and there is no explicit 'use this when you want X' condition.

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

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

No annotations exist, so the description carries the full behavioral burden. It hints at a side effect on member assignments ("ne sont pas sauvegardées automatiquement") but this phrasing is ambiguous — it is unclear whether assignments are deleted, orphaned, or left untouched, and nothing is said about irreversibility or required authorization.

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

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

Three short sentences with no padding, but the front-loaded "APERÇU" is the least informative and most confusing element to lead with. Restructuring around the delete action and its consequence would earn the space better.

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 mutation with no annotations, no output schema, and an undocumented required parameter, the description should state permissions, irreversibility, and what happens to member assignments. The current text leaves all of these unresolved.

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

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

Schema coverage is 0% and the single parameter role_id has no description in the schema. The description adds no meaning about what role_id is, its expected format, or how to obtain it, so the one required parameter is 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?

"Supprimer un rôle" is a clear verb+resource, but the leading token "APERÇU" (preview) directly muddies whether this actually deletes the role or only simulates it. The agent cannot tell the operation mode apart from the sibling modifier_role/creer_role without guessing.

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 use this versus modifier_role (edit) or role_membre (unassign members), and no prerequisite such as permissions or hierarchy checks. The only guidance is an implicit warning about member assignments.

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

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

With no annotations supplied, the description carries the full burden, and it does disclose the key destructive traits: the channel and its messages are removed, the action is irreversible, and a backup restores structure but not messages. It omits permissions required, whether confirmation is needed, and what 'APERÇU' actually changes about 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 sentences, front-loaded with the destructive outcome and its irreversibility. The unexplained 'APERÇU' prefix is the only element that does not clearly earn 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 one-parameter destructive tool with no annotations and no output schema, the description covers the most important risk (permanent loss of messages). It leaves gaps on required permissions, confirmation flow, and the meaning of the preview marker, which an agent would need to call this safely.

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 required parameter, salon_id, with 0% schema description coverage, so the description would ideally clarify its meaning. It only implies the parameter by referring to 'un salon', adding no format or resolution details, but the low parameter count keeps the ambiguity small.

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

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

The description names a specific verb and resource ('Supprimer un salon et ses messages'), which clearly distinguishes it from siblings like creer_salon and modifier_salon. The leading token 'APERÇU' is unexplained and sits oddly next to 'suppression irréversible', leaving some doubt about whether this is a dry-run or a real deletion.

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 alternatives such as modifier_salon or the plan/approval siblings (preparer_plan, executer_plan). The remark about backup hints at a relationship with sauvegarder_serveur but never states a prerequisite or ordering.

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