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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that it authenticates (a login side-effect) and explicitly sends no email, which is useful. It does not say what happens on auth failure or what credentials/config it depends on, so it stops short of rich behavioral 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?

Two short sentences with zero filler, action first and the usage cue second. Every clause earns its place.

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

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

For a no-param, read-only connectivity probe with annotations covering safety, the description is nearly sufficient. It could mention what the check returns (e.g. success/failure per protocol), but with no output schema that omission is minor.

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

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

The tool takes zero parameters, so the description has nothing to disambiguate; the baseline for a no-param tool is 4. No schema gap is left unaddressed.

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 specific actions: logs into IMAP and verifies SMTP authentication, with the clarifying detail that no mail is sent. This distinguishes it from send_message and reply_message, though it does not distinguish it from the similarly-named sibling mail_config_status.

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?

"Úsala antes de organizar" gives a concrete when-to-use context, and "sin enviar correo" implicitly rules out the send path. However, no alternative tool is named for the case where the agent only wants config info (mail_config_status), so the comparison is left to inference.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, already indicating a write operation. The description adds the critical behavioral detail that it saves to the Drafts folder and does not send the email, which is not captured by the annotations and helps the agent avoid confusing this with a send action. However, it does not describe permissions, return values, or side effects on existing drafts.

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 communicate the core action and the key non-send distinction without any filler. The description is appropriately sized for a minimal tool summary.

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

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

For a tool with 7 parameters, no parameter descriptions, and no output schema, the description is far too sparse. It gives no help on how to supply recipients, content, or attachments, making it inadequate for correct invocation beyond the basic purpose.

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 are 7 parameters with 0% schema description coverage, yet the description provides no information about any of them. It does not explain the expected formats for to, cc, bcc, subject, text, html, or attachment_paths, leaving the agent without guidance on how to construct the draft.

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 ('Guarda') and resource ('un borrador') with its destination ('carpeta Drafts'), and explicitly distinguishes it from sending ('No envía el correo'), which separates it from sibling tools like send_message. An agent can identify the core action without opening the schema.

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

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

The phrase 'No envía el correo' implies that this tool should be used when the user does not want to send the message, but it does not explicitly state when to use it versus alternatives such as send_message or reply_message. Usage is implied rather than directly instructed.

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

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

Annotations already declare this as a write operation (readOnlyHint=false) in an open-world context. The description adds the useful side effect that the folder is subscribed, but omits permissions, idempotency, and what happens if the folder already exists.

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 main action and followed by a practical naming note. Every sentence earns its place with 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 mutation, the description covers the core action and a naming convention. It is still missing important mutation context such as failure behavior when the folder exists and whether permissions are required.

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 baseline is 3. The description adds cPanel-specific prefix examples (INBOX.Clientes, INBOX.Facturas) beyond the schema's examples, giving extra naming semantics for that environment.

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: 'Crea una carpeta IMAP' and adds the subscription effect. It is clearly distinct from read-oriented siblings like list_mailboxes, but it does not explicitly name 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?

The cPanel prefix note ('usa un prefijo como INBOX.Clientes') gives useful context for naming, implying when this naming convention applies. However, it does not say when to use this instead of list_mailboxes or other mailbox-management siblings, nor any when-not conditions.

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

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

Beyond the destructiveHint=true annotation, the description discloses real behavior: default operation is a soft move to trash, it is a no-op if the messages are already in the trash, and permanent expunge only occurs when MAIL_ALLOW_EXPUNGE=true and the target is the trash folder. That conditional gating is genuinely useful and not derivable from annotations.

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

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

Three tightly packed sentences with the primary action front-loaded, followed by the idempotency note and the conditional expunge rule. No filler; every sentence carries distinct semantic content.

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

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

For a destructive mutation with no output schema, it covers the soft/hard delete distinction and preconditions but omits what happens when permanent=true while MAIL_ALLOW_EXPUNGE=false (silently ignored? error?), return/response shape, and any indication that move_messages exists as an alternative. Adequate but with clear gaps.

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

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

With 67% schema coverage, the schema documents uids and mailbox, but permanent has no schema description. The description compensates by explaining exactly what permanent=true does and under which two conditions it takes effect, adding meaning the schema lacks.

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 — 'Mueve los UID a la papelera' — which usefully clarifies that the tool named delete_messages is actually a soft-delete move, not an irreversible purge. However, it never distinguishes itself from the obvious sibling move_messages, so an agent cannot tell the two apart from the description alone.

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

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

There is no explicit when-to-use / when-not-to-use guidance and no mention of alternatives such as move_messages. The permanent flag precondition is a behavioral detail, not routing guidance, so the agent must infer when this tool is preferred over its 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?

Adds substantial context beyond the annotations: it discloses the return shape (trimmed plain text plus attachment list), the conditional side effect ('no lo marca como leído salvo mark_seen=true'), and a 2 MB truncation rule that omits the body. This clarifies why readOnlyHint=false despite the read-shaped name; only error/timeout behavior is left unstated.

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, each carrying distinct information (purpose, output, side-effect condition, size limit), with the core action front-loaded and zero filler.

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

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

With no output schema, the description responsibly covers the return contents, the side-effect condition, and a size cutoff, which is close to complete. Minor gaps remain around mailbox defaulting and failure behavior, but nothing critical for a correct call is missing.

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

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

Schema coverage is 50%, with uid and mark_seen already described in the schema. The description reinforces the mark_seen conditional and implies max_chars via 'texto plano recortado', but says nothing about the mailbox parameter, leaving part of the gap uncovered.

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 ('Lee un mensaje por UID') and clarifies the scope as a single-message fetch keyed by UID, which implicitly distinguishes it from list_messages/search_messages. It does not explicitly name any sibling, so it stops short of full differentiation.

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

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

There is no when-to-use guidance and no mention of alternatives such as list_messages, search_messages, or save_attachment. The mark_seen caveat is a behavioral note, not routing guidance, so an agent gets no help deciding when this tool is the right pick.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful context by specifying the returned fields and noting that totals/unread counts are server-dependent, but it does not disclose auth needs, pagination, or failure behavior. This is solid added value but not rich behavioral 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?

One efficiently constructed sentence with the verb and resource front-loaded, followed by the exact returned attributes and a relevant server-side condition. 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?

There is no output schema, so the description must carry return-value information; it does so by naming the path, special-use flags, and optional counts. It is complete for a 0-param read tool, though it omits hierarchy/delimiter details and error behavior.

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

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

The tool takes zero parameters and the schema has no properties, so there are no parameter semantics to clarify. Per the rubric, a 0-parameter tool receives a baseline of 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?

States a specific verb (Lista) and resource (carpetas IMAP) and enumerates the returned attributes (ruta exacta, uso especial, total, no leídos). This clearly distinguishes it from generic status or message tools, but it never names or contrasts with siblings like mailbox_status or unseen_summary, so it misses the top mark.

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 says what the tool lists but gives no explicit when-to-use guidance, no exclusions, and no alternatives. An agent must infer that this is the right tool for enumerating folders, which is the same gap that earned the calibration example update_drive a 2.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by listing what is returned (UID, date, sender, subject, flags, attachment presence) and explicitly stating that the message body is not downloaded. It does not, however, describe pagination or sorting order beyond 'most recent'.

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

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

Two sentences, front-loaded with the core action and scope, followed immediately by the key exclusion ('No descarga el cuerpo'). No filler or repetition.

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

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

For a simple read-only list tool with three fully documented parameters and no output schema, the description supplies the necessary return-field summary and the important non-behavior of not fetching bodies. An agent has enough to invoke it correctly without opening additional context.

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

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

Schema description coverage is 100%, and all three parameters (limit, mailbox, unread_only) are already documented in the schema with constraints and examples. The description adds no parameter-level meaning beyond the schema baseline.

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 ('Lista los mensajes más recientes de una carpeta'), enumerates the returned fields, and implicitly distinguishes itself from body-fetching siblings by saying it does not download the body. An agent can tell this is a metadata-only listing tool.

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

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

The description implies when to use it — for recent-message metadata in a folder — and hints that body retrieval belongs to another tool. However, it does not explicitly name alternatives like get_message or search_messages, nor does it state when not to use this tool.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safe-read nature is covered. The description adds no further behavioral context—no mention of permissions, rate limits, or output format—beyond restating that it counts messages.

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

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

The description is a single concise sentence with the verb front-loaded, making it easy to parse. It is appropriately sized for a simple tool, though it could be marginally more informative without becoming verbose.

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

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

The tool is simple (one parameter, no output schema) and the description conveys the core counting behavior. However, it does not specify the return format or what 'recent' means, leaving some ambiguity for an agent that needs to interpret the output.

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

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

Schema description coverage is 100%, and the single parameter 'mailbox' is fully documented in the schema. The description adds no syntax or format details beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb (Cuenta) and resources (mensajes, no leídos, recientes) scoped to a folder. It is clear but does not explicitly differentiate from similar siblings like unseen_summary or list_messages.

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 guidance is provided on when to use this tool versus alternatives such as unseen_summary or list_messages. The description only states what it does, leaving the agent to infer usage context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds valuable behavioral context: it returns public configuration without the password, and it reports which variables are missing. These are useful security and output-content details beyond the annotations.

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

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

A single sentence that is front-loaded with the core action and includes only relevant details. No waste or repetition.

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

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

For a zero-parameter, read-only status tool with no output schema, the description adequately explains what is returned: public configuration, omitted password, and missing variables. It could optionally mention the response shape, but it 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 tool has zero parameters, so the baseline is 4 per the rubric. There are no parameter semantics to clarify in 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?

States a specific verb and resource: 'Muestra la configuración pública del correo' (shows public mail configuration). Adds key details about excluding the password and indicating missing variables. Does not explicitly differentiate from siblings like check_connection or mailbox_status, but the resource focus is clear.

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 guidance on when to use this tool versus alternatives such as check_connection or mailbox_status. Implied usage is to inspect mail configuration, but there are no explicit conditions, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so safety profile is covered. The description adds one useful behavioral fact — the destination must pre-exist — but says nothing about what happens to the source copies, partial failure on the 50-UID cap, or what is returned.

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

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

Two short sentences, zero filler, with the core action front-loaded and the prerequisite/alternative trailing. Every sentence earns its place.

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

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

For a 3-parameter, all-required mutation tool with no output schema, the description covers the operation and its key precondition. It omits error/partial-failure behavior and result reporting, but the essential call requirements are 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 67%: uids and mailbox carry their own descriptions (including the valuable 'UID de IMAP, no el número de secuencia' note), while destination only has a $ref. The description reinforces UID semantics and the existence requirement for destination but adds little beyond the schema, matching the baseline 3.

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

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

States a specific verb (mover) plus resource (mensajes) and scope (por UID, de una carpeta a otra), which cleanly separates it from delete_messages, set_flags, and search_messages among the siblings. An agent knows exactly what operation this performs.

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 clear precondition (the destination folder must already exist) and routes the agent to a specific sibling (create_mailbox) to satisfy it. It does not state when to prefer this over alternatives like delete_messages or copy, so it falls short of full when/when-not guidance.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true. The description adds genuinely new behavioral facts: a configuration gate (MAIL_ALLOW_SEND=true) and two side effects (quoting the original, flagging the message as replied). It still doesn't say whether the reply is sent immediately or drafted.

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 no filler; the core action comes first, then the preconditions. Every clause carries information.

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

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

For a mutation tool with no output schema, the preconditions and side effects are covered well enough to call it safely. The gap is parameter-level: mailbox selection and reply_all semantics are unexplained.

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

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

Schema coverage is only 25% (only 'mailbox' is documented), so the description must compensate. It covers uid and the reply text implicitly, but says nothing about 'mailbox' or 'reply_all', leaving half the parameters undocumented in either place.

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 ('Responde a un UID') plus two distinguishing behaviors — quoting the original text and marking it as replied — which separates it from send_message and create_draft. It stops short of explicitly naming the sibling it is not, so it misses the top level.

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 clear precondition for invocation: the config flag MAIL_ALLOW_SEND must be true and the person must have made an explicit request. That is real when-to-use guidance, though it never contrasts with send_message or create_draft as alternatives.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the write-to-filesystem nature is already flagged. The description adds genuinely useful behavior not in annotations: the directory must already exist, and the filename is sanitized so it cannot escape that directory (path-traversal protection). It omits error/return behavior but adds meaningful side-effect context.

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

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

Three terse sentences, each earning its place: the action, the prerequisite/parameter source, and the safety guarantee. Front-loaded with the core action and 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?

No output schema exists, so the description should ideally state what is produced (e.g. saved file path) and what happens on failure. It covers the main hazard (directory existence, sanitization) but leaves the result and error behavior unspecified.

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

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

Schema description coverage is only 25% (only mailbox documented), so the description must compensate. It explains the index source (get_message) and the output_directory constraint (must exist), which helps, but the uid parameter is never addressed and no format hints are given for the path parameters.

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

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

States a specific verb+resource ('Guarda un adjunto en un directorio local'), and adds the key constraint that the directory must already exist. It also names the sibling get_message as the source of the index, giving partial sibling differentiation. It does not distinguish itself from the other siblings beyond that dependency.

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 states the prerequisite that the output directory must pre-exist and that the index is obtained from get_message, which effectively documents the required call sequence. No explicit when-not-to-use or alternative is given, but the usage context is clear.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine behavioral context beyond that: the mandatory-criterion constraint and the return ordering ("Devuelve los UID más altos, que en cPanel suelen ser los más nuevos"), which tells the agent how results are sorted. Not exhaustive, but a real addition over the annotations.

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

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

Four short sentences, front-loaded with the core action and the hard constraint, with zero padding. Slight redundancy with the schema's date descriptions, but otherwise tight.

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 10-parameter tool with 50% schema coverage and no output schema, the description covers the criterion requirement and result ordering, which is helpful since there is no output schema. But it omits guidance for the undocumented parameters and any routing versus list_messages, leaving meaningful gaps.

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

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

Schema coverage is only 50% across 10 parameters, so the description must compensate more than it does. Its date info ("since y before usan YYYY-MM-DD") largely duplicates the schema descriptions, and it adds nothing for mailbox, limit, text, flagged, or subject. Marginal value over the schema.

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

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

"Busca dentro de una carpeta" states a clear verb+resource and adds the requirement of at least one criterion. However, it never distinguishes itself from the sibling list_messages, so an agent cannot tell from the text alone why it would pick search over list. Clear purpose, absent sibling differentiation.

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

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

"Exige al menos un criterio" implies usage (call this when you have a filter criterion), but the description gives no explicit when-to-use/when-not guidance and never names an alternative such as list_messages or unseen_summary. Usage is only inferred from the constraint.

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

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

Annotations only cover readOnlyHint=false and openWorldHint=true, so the description carries the interesting detail: a configuration-gated failure mode (MAIL_ALLOW_SEND) and the side effect of writing a copy to Sent. The explicit-request constraint is valuable behavioral context. It stops short of full disclosure (no rate limits, attachment handling, or return/failure detail beyond the one flag).

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

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

Two tightly written sentences, zero filler, with the operational constraint and the consent gate front-loaded where an agent will see them first.

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

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

For a mutation tool with no output schema, the description covers the critical behavioral facts (failure gate, Sent-copy side effect, consent requirement), which is genuinely useful. But it leaves the nine-parameter surface entirely undocumented beyond the schema's terse field names, so an agent lacks guidance on composing a valid 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?

Nine parameters with only 11% schema description coverage, and the description adds nothing about any of them — no mention of to/cc/bcc semantics, html vs text precedence, references/in_reply_to threading, or the 5-attachment cap. With coverage this low, the description was obligated to compensate and does not.

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

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

States a specific verb and resource ('Envía un correo por SMTP') plus two concrete behaviors: SMTP transport and saving a copy to Sent. That distinguishes it from siblings like create_draft or reply_message, though those alternatives are never named, so the differentiation is inferred rather than explicit.

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 hard precondition gate ('Falla si MAIL_ALLOW_SEND no es true') and an explicit usage restriction ('No lo uses sin un pedido explícito de la persona en este turno'). Strong when-to-use guidance, but it never routes to the sibling that should be used instead (create_draft, reply_message).

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and openWorldHint=true, covering the mutation and safety profile. The description adds only a list of flag names, which duplicates the schema enum, and says nothing about permissions, how add and remove interact, or that 'deleted' is a flag rather than an actual deletion.

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

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

A single sentence front-loads the action ('Añade o quita banderas') and then lists the flags. It is efficient, though the parenthetical glosses for some flags are arguably redundant with the schema enum.

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 mutates IMAP flags across up to 50 message UIDs with four parameters and no output schema. The description omits when to use it versus siblings, how add and remove arrays combine, and what happens to unspecified flags, leaving significant context gaps despite the annotations covering idempotency and mutation.

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

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

Schema description coverage is 75%, so the schema already documents the purpose of 'uids' and 'mailbox' (and the enum for 'add'/'remove'). The description gives Spanish glosses for the flag values but adds no syntax, constraints, or interaction details beyond what the schema provides, matching the baseline 3 for high coverage.

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 (adds/removes) and resource (flags) and enumerates the available flags, making the tool's purpose clear. It does not explicitly differentiate itself from sibling tools such as delete_messages or move_messages, so it lacks the sibling-aware precision 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?

The description offers no when-to-use guidance, no prerequisites, and no mention of alternatives like delete_messages or create_draft. It implies that the tool manages flags but leaves the agent to infer when to call it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe read-only nature is covered. The description adds that it filters to only folders with unread messages, which is useful behavioral context, but it does not describe the return shape or any pagination details.

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 no wasted words. The core behavior is front-loaded, and the secondary usage hint follows immediately without bloating the definition.

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

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

For a zero-parameter, read-only summary tool with annotations covering the safety profile, the description is mostly complete. It could clarify whether the result is a list of folder names, unread counts, or both, but an agent can still select and invoke it correctly.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The schema coverage is 100% and the description needs no additional parameter detail, making the baseline of 4 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 and resource: returns only folders that contain unread messages. It is clear what the tool does, but it does not explicitly distinguish itself from siblings like list_mailboxes or mailbox_status that also return mailbox-related data.

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 'Es el punto de partida para organizar' implies this is used as an initial organizing step, which gives some usage context. However, it does not state when not to use it or name alternative sibling tools for other mailbox views.

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