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

readOnlyHint=true already establishes the safe-read profile, and the description adds real behavioral context beyond it: what is included (unread count, summaries), what is deliberately excluded (bodies), and the bounded result size. Missing only notes on truncation/pagination behavior at the limit ceiling.

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 whole contract, followed by a tight Args block that is justified given the zero schema coverage. Slight redundancy in restating the schema's default values, but no 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?

With an output schema present, return values need no explanation, and readOnlyHint covers safety. The description supplies purpose, content scope, and all three parameters, leaving only minor gaps such as how the unread count is derived or behavior at the limit boundary.

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

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

Schema description coverage is 0%, so the description carries the parameter burden and does document all three: folder as target, days as the window, limit as the digest size. It also supplies the 1-100 range that is absent from the schema, though the stated defaults merely duplicate schema values.

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 (digest of a folder) and pins down the exact payload: unread count plus recent message summaries with subjects and senders only, no bodies. This implicitly separates it from read_email/list_emails, but no sibling is named explicitly, so it stops short of a 5.

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

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

The 'compact digest' framing implies the right moment (a quick overview rather than fetching full messages), but the description never states when to prefer this over list_emails or search_emails, nor any exclusions. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent knows this writes a file but is non-destructive. The description adds genuinely useful context (the file lands in the local sandbox directory, and the filename defaults), but it never explains the non-idempotent behavior, e.g. what happens if the target file already exists or whether an existing file is overwritten.

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 single lead sentence is front-loaded with purpose, format, and destination, followed by a compact Args list for the three parameters. No filler or repetition; only the arg restatement of types is mildly redundant.

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 no explanation, and the description covers purpose, destination, and all three parameters. The remaining gap is overwrite/collision behavior for a non-idempotent write, which is a minor omission for this tool's complexity.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely does: it defines message_id as the Message-ID, folder as the containing folder, and filename as optional with a stated default (Message-ID plus .eml) that goes beyond the schema's bare default of null. The folder default of INBOX is left to the schema, so it is not fully exhaustive.

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 (export), resource (a full message), output format (.eml), and destination (the local sandbox directory), which clearly separates it from read_email and save_attachment. It does not explicitly name a sibling or contrast itself with them, so it stops short of a 5.

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

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

Usage is only implied: an agent can infer this is for materializing a raw .eml file locally rather than reading content in-context. There is no explicit when-to-use statement, no condition for choosing it over read_email or save_attachment, and no 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?

readOnlyHint=true already declares this as a safe read, so the description only needs to add context beyond that. 'Without fetching messages' usefully signals a lightweight operation that avoids downloading bodies, but there is no mention of performance, caching, or failure modes for a non-selectable folder.

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 plus a single tight Args line; no filler or restatement of the tool name.

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

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

With an output schema present, return values need not be explained, and the description covers the one parameter's behavior. It is nearly complete for this simple tool, only lacking explicit routing to sibling tools.

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%, so the description carries the burden for the single folder parameter and does so clearly: a single folder name, or omit for all selectable folders. This adds real semantics (singular name, null means 'every selectable folder') that the bare string/null schema does not convey.

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

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

States a specific verb and resource ('counts of total and unread messages per folder') and adds the scoping qualifier 'without fetching messages', which implicitly separates it from list_emails/read_email. It does not name a sibling explicitly, so it falls just short of 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 Args note tells the agent that omitting the folder returns every selectable folder, which implies efficient bulk use. However, there is no explicit when-to-use-this-vs-alternatives guidance (e.g. use this instead of list_emails to get counts cheaply).

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 readOnlyHint annotation only covers safety. The description adds rich behavioral context: the thread-reconstruction strategy, All Mail search scope, fallback to the containing folder, chronological ordering, and the 1-100 limit range.

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 sentence is front-loaded, and the Args list is compact and directly useful. Every sentence adds operational detail without 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?

An output schema exists, so return values need not be explained. With annotations covering read-only safety and the description covering search scope, fallback, ordering, and parameter constraints, an agent has everything needed to call 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?

Schema description coverage is 0%, so the description must compensate fully. It documents all three parameters: message_id as any message in the thread, folder as a fallback if All Mail is absent, and limit as a 1-100 maximum.

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: reconstructs a conversation/thread around a message. It also names the mechanism (References/In-Reply-To) and search scope (All Mail), making it distinguishable from siblings like read_email and search_emails.

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?

Clear context: call it with a message_id from any message in the thread to retrieve the full conversation. It does not explicitly name the sibling alternatives or state when-not-to-use conditions, so it falls short of full explicit 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 already declare readOnlyHint=true, and the description reinforces this with 'without saving anything to disk', plus discloses what the result contains (attachment names, content types, sizes). It adds useful behavioural context beyond the annotation, though it says nothing about permissions or failure modes.

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 purpose and the no-disk-write constraint are front-loaded in one efficient sentence; the trailing Args block is mildly redundant formatting but adds no padding. Nothing 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?

With an output schema present, return values need not be described, yet the description helpfully indicates the metadata fields. Both parameters and the read-only nature are covered; only auth requirements and error behaviour are absent, which is acceptable for this simple listing tool.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden — and it does, defining message_id as the Message-ID and folder as the folder containing the message. The only gap is that the INBOX default is left to the schema rather than restated.

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 (List) and resource (a message's attachments) and immediately scopes the output to metadata — names, content types, sizes — which cleanly separates it from save_attachment in the sibling set.

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 'without saving anything to disk' signals the read-only context and implicitly contrasts with save_attachment, giving clear usage context. However, it never names the alternative tool or states an explicit when-to-use condition, 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?

The readOnlyHint=true annotation already establishes the safety profile, so the bar is lower. The description does add real behavioral value beyond annotations: newest-first ordering and, importantly, the cursor contract ('Cursor from a previous page's next_cursor to continue listing'), which reveals pagination. It still says nothing about how multiple filters combine or result caps.

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 summary sentence is front-loaded before the Args block, and each argument line earns its place given zero schema coverage. The docstring-style enumeration is slightly formulaic but contains 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?

An output schema exists, so return values need not be described, and the readOnly annotation covers safety. The description adds ordering and pagination, the two things structured fields do not cover. Minor gaps: the default folder of INBOX and whether filters are AND-combined are not stated.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does so: every one of the seven parameters gets a meaning, including match semantics ('From header contains this text'), the 1-100 bound on limit (absent from the schema), and the next_cursor round-trip for 'before'. This is substantially more than the schema names provide.

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 the most recent messages of a folder') plus the sort order ('newest first'), which lets an agent distinguish it from a single-message reader like read_email. It does not, however, differentiate itself from search_emails, which is the closest sibling and the one an agent is most likely to confuse it with.

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

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

Usage is only implied: the tool is for enumerating a folder's contents with optional narrowing filters. The one sibling reference ('as returned by list_folders') is a data dependency for the folder argument, not guidance on when to pick this tool over search_emails or get_thread, and no exclusions are stated.

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

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

The readOnlyHint annotation already establishes this as a safe, non-mutating read. The description adds real value beyond that by disclosing that the output is a discovery artifact feeding other tools, but it says nothing about mailbox breadth, permissions, or large-mailbox behavior.

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

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

Two sentences, both load-bearing: the first states the action, the second states when to call it and why the result matters. The primary guidance is front-loaded 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?

With an output schema present, the description need not document the returned folder structure, and it correctly focuses on when to call the tool and how to consume its output. It is nearly complete; only the call-ordering relationship with sibling tools could be tightened further.

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

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

The tool takes zero parameters, so there are no argument semantics to explain; the baseline for a parameterless tool applies. Nothing in the description conflicts with the empty schema.

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

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

"List every folder and label of the mailbox" names a specific verb (list), a specific resource (folders and labels), and its scope (every). This is unmistakably distinct from the email-oriented siblings (list_emails, read_email, search_emails) without needing to name them.

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?

"Use this first when you do not know where a message lives" gives an explicit triggering condition and ordering relative to other tools. It also explains the payoff (returned names are valid inputs elsewhere), which is exactly the routing guidance an agent needs.

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?

readOnlyHint=true already signals a safe read, but the description adds value beyond the annotation by disclosing the return shape (headers, decoded body, attachment names, flags) and the truncation behavior via max_chars. Auth requirements and rate limits remain undisclosed.

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-sentence purpose covering both action and return, followed by a compact Args block with no filler. Every sentence carries information an agent needs.

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?

Complete for a single-message read: identity source, required param format, truncation knob, and return contents are all covered, and an output schema exists so return values need no further elaboration.

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

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

Schema description coverage is 0%, so the description carries the burden, and it does: it explains that message_id must be the full Message-ID header including angle brackets, that folder locates the message, and that max_chars truncates longer bodies. Minor gap: no mention of the default values already present in the schema.

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

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

States a specific verb+resource (read one full message) plus scope ('one' vs the list/search siblings) and names where the Message-ID originates, which routes the agent away from list_emails/search_emails.

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 frames this as a follow-up to list_emails or search_emails, giving a clear usage context and an implied input source. It does not state when to prefer get_thread for conversation reading, so the exclusion is absent but the context is solid.

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 not read-only, not destructive, not idempotent. The description adds genuinely new context: files are never overwritten and never leave the sandbox, which tells the agent the operation is contained and non-destructive to existing files. This is useful beyond what the annotations provide.

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

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

Front-loaded with the core behavior, then a compact Args block. Every line earns its place, though the Args formatting is slightly verbose for the amount of information conveyed.

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?

Complete for a mutation tool: an output schema exists so return values need no explanation, annotations cover the safety profile, and the description covers behavior and all parameters. Missing only explicit guidance on error/ambiguity handling beyond the filename/index hints.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it delivers: each of the four parameters is explained, including the non-obvious conditional rules for filename ('omit when the message has exactly one') and index ('0-based when filenames are ambiguous'). Minor gap: no format hint for message_id or folder beyond the default.

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 ('Save one attachment') plus a clear destination ('local sandbox directory') and scope ('one attachment'). It is easily distinguished from list_attachments and export_email by the save-into-sandbox semantics, though it doesn't 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?

No explicit when-to-use or when-not-to-use guidance, but the Args section implies the intended workflow (single attachment -> omit filename; ambiguous filenames -> use index). Usage is inferable rather than stated.

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

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

Beyond readOnlyHint=true, the description discloses a non-obvious implementation constraint: IMAP cannot natively search attachments, so up to 200 newest candidates are probed via BODYSTRUCTURE and the result reports scanned/truncated counts. That is exactly the kind of caveat an agent needs to interpret partial results.

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 and AND-combination rule are front-loaded in two short sentences, followed by a compact per-parameter list. Every line adds information; nothing is padded, and the attachment caveat is placed where it is relevant.

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 still notes that attachment searches report scan/truncation counts. Ten parameters at 0% schema coverage are all documented, so an agent has everything required to call the tool 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 carries the full burden and does so for all ten parameters: full-text scope for query, substring matching semantics for sender/recipient/subject, relative-window meaning for since_days/before_days, and boolean triggers for unread_only/has_attachment. This is meaningfully more than the schema provides.

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

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

States a specific verb and resource ("Search messages") plus an ordering guarantee ("newest first") and the AND semantics of filters. However, it never differentiates itself from the sibling search/list tools such as list_emails or get_thread, so the agent must infer which to choose.

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 clarifies how filters combine (AND), that an empty query matches everything, and points to list_folders for valid folder names, which is real usage guidance. It offers no when-to-use/when-not guidance relative to list_emails or get_thread, so routing between siblings is left implied.

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