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 usefully discloses the subscribe default and the account default resolution, but says nothing about idempotency if the folder already exists, permission requirements, or error behavior 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 one-line purpose is front-loaded, and the Args block is structured and dense. It is documentation-styled rather than terse, but every line adds information, so little 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?

An output schema exists, so return values need not be described, and all three input parameters are covered. The remaining gap is mutation-specific behavior (permissions, duplicate handling), which is a modest omission for a simple create tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains all three parameters, the nested-folder separator convention with examples, the subscribe default (True), and how 'account' maps to credentials.json. This is meaningful meaning beyond the bare schema types.

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 ('Create a new mailbox folder'), which is unambiguous and distinct from read-only siblings like sch_list_folders. It does not explicitly differentiate itself from other folder operations, but the purpose is clear 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?

Usage is largely implied rather than stated – no when-to-use/when-not or reference to alternatives. The Args block does give practical guidance (separator conventions for nested folders, account default resolution), which nudges it above pure 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 behavioral burden. It usefully discloses the allowed-directory restriction, default output directory, case-insensitive filtering, and account default logic, but it omits key mutation behaviors such as whether existing files are overwritten, error handling, or permission requirements.

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

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

The purpose is front-loaded in the first sentence, followed by a well-organized Args block. Every sentence adds value, with no redundancy or filler.

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

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

Given five parameters, full schema coverage in the description, and an output schema that handles return values, the definition is largely complete for invocation. It still lacks some behavioral context expected when no annotations are present, such as overwrite semantics or failure modes.

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 thoroughly. Each of the five parameters is explained with its source, default, or constraint (e.g., msg_id UID source, out_dir allowed folders, filename_filter substring behavior, account key file).

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 sentence gives a specific verb (Download) and resource (attachments from a message) and destination (to disk), clearly distinguishing this tool from siblings like sch_get_mail or sch_search_mail. An agent can immediately tell what the tool does 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?

It provides clear context by stating that msg_id comes from sch_list_mail / sch_search_mail, and it documents defaults for folder, out_dir, and account. However, it does not explicitly state when to use this tool versus alternatives or any conditions where it should not be used.

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 full behavioral burden. It discloses the critical draft-vs-dispatch behavior via send_now, attachment preservation, and the account default resolution from credentials.json. It doesn't mention permissions or rate limits, but covers the key state-changing 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?

A front-loaded purpose sentence followed by structured Args and Returns sections. Every line adds parameter value rather than padding. Slightly verbose but earns its length given 8 undocumented params.

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?

Despite output schema existing, the description still notes what is returned (status, subject, attachment count, message id). Given 8 params at 0% schema coverage and no annotations, the description covers all the info an agent needs to call this mutation correctly.

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

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

Schema description coverage is 0%, so the description must fully compensate and it does: each of the 8 params is explained with meaning, format (comma-separated), default (INBOX, Drafts), and the account key example. This is exactly the compensation 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 ('Forward an existing message to new recipient(s)') plus a distinguishing behavioral trait ('preserving attachments'). This clearly separates it from siblings like sch_send_mail or sch_move_mail.

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 by tying msg_id to sch_list_mail/sch_search_mail as sources and explaining the send_now draft-vs-send behavior. It doesn't explicitly state when to use this over sch_send_mail, but the context is clear enough for selection.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: default folder INBOX, body format choices, a 5000-char truncation default, and how the account key resolves via credentials.json. The notable omission is whether reading marks the message as read (an IMAP side effect) or what permissions are needed.

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 gives the purpose, followed by a compact Args list; no filler and every line carries parameter information the schema does not.

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?

An output schema exists so return values need not be described, and the parameters are fully covered. What remains thin is the safety/side-effect profile for a read over IMAP and any explicit routing away from the attachment and stats 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 fully, and it does: every one of the five parameters (msg_id, folder, body, max_body_chars, account) is documented with type, accepted values, default, and provenance. The 'body' enum-like options and account example add meaning the bare 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 ('Read a specific message by UID') and immediately ties the UID to its origin tools (sch_list_mail / sch_search_mail), which lets an agent distinguish this from the list/search siblings without opening a 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 description establishes the required context: msg_id must come from sch_list_mail or sch_search_mail, so the agent knows this tool is a follow-up read after enumeration. It stops short of explicit when-not guidance (e.g., use sch_download_attachments for attachment retrieval).

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. It usefully discloses that folder names are returned and that the account resolves via credentials.json with a "default" key when omitted, but says nothing about read-only safety, authentication failures, or folder hierarchy/pagination 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?

Front-loaded with the core purpose in one short sentence, followed by return info and parameter guidance. Slight redundancy between "List all mailbox folders" and "Returns folder names available in the sch.gr mailbox," 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 one-parameter read tool with an output schema present (so return structure needn't be explained), the description covers purpose and the account-selection mechanic. Only multi-mailbox edge cases and error conditions are unaddressed.

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

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

Schema description coverage is 0%, yet the description fully explains the single parameter: it is a key in credentials.json (e.g. "work"), and omission resolves to the "default" account. This compensates well for the missing schema documentation, though it doesn't state the error behavior for an unknown key.

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 ("List all mailbox folders") plus the concrete return (folder names in the sch.gr mailbox). It is clearly distinguishable from write siblings like sch_create_folder or mail siblings like sch_list_mail, though that separation is inferred rather than stated 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 description gives no when-to-use framing relative to alternatives (e.g. using this before sch_move_mail or after sch_create_folder); the only guidance is for the account parameter. Usage is implied by the listing nature of the tool, so it lands at minimum viable.

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 add real behavioral context: the 'id' is an IMAP UID that is stable across calls (unlike a sequence number) and is the value every msg_id parameter expects, plus which credentials file/account governs the call. It omits rate limits, ordering guarantees, or empty-result behavior, but the UID stability note is genuinely useful information not available elsewhere.

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 primary action is front-loaded in sentence one, the important UID caveat follows, and the Args block is a compact per-parameter reference. No sentence is redundant or 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?

For a read-only listing tool with an output schema present, the description need not explain return shape, and it correctly focuses on parameters and the id semantics that link output to other tools. Minor gaps remain (no statement about empty results or what happens if the folder is missing), but nothing essential for a correct call is absent.

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 for all four parameters: folder default INBOX, top default 20 with a 100 maximum, the YYYY-MM-DD format and 30-day default for since, and the account key convention with its default resolution rule. This is exactly the information the bare 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?

The first sentence gives a specific verb and resource ('List recent messages') plus the concrete fields returned (subject, sender, date, attachment indicators), which distinguishes it from sch_get_mail and sch_search_mail implicitly. It never names the alternatives, so an agent must infer the routing, but the purpose itself is unambiguous.

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

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

The default 30-day 'since' window and 'recent messages' framing imply when this listing tool is appropriate versus a search, but there is no explicit when-to-use or when-not-to-use statement and no sibling is named. 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?

No annotations are provided, so the description carries the full burden. It discloses what is returned (counts, date range) and implies a read-only operation, but never states that it is non-mutating, what permissions/auth it needs, or whether it hits the network per call. Partial disclosure only.

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?

Front-loaded one-line summary followed by a compact args list; every line earns its place given the zero-coverage schema. Slightly verbose but no waste.

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?

An output schema exists, so return format need not be re-explained, and both parameters are documented in the description despite 0% schema coverage. Only the read-only/auth profile is left implicit for a zero-annotation tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it documents folder's default (INBOX) and explains account as a credentials.json key with an example ('personal'/'work') and a default-resolution rule. This meaningfully exceeds the bare schema.

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

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

States a specific verb+resource ('mailbox statistics') and enumerates the outputs (total messages, recent/unseen counts, date range). This clearly differentiates it from the sibling list/get/search mail tools, though it does not name a sibling explicitly.

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

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

The word 'Quick' hints that this is a lightweight summary, but there is no explicit when-to-use guidance and no mention of when an agent should prefer sch_list_mail or sch_search_mail instead. Usage must be inferred entirely.

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, and it delivers unusually good behavioral detail: it discloses the server-capability fallback chain (UID MOVE vs. UID COPY + \Deleted + UID EXPUNGE vs. bare EXPUNGE). It omits reversibility, permission/authentication requirements, and error behavior when the move fails partway.

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 core action is front-loaded in the first sentence, followed by implementation detail and then an Args block. The IMAP fallback sentence is the only slightly dense part, but it earns its place by explaining non-obvious server-dependent behavior.

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 an output schema present, return values need not be described, and the description covers the remaining gaps: prerequisites, addressing constraints, defaults for both optional parameters, and the fallback execution path. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must fully compensate, and it does: msg_id is specified as a single UID with ranges/lists explicitly refused, dest_folder is the target name, source_folder defaults to INBOX, and account is explained as a credentials.json key with its own default resolution rule.

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 sentence states a specific verb (Move), a precise resource (one message), and both endpoints (source_folder to dest_folder), with the addressing scheme (UID) called out. It is immediately distinguishable from siblings like sch_send_mail or sch_get_mail 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?

It explicitly routes the agent to siblings for prerequisites: use sch_create_folder if the destination does not exist, and msg_id comes from sch_list_mail / sch_search_mail. It does not state any when-not-to-use conditions (e.g., that it cannot move multiple messages), so it falls just short of full 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 provided, so the description carries the full burden. It discloses useful operational detail — result ids are IMAP UIDs, folder defaults to INBOX, and account defaults to the 'default' entry in credentials.json — but never states that this is a read-only operation, nor addresses rate limits, permissions, or result ordering/pagination.

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

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

Front-loaded purpose sentence followed by a compact Args block; each parameter line is a single clause with no waste. The docstring-style layout is slightly verbose relative to a prose summary but remains tight and scannable.

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?

An output schema exists so return values need not be explained, and the description still usefully clarifies that ids are IMAP UIDs. Combined with the full parameter documentation and default-resolution rules, it covers what an agent needs, though it omits read-only/behavioral guarantees.

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

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

With 0% schema description coverage the description must do all the work, and it does: every one of the six parameters is documented with meaning and defaults, including the enumerated field values ('subject','from','body','all') that the schema lacks entirely, the YYYY-MM-DD date format for 'since', and the credentials.json account-key semantics.

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 ('Search messages') and the searchable fields (subject, sender, body), and differentiates itself from siblings by noting result ids are IMAP UIDs identical to what sch_list_mail returns. An agent can distinguish this from sch_list_mail and sch_get_mail without opening any schema.

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

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

The tool's purpose implies its use case (keyword lookup vs listing), and the UID note hints at how it relates to sch_list_mail, but there is no explicit when-to-use/when-not statement or named alternative for retrieval-by-id (sch_get_mail). Usage is inferred 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 full burden and does well: it discloses the atomic attachment-validation rule (missing or out-of-allowed-dir file fails the whole call, nothing saved or sent), the allowed-dirs default and SCH_MAIL_ALLOWED_DIRS override, and account resolution from credentials.json. Auth mechanics and any rate limits are not spelled out, but failure semantics and defaults are unusually well covered.

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?

Purpose is front-loaded in one sentence, then a clean per-argument list where each line earns its place. The attachments entry is long, but that length buys genuinely load-bearing failure-mode information rather than padding.

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

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

For a 9-parameter mutation tool with zero schema coverage and no annotations, nothing critical is missing: modes, defaults, attachment constraints, account selection, and failure behavior are all present. The brief return summary ('draft_saved' or 'sent', folder/recipients, message id) is mildly redundant against the output schema but harmless.

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% across 9 parameters, so the description must compensate – and it does. It defines formats and examples for every parameter: comma-separated recipient lists with an example ('a@x.gr,b@y.gr'), html's effect on body, attachments as absolute paths with validation rules, send_now's default, and account's default key resolution.

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 ('Send a new email via SMTP') plus the key mode switch ('or save as draft (default)'). The word 'new' implicitly separates it from sch_forward_mail, so an agent can route between the two send-family tools without opening a schema.

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

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

Gives clear operational context: the default is a draft and send_now=True dispatches it, which is the main decision an agent must make. It does not name alternatives or state when-not to use it (e.g. vs sch_forward_mail), so it stops short of full routing guidance.

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