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

With no annotations, the description carries the full burden. It does this well: it states the action is irreversible ('ACTION IRRÉVERSIBLE'), that it actually forwards (not simulates), and mandates user confirmation. These are key behavioral traits. It does not disclose side effects like whether the original email is modified, but for a forwarding action this is minor. Overall it provides substantial behavioral context beyond the schema.

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

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

The description is two sentences with zero fluff. It front-loads the most critical warning ('ACTION IRRÉVERSIBLE') before stating the purpose, then adds the mandatory confirmation requirement. Every word earns its place, making it both concise and structurally effective.

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

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

The description covers the essential context for a mutation tool: irreversibility, the need for user confirmation, and the core action. It does not explain return values or error behavior, but with no output schema and a simple operation, these are not critical for correct invocation. The main practical uncertainty – how to get itemId – is handled by sibling tools. A small gap is not specifying what happens to the original email, but this does not impede usage.

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% – all three parameters (to, itemId, comment) already have clear schema descriptions. The tool description adds no additional meaning for the parameters, so it does not go beyond what the schema provides. Per the rubric, when schema coverage is high, baseline is 3, which is appropriate 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 states a specific action: 'transfère réellement un email existant à un nouveau destinataire' (actually forwards an existing email to a new recipient). It clearly distinguishes this from siblings like send_email (creating a new email) and reply_to_email (replying), without needing to open the schema. The verb 'transfère' and resource 'email' are unambiguous.

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

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

The description gives explicit guidance: it is irreversible and the agent MUST always ask for explicit confirmation of the recipient and comment before calling. This is a strong usage constraint that tells when to pause and verify. However, it does not explicitly name alternative tools or state 'use this instead of send_email when forwarding an existing email,' so it misses the explicit sibling differentiation that would earn 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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses the return of base64-encoded content and listing metadata, which is helpful, but it does not mention error handling, permissions, rate limits, or side effects. For a read-only listing/download operation, this is adequate though not exhaustive.

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 concise sentences with no wasted words. The conditional (without/with attachmentId) is front-loaded, making the decision path immediately clear. It is well-structured for quick parsing.

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

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

Given only two parameters and no output schema, the description covers the essential behavior: what each mode returns and the required context (itemId). It omits potential error messages or pagination details, but for a simple tool this is 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?

The schema covers both parameters with clear descriptions (100% coverage), and the description adds the crucial conditional logic that not only defines each parameter's role but explains how they interact. This goes beyond the schema's static field descriptions, providing actionable semantics for an agent.

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

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

The description clearly states a specific behavior: without attachmentId it lists attachments (with name, type, size, id), with attachmentId it downloads the content base64-encoded. This directly matches the title 'Lister ou télécharger les pièces jointes' and distinguishes the two modes unambiguously.

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 explains precisely when to use each mode (with or without attachmentId), which is exactly the usage guidance needed. However, it does not explicitly mention alternatives or when not to use this tool, but the sibling tools clearly cover different operations, so the context is 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does say what the tool returns (full email content, recipients, attachments), but it does not disclose side effects, authentication needs, or whether attachments are inline vs. handled separately by get_attachments.

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, efficient French sentence that front-loads the verb, identifies the resource, enumerates key content, and specifies the input source. Every element contributes value; 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 simple one-parameter fetch tool, the description is mostly complete: it names the key return elements and the parameter schema covers the input workflow. The main gap is the ambiguous relationship with get_attachments and the lack of any note about attachment representation or output format.

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

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

Schema description coverage is 100%, and the schema already explains that itemId is an EWS identifier obtained via search_emails. The tool description adds no additional parameter semantics, so the baseline of 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 clearly identifies the operation: 'Récupère le contenu complet d'un email' and specifies the resource and output components (corps HTML, destinataires, pièces jointes). It is distinct from most siblings like search_emails, send_email, and update_email, but the explicit mention of pièces jointes blurs the boundary with get_attachments without resolving 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?

Usage context is implied rather than stated: the main description says 'à partir de son identifiant', and the parameter schema adds that itemId is 'obtenu via search_emails', which implies a search-then-fetch workflow. However, there is no explicit guidance about when to prefer this over get_attachments or other 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 provided, the description carries the full behavioral disclosure burden. It clearly indicates a read-only enumeration action and specifies the returned information (folder names plus unread email counts). It does not mention pagination or ordering, but for a simple listing tool the behavior is transparent enough.

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, well-structured sentence that front-loads the action and resource, then provides illustrative examples and the key output detail. Every word contributes value with no 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?

This is a simple, parameterless tool with no output schema, and the description fully covers what an agent needs to call it correctly: it lists all folders and includes unread counts. There is no missing prerequisite, permission, or return-value information that would materially affect 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?

The tool has zero parameters, so there is nothing for the description to clarify beyond the schema. Per the baseline for zero-parameter tools, this is adequate, and the description adds useful context about what the output includes.

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

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

The description uses the specific verb 'Énumère' (enumerates) and identifies the resource as all mailbox folders, listing examples such as Inbox, Sent Items, Drafts, and custom folders. It also adds the distinguishing output detail of unread email counts, which clearly separates it from the email-focused sibling tools.

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

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

The description implies usage when an agent needs a folder overview, and the sibling tools are all email operations, making this the only folder-listing tool. However, it does not explicitly state when to choose this over alternatives or provide any exclusion criteria, so usage guidance is only implied 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?

With no annotations provided, the description carries the full burden. It discloses the irreversible nature and the real sending effect, which is critical behavioral context. It also warns about the confirmation requirement. However, it does not mention any side effects like what happens to the original email or whether it updates status, but for a simple reply action, this is adequate. The irreversibility warning is a strong disclosure.

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, purpose-built sentence that front-loads the critical warning about irreversibility and the mandatory confirmation step. There is no fluff or redundancy; every word earns its place. The structure is efficient and immediately conveys the core message.

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

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

Given the tool's simplicity (3 parameters, 2 required), no output schema, and no annotations, the description effectively covers the essential contextual elements: it states the action, stresses irreversibility, and mandates user confirmation. The parameter details are already in the schema, so nothing essential is missing. It could have mentioned the replyAll option, but the schema covers it, so this is 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 coverage is 100%, so the schema already documents all three parameters (body, itemId, replyAll) with descriptions. The tool description does not add any additional meaning beyond what the schema provides. Since the schema is complete, a baseline of 3 is appropriate; the description does not need to repeat parameter details.

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

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

The description clearly states the action: sending a real reply to an existing email. It uses a specific verb ('envoie') and identifies the resource ('un email existant'). It also distinguishes itself from siblings like forward_email or send_email by emphasizing 'réellement' (really) and the irreversibility, setting it apart as the actual sending 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?

The description explicitly mandates that the agent must always ask explicit confirmation from the user before invoking this tool, specifying both content and the reply/Reply All choice. This provides a strong usage guideline, though it does not explicitly compare with alternatives. The warning is clear and actionable, making it a high-quality usage 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?

The core behavior is disclosed: this is a listing/search operation scoped to a folder with an optional filter. With no annotations present, the description carries the burden, and it does not explicitly mention read-only status, returned fields, sorting, or pagination. This is a moderate gap for a low-risk read 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 a single front-loaded sentence with no filler. It communicates the resource, scope, and optional filter 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?

The description gives enough to invoke the tool correctly: folder scope and optional filter. However, there is no output schema and the description does not mention what fields are returned, pagination behavior, or default sorting. This is adequate but not 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 100%, so the schema already documents all three parameters (query, folder, maxResults). The description adds no parameter-level meaning beyond what the schema provides, so the baseline score of 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 states a specific verb ('Liste') and resource ('emails d'un dossier Exchange'), and adds the optional AQS filter. This clearly distinguishes it from siblings like get_email (single email), send_email, and list_folders.

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

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

The description makes the usage context clear: list emails in a specified Exchange folder, optionally filtered by AQS. However, it does not explicitly say when to prefer this over get_email, get_attachments, or list_folders, so guidance is implied 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?

With no annotations, the description carries the safety burden and does so well: it flags the action as 'ACTION IRRÉVERSIBLE' and emphasizes that the email is actually sent, not staged or simulated. It could add more about failures or side effects, but the key irreversible behavior is disclosed.

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 most important warning placed first in uppercase. Every word is functional 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?

Given that this is a destructive send action with no annotations and no output schema, the description covers the critical pre-call requirement and the irreversible nature. It does not describe the response or failure modes, but for a send tool the main risk and required protocol are well 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?

The input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds that recipient, subject, and content must be confirmed, but does not add new parameter-level semantics beyond the schema.

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

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

The description states a clear action: 'envoie réellement un nouvel email' (actually sends a new email). It is distinct enough from reply/forward siblings by specifying a new email, but it does not explicitly name those alternatives.

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

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

It provides an explicit precondition: the agent must always get user confirmation of recipient, subject, and content before calling. It does not, however, explain when to prefer this tool over reply_to_email or forward_email, so it stops 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the mutation actions ('marks as read/unread and/or moves') but does not disclose potential side effects, such as whether moving removes the email from the original folder, whether the folder must already exist, or what happens if only itemId is provided without optional parameters. This is a significant transparency 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?

The description is a single sentence that directly captures the two main supported operations. It contains no fluff, redundant phrasing, or extraneous details. The structure is appropriately concise and front-loaded.

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

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

With no annotations and no output schema, the description is adequate but leaves gaps. It does not clarify behavior when optional parameters are omitted, whether both actions can be combined safely, or constraints on folder names. The schema covers parameter meanings, so the tool is callable, but some edge-case behavior remains ambiguous.

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 input schema has 100% description coverage, so the structure already documents itemId, markAsRead, and moveToFolder fully. The description adds no extra parameter semantics beyond restating the two actions. Baseline 3 is appropriate because 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 states a clear, specific action: 'Marks an email as read/unread and/or moves it to another folder.' This distinguishes it from sibling tools like send_email, get_email, search_emails, and list_folders, which serve different operations. The verb and resource are explicit, so an agent can immediately understand what the tool does.

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 when to use the tool (when updating an email's read state or folder location), but it does not explicitly state exclusions or alternatives. No mention of 'use send_email for sending' or 'use get_email for reading' appears. The usage context is clear but left to inference rather than explicit guidance.

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