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

Annotations already indicate mutating and non-idempotent behavior, but the description adds valuable context: moving archives invalidates the provided short IDs, and there is a limit of 25 per call. This goes beyond the annotations and helps the agent understand consequences of use.

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 very concise, with two sentences and a short Args section. Every sentence adds value: the action, the ID invalidation warning, re-query guidance, and parameter format. No unnecessary words 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 single-parameter tool, the description covers the essential information: purpose, parameter format, constraints, and post-call behavior. The output schema is present (per context signals), so return values need not be explained. It's sufficiently complete for an agent to use 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 input schema only names 'message_ids' with no description, so the description carries the full burden. It explains the format (comma-separated short IDs) and the limit (max 25), which is essential for correct invocation. The description compensates well for the 0% schema 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 clearly states the action: 'archive emails (move to Archive folder)'. It specifies the resource (emails) and destination (Archive folder), distinguishing it from similar tools like move_messages. The purpose is specific and unambiguous.

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

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

The description provides clear context: use this tool to archive emails. It also includes a critical post-condition (IDs become invalid, re-run search_messages). However, it does not explicitly mention alternatives or when not to use this tool, so it lacks explicit 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=true, and the description adds valuable context about what is diagnosed (settings, auth, connection). It does not disclose output format, but with a read-only annotation and an output schema present, the added behavioral context is sufficient.

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

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

The description is two short sentences, front-loaded with the main purpose and followed by clear trigger conditions. Every word is functional; no wasted text.

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 diagnostic tool with an output schema and read-only annotation, the description fully covers its purpose, usage triggers, and diagnostic scope. No additional details are necessary.

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?

This tool has zero parameters, so the baseline score is 4. The description appropriately does not need to explain parameter semantics, as there are none.

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

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

The description clearly states it diagnoses server settings, authentication, and connection status, which is a specific verb+resource. It is clearly distinct from all sibling tools that operate on folders, messages, or rules.

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 provides when to use: when other tools return an error or when the user asks if they are connected. This gives clear context and differentiates it from the other operational tools.

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

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

Annotations only indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds crucial behavioral context: there is no sending mechanism on this server, drafts are placed in Outlook's Drafts folder, and they remain there until the user sends them. It also instructs the agent to communicate this limitation to users, which is valuable 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?

The description is well-structured and front-loaded: the bold '**送信はしない**' immediately signals the most important caveat, followed by a concise explanation and a clean Args list. Every sentence adds value, and the formatting improves readability.

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 draft-creation tool, the description covers the essential behavioral constraint (no sending), the destination folder, the user-facing instruction, and all parameter semantics. An output schema exists, so the lack of explicit return-value documentation is acceptable. The description is wholly sufficient for an agent to use 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 fully compensates by explaining each parameter: 'to' and 'cc' accept comma-separated addresses, 'subject' is the subject line, and 'body' is plain text. This adds meaning beyond the bare schema titles and clearly conveys the expected input format.

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

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

The description clearly states 'メールの下書きを作る' (create an email draft) and emphasizes '**送信はしない**' (does not send), giving a specific verb and resource. However, it does not explicitly distinguish this from the sibling tool 'draft_reply', which likely creates a reply draft, leaving some ambiguity about whether this is for new emails only.

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

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

The description explicitly states when not to use it (when sending is requested) and instructs the agent to tell the user that only draft creation is possible. It provides clear context for the tool's scope but does not name alternatives like 'draft_reply' for reply-draft scenarios.

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 annotations (readOnly=false, idempotent=false, destructive=false), the description adds substantial behavioral context: required Mail.ReadWrite permission, OUTLOOK_READONLY restriction, duplicate folder behavior (409 error, no double creation), parent must exist, no automatic intermediate folder creation, and no effect on existing emails. It also confirms these behaviors are verified on a real device. No contradiction with 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?

Though the description is relatively long, every sentence earns its place. It opens with a one-line summary, then follows with usage focus, behavior bullet points, permission note, and parameter details. The bullet-point structure improves scannability, and there is no fluff or redundancy. The length is justified by the tool's complexity and the edge cases documented.

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

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

The description is complete given the tool's complexity and the presence of an output schema. It covers prerequisites (permission, existing parent), failure modes (409 on duplicate, missing parent), usage sequence (call before moves), and parameter constraints. The output schema presumably describes the return value, so no need to duplicate that. It leaves no significant gaps for an agent to misuse the 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?

The input schema provides only type/title/default for 'name' and 'parent' with no descriptions. The description's Args section adds rich semantics: 'name' cannot contain '/' and must be unique under the same parent; 'parent' can be a folder name or full path, is optional, and must point to an existing folder. This fully compensates for the 0% schema description 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 clearly states the tool's function: 'Create one empty folder. Does not move emails.' It specifies the resource (folder), action (create), and scope (empty, no email movement). It also differentiates from sibling tools by explicitly referencing move_folder/rename_folder and move_messages/move_by_search, making its purpose unambiguous.

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

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

The description gives explicit guidance on when to use this tool: call it first when needing a destination for emails, since move_messages and move_by_search cannot move to nonexistent folders. It also states when not to use it: use move_folder or rename_folder instead if only moving or renaming an existing folder. This covers both when and when-not with named 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?

Adds rich behavioral context beyond annotations: persistence across MCP downtime, non-retroactivity, AND logic for multiple conditions, comma-separated values, stop_processing default, and to_trash not being permanent deletion. This complements the annotations (readOnly=false, idempotent=false, destructive=false) with meaningful detail.

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 well-structured: starts with core purpose, followed by key behavioral notes, then a clean bullet-style Args list. Every sentence adds value, and repetitive clarifications ('カンマ区切りで複数可') are necessary for each relevant parameter. It is appropriately sized for a 10-parameter tool with important nuances.

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

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

Given the complexity (10 params, 0% schema coverage), the description is remarkably complete: it covers purpose, persistence, scope of application, condition semantics, and parameter meanings. An output schema exists, so return values need not be described. No critical operational details are 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%, but the description explains every parameter with practical guidance. For example, 'name' is described as a self-explanatory label, 'to_trash' clarifies it's not permanent deletion, 'stop_processing' explains its default behavior, and 'sequence' explains the default append behavior. This fully compensates for the schema's lack of descriptions.

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

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

The description clearly states the tool's function: '受信トレイに自動振分ルールを作る' (creates an automatic routing rule in the Inbox). It also specifies scope (applies to future emails, not retroactive) and explicitly differentiates from sibling 'move_by_search', making the purpose 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?

It provides explicit when-to-use context: rules persist on Outlook side and work even if MCP isn't running. It also states when not to use it: '既に届いているメールには遡って適用されない(それは move_by_search の仕事)' directly naming the alternative tool for retroactive moves.

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 annotations (readOnlyHint=false, destructiveHint=true), the description adds critical behavioral context: irreversible deletion, default behavior with non-empty folders, force semantics, and the confirmation requirement. No contradiction with 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?

The description is appropriately sized for a destructive operation, with a clear opening statement, concise warnings, alternative guidance, and a structured Args section. Every sentence adds value without unnecessary fluff.

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

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

Given the tool's destructive nature and the existence of an output schema, the description covers all necessary aspects: purpose, default behavior, force option, irreversibility, alternative tool, and user confirmation. It is complete for safe and 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?

Schema description coverage is 0%, but the description fully explains both parameters: 'folder' is the folder name or full path, and 'force' deletes even if content remains. This adds meaning well beyond 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?

The description states a specific verb+resource: 'フォルダを削除する' (deletes a folder). It distinguishes from sibling alternatives by explicitly comparing with move_folder and noting irreversibility, making the tool's scope 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?

Provides explicit usage guidance: default rejects non-empty folders, force flag to override, and '残しておきたいなら削除ではなく move_folder で退避すること' (use move_folder instead if you want to keep it). Also instructs to always get user confirmation before executing, covering when and how to use the 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 indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context beyond these hints, notably that deleting the rule does not move emails. This helps set expectations about the operation's side effects. However, it does not mention irreversibility or permission requirements, which is partly covered by the destructive hint.

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 concise and front-loaded with the main purpose. It uses a single informative sentence about behavior plus a short parameter section. No unnecessary words or repetition—every part 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 simple rule-deletion tool with one parameter, the description covers the key aspects: what it does, its effect (or lack thereof) on emails, and the parameter format. The presence of an output schema and annotations fills other gaps. A minor omission is explicit mention of permanence, but destructiveHint already conveys that. Overall, the description is sufficiently complete.

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

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

The input schema only defines the 'rule' field as a string with no explanation. The description compensates fully by specifying that it can be either a rule name (as shown in list_rules) or a raw rule ID. This is essential guidance for correct usage, and the description provides it clearly.

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

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

The description clearly states the tool's function: deleting an auto-sorting rule. It uses a specific verb ('delete') and resource ('rule'), distinguishing it from sibling tools like create_rule and list_rules. The additional note 'Emails do not move' clarifies the tool's scope.

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 for deleting rules but does not explicitly state when to use it over alternatives or provide exclusions. It gives helpful guidance on the 'rule' parameter format (name from list_rules or raw ID), but lacks explicit contextual direction. This is acceptable but not outstanding.

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 annotations, the description discloses key behaviors: it does not send, the original email quote and recipient are assembled by Graph, and the body appears at the top. This adds meaningful context not visible in annotations, with no contradictions.

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 compact and well-structured, with a bold emphasis on the non-sending behavior and a clear Args section. Every sentence earns its place, and the formatting improves scannability.

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 an output schema exists, return values are already covered. The description provides essential behavioral context (no send, quote assembly), parameter meaning, and side-effect clarity. It is sufficiently complete for a draft-creation tool, though it could optionally mention the destination folder for drafts.

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 fully compensates by explaining each parameter: message_id accepts short or raw IDs, body is plain text, and reply_all toggles reply-to-all. This is sufficient for correct usage, though it could include more examples or validation details.

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

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

The description clearly states the tool creates a draft reply to a received email and explicitly notes it does not send it. This is a specific verb+resource pairing that distinguishes it from sending tools and from the general create_draft sibling.

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

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

The description implies usage for replying to received emails, but there is no explicit guidance on when to use this tool versus alternatives like create_draft. It lacks exclusions or alternative tool references, though the purpose is clear enough for basic 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?

The readOnlyHint annotation already signals a safe read operation. The description adds value by specifying exactly which fields are read (body and recipient) and explaining the two accepted ID formats, which goes beyond the annotation alone.

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 extremely concise, with a single sentence for purpose and a clear Args section for the parameter. Every word earns its place, and it is well-structured with a leading verb and resource.

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 operation with one parameter and an output schema, the description covers the essential information: what is returned (body and recipient) and how to specify the message. There is no unnecessary detail.

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 explain the parameter. It thoroughly does so by clarifying that message_id can be a short ID from search_messages (e.g., '#3') or a raw ID, adding meaning beyond 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?

The description clearly states it reads the body and recipient of one email, using a specific verb and resource. This distinguishes it from sibling tools like search_messages or move_messages, which perform different operations.

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 indicates the message_id comes from search_messages, implying this tool is used after a search to retrieve full details. It provides clear context for when to use the tool, though it does not explicitly state exclusions or 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 already provide readOnlyHint=true, and the description adds useful behavioral context: it returns counts and unread counts, and the only_nonempty parameter filters empty folders. No contradiction with 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?

The description is concise, front-loaded with the primary purpose, followed by usage context and parameter explanation. Every sentence adds value and there is no wasted text.

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 one parameter and an output schema, the description covers purpose, when to use it, and parameter semantics. It is complete and appropriately scoped.

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

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

The input schema only provides the type and default for only_nonempty. The description compensates by explaining that setting it to True omits empty folders, adding meaning beyond the schema.

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

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

The description clearly states the tool returns a list of mailbox folders with message counts and unread counts, which is a specific verb+resource. It also differentiates itself by noting when it should be called (before moving mail or when folder names are ambiguous), setting it apart from sibling folder operations.

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

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

The description explicitly says to use this tool before moving mail or when the user mentions a folder name vaguely. This gives clear usage context, though it does not mention exclusions or name alternative tools.

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

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

The readOnlyHint annotation already indicates a safe read operation. The description adds valuable context about the purpose of the read (conflict checking and sequence discovery) without contradicting the annotation. It does not detail output formatting, but that is covered by the output schema.

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

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

The description is two sentences, front-loaded with the main purpose. The second sentence provides crucial usage guidance without redundancy. Every phrase 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 simple, zero-parameter, read-only tool with an output schema, the description is complete. It tells what it does, when to use it, and why, leaving no significant gaps for an agent to 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 the schema provides complete coverage. The description does not add parameter-specific details but none are needed; the baseline of 4 applies because the description clarifies why the absence of parameters is appropriate and what the tool returns.

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

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

The description clearly states the tool lists automatic sorting rules in the inbox, which is a specific verb+resource combination. It distinguishes itself from siblings like create_rule and delete_rule by focusing on listing existing rules.

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

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

The description explicitly instructs to call this tool before creating a rule to check for conflicts and see which sequence numbers have been used. This provides clear when-to-use guidance and implicitly contrasts with create_rule, making the use case unambiguous.

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 indicate the tool is not read-only and not destructive. The description adds behavioral details beyond annotations: batch limit of 25, comma-separated short ID format, and the toggle between read and unread via the 'read' parameter. No contradiction with 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?

The description is exceptionally concise: a one-sentence purpose followed by a two-line args spec. Every word earns its place, no fluff, and the key info is front-loaded.

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

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

For a simple state-change tool, the description covers purpose, parameters, constraints (batch size, ID format), and aligns with annotations for safety. The output schema handles return values, so no extra explanation is needed here.

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

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

With 0% schema description coverage, the description carries full responsibility for parameter meanings. It clearly explains message_ids (short IDs, comma-separated, example, limit) and read (True/False semantics), fully compensating for the schema's lack of descriptions.

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

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

The description clearly states the verb 'mark' and resource 'messages' with the state change (read/unread). It distinguishes from siblings like move_messages and archive_messages by specifying the state mutation, and from mark_read_by_search by focusing on specific message IDs.

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 for specific message IDs but provides no explicit guidance on when to choose this tool over alternatives like mark_read_by_search. It lacks a when-to-use or exclusion statement, though the parameter semantics make the context 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?

The description adds significant behavioral context beyond annotations: it specifies that emails are not moved (location and short ID unchanged), explains the irreversibility of the read status change, and details the dry_run default behavior. The annotations already mark it as destructive, but the description enriches that with concrete consequences.

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 well-structured and appropriately sized. It begins with a one-line summary, then provides a sibling comparison, safety warning, and a clear parameter list. Every sentence serves a purpose, and the front-loaded summary immediately conveys the core function.

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

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

Given the tool's complexity (8 parameters, destructive behavior, bulk operation), the description is complete. It covers purpose, sibling differentiation, safety considerations, parameter details, dry_run default, and the fact that emails are not moved. The presence of an output schema means return values do not need to be described. All necessary context is present.

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

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

With 0% schema description coverage, the description fully compensates by providing detailed explanations for all 8 parameters in an 'Args' section. It covers partial matching for from_address and subject_contains, date formats for since/until, the meaning of read, max_messages limits (default 5000, max 25000), and dry_run behavior. This adds substantial meaning that the schema alone 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 description clearly states the tool's function: bulk mark emails as read/unread based on search conditions. It explicitly distinguishes itself from the sibling 'mark_messages_read' by calling itself a 'bulk version', making the purpose and differentiation very 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?

The description provides explicit guidance: it is the bulk version of mark_messages_read, advises to use dry_run first to preview count, and warns about the irreversibility of marking many messages as read. It includes a strong recommendation to show the target and count to the user before execution, which is a clear usage guideline.

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 description discloses the dry-run default, the consent workflow, the rejection of unfiltered calls, the max_messages default and cap, the folder scan behavior, and matching semantics for from_address and date inclusivity. This goes well beyond the annotations, which only indicate mutability, adding critical context for safe execution.

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 well-structured with a concise summary, safety note, and an Args list. Every sentence adds value; the dry-run explanation is repeated in both the intro and the Args list, but that's acceptable given its importance. The layout is front-loaded with the core purpose and then safety details.

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

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

Given the 9 parameters and the output schema, the description covers all operational behaviors and constraints. The safety workflow and parameter semantics are fully specified, making the tool self-sufficient for correct invocation. Nothing essential is left to guess.

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's Args section provides all parameter semantics. Each parameter is explained with concrete examples (e.g., dest folder names, date format, matching rules), adding significant value beyond the schema's bare types and defaults.

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

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

The description clearly states the tool moves emails matching conditions in bulk, and explicitly frames it as 'move_messages の大量版' (large-scale version of move_messages), distinguishing it from the sibling tool. The verb 'move' and the resource 'emails matching conditions' are specific and unambiguous.

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

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

The description provides explicit usage guidance: use dry_run first, show the count, get consent, then re-invoke with dry_run=False. It also states that calls without any filter conditions are rejected, preventing misuse. The 'large-scale version' implies when to use over move_messages, and the safety protocol is clearly outlined.

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 provide readOnlyHint=false, destructiveHint=false, so the safety profile is known. The description adds useful behavioral context: the folder's contents move along with it, and system folders cannot be moved, which goes beyond the annotation hints and helps the agent predict side effects.

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 brief and well-structured: a topic sentence, a key behavior, a usage guideline, a limitation, and a clear Args list. Every sentence adds value with no redundancy, and the most important information is front-loaded.

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

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

For a tool with two parameters, the description covers purpose, behavior, usage guidance, and parameter semantics. An output schema exists, so return value details are not required in the description. The tool's scope and limitations are adequately described, making it complete for an agent to select and invoke 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 input schema provides only types and requiredness, but the description's Args section gives full semantics: `folder` can be a name or full path with an example, and `parent` is optional with default behavior (moves to top level). This fully compensates for the 0% schema description 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 clear action ('Moves a folder under another parent') with a specific resource, and distinguishes from siblings by noting it moves the whole folder tree rather than individual messages. The limitation about system folders further clarifies scope.

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

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

The description explicitly advises using this tool when moving a whole folder instead of moving many emails one by one, giving a clear when-to-use context and an implicit alternative. It also states a system folder exclusion, though it does not name the sibling tool for moving individual messages.

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?

Even with annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description adds significant behavioral insight: error on missing folder, short IDs becoming invalid after moving, a 25-message limit, and a user confirmation requirement. No contradiction with 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?

The description is tightly structured: a one-line purpose, bullet-style behavioral notes, and a clear Args section. Every sentence provides actionable information 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?

For a tool with only two parameters and an output schema, the description covers error conditions, prerequisites, side effects, limits, and parameter formats. It leaves nothing essential unexplained for an agent to 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?

Schema description coverage is 0%, so the description carries full responsibility for parameter semantics. It explains message_ids format with examples (#1,#2,#5) and max count, and folder with examples ('領収書', '受信トレイ/請求'). This adds substantial meaning beyond 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?

The description opens with 'メールを指定フォルダへ移動する' (Moves emails to the specified folder), which is a specific verb+resource+destination statement. It clearly distinguishes from sibling tools like move_folder, archive_messages, and move_to_trash by emphasizing arbitrary folder targeting.

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?

Provides clear context: call create_folder if the destination doesn't exist, confirm with user before bulk moves, and re-run search_messages because IDs become invalid. However, it does not explicitly state when not to use this tool in favor of alternatives like move_by_search or archive_messages, though the parameter difference implies 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?

Despite annotations already indicating destructiveness, the description adds significant behavioral detail: the action is reversible (not permanent), there is no permanent deletion option on this server, IDs are invalidated after moving, and user confirmation is mandatory. This goes well beyond the annotations and provides essential operational 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?

The description is compact, front-loaded with the core action, then provides necessary behavioral notes and parameter details. Every sentence serves a purpose, with no redundancy or fluff.

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 tool, the description covers the main action, reversibility, server limitations, user confirmation requirement, ID invalidation, and parameter format/limits. The presence of an output schema means return values need not be described. It is complete for safe and correct usage.

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

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

The schema only defines message_ids as a string, but the description explains it expects comma-separated short IDs and enforces a limit of 25 per call. This is critical information for correct invocation and fully compensates for the 0% schema description 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 clearly states the action: moving emails to trash (deleted items), and clarifies it is not permanent deletion. It names the resource (emails) and the target (trash), but does not explicitly distinguish from sibling tools like move_messages or archive_messages, though the specified target makes the purpose unambiguous.

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

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

The description provides clear usage context: confirms that permanent deletion is unavailable on this server, instructs to always get user confirmation before execution, and warns that short IDs become invalid after moving, recommending to re-run search_messages for further operations. It does not explicitly name alternative tools, but the guidance on when and how to use is substantial.

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 indicate this is a non-readonly, non-destructive operation. The description adds meaningful context: emails inside are unaffected, system folders are restricted, and the folder hierarchy remains unchanged. This goes beyond what annotations provide and clarifies user expectations.

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 compact, front-loaded with the core purpose, and uses a clear Args section for parameters. Every sentence contributes (purpose, behavioral note, system folder restriction, param constraints) with no redundancy or fluff.

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 rename tool with two parameters and an output schema, the description covers purpose, constraints, system folder exclusions, and parameter semantics. Nothing critical is missing; the output schema handles return value details.

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 fully compensates by explaining both parameters: 'folder' (target folder name or full path with example) and 'new_name' (no '/' because hierarchy doesn't change). This adds critical 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?

The description clearly states the verb and resource: 'フォルダの名前を変える' (change the name of a folder). It distinguishes from sibling tools like move_folder by noting '中身のメールは動かない' (emails inside don't move) and '階層は変わらない' (hierarchy doesn't change), making the rename-only scope unmistakable.

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?

Provides clear when-not guidance: system folders like Inbox/Spam cannot be changed, and the hierarchy isn't altered, which implies using a move tool for path changes. However, it doesn't explicitly name alternatives like move_folder, so it's not a full 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 description discloses sorting order, output format (#N), and parameter behaviors such as limit's upper bound and include_preview's effect on response length. Even with readOnlyHint true, it adds useful context beyond the annotation.

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 begins with a one-line purpose, then formatted Args with concise bullet-like explanations. Every parameter earns its place, and the structure makes it easy to scan. No unnecessary words.

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 output schema exists, so return values need no explanation. The description covers the search orientation, sorting, ID format, and all parameter constraints, making it sufficiently complete 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?

All 8 parameters are described with richer semantics than the schema provides: query covers subject/body, from_address is partial match, since/until specify date format, and limit has explicit defaults and max. This fully compensates for the 0% schema description 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 clearly states the tool searches emails in descending order and that the leading #N is a short ID for organizing tools. This distinguishes it from sibling tools like get_message (single message) and move_by_search (search-and-move).

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 positions this as the search entry point that provides short IDs for other organizing tools, making its use case clear. It doesn't explicitly list alternatives or exclude other tools, but the context is unambiguous enough for an agent to select it when searching is required.

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