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

With no annotations provided, the description carries the full burden and delivers extensively: it discloses automatic IMAP folder change detection, new folder logging, the 100-item eviction policy, deletion-signal handling, non-removal of empty folders, required ⚠️ marking for reply_to_differs=true, and the full output structure. This goes well beyond minimal viability.

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 long but front-loaded with the core purpose, followed by behavior and output format. Each section earns its place, though the density and lack of bullet formatting make it slightly harder to scan than ideal.

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 format is fully described and folder-related behavior is very complete, which is helpful given there is no output schema. However, the three parameters are completely undocumented, so the description is not fully sufficient for an agent to confidently call the tool with non-default arguments.

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% and the description never explains account_label, override_since, or max_per_account. Even the 100-item mention refers to an internal eviction rule, not to the max_per_account parameter. The agent is left to guess the format and semantics of override_since and the selection behavior of account_label.

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

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

The description uses a specific verb '수집합니다' and a clear resource: unread mails from all registered accounts since the last check. It also clearly scopes the tool to K-Mail-MCP and differentiates it from siblings like read_email by emphasizing the batch collection over registered accounts.

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 directs users to set_watched_mailboxes for folder exclusion management, which is a useful alternative-tool pointer. It does not explicitly contrast check_new_mails with read_email or list_accounts, but the batch-collection purpose is clear enough to infer when to use 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?

With no annotations provided, the description carries the full behavioral burden. It does disclose a key non-obvious behavior: categories are only saved when overwrite=true. However, it does not explain what happens when overwrite is false, whether existing categories are replaced, or other side effects of the operation.

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 with no filler. The main purpose is front-loaded, and the critical saving condition immediately follows. Every word 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 tool with no annotations and no output schema, the description is somewhat thin. It conveys the core purpose and the overwrite requirement, but it omits what sample_size controls, what the output looks like, and the implications of overwrite=false. An agent could invoke it correctly but might misunderstand persistence or return behavior.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful context for the overwrite parameter by explaining that it must be true for saving to occur. However, it provides no information about sample_size, leaving that parameter dependent entirely on the schema's default/min/max constraints.

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

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

The description clearly states a specific action: automatically generating custom categories from analyzing actual email patterns. This distinguishes it from sibling tools focused on listing accounts, checking/reading mail, and managing watched mailboxes, since it is the only category-generation tool.

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

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

The description gives one important usage constraint: overwrite must be true for results to be saved. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention situations where generation might be inappropriate or unnecessary.

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 full behavioral disclosure. It adds meaningful details: the 100-item cap on discovered folders, the excluded folder source, the effective = discovered − excluded calculation, and automatic initialization for unregistered accounts. It does not explicitly state whether the operation is side-effect free, but the read-oriented wording strongly implies it.

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 efficiently structured: purpose first, then each status defined in a scannable format, followed by one important behavioral note. Every sentence earns its place, and no redundancy is present.

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

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

For a no-parameter query tool without annotations or output schema, the description provides enough context to understand what will be returned and how the statuses relate. It could be even stronger by stating the response format explicitly, but the current description is broadly sufficient.

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

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

The tool has zero parameters, so there is no burden for the description to explain inputs. The description instead usefully defines the returned status fields, which serves the agent's understanding of the result.

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 resource (account-specific folder logs) and the verb (조회/query), defining the three statuses. It does not explicitly differentiate from sibling tools, but the focus on discovered/excluded/effective scan status makes the tool's purpose readily identifiable.

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 this is used to inspect folder scan status, and it references check_new_mails for initialization behavior. However, it never explicitly states when to prefer this tool over alternatives or what conditions make it the right choice.

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 usefully discloses that passwords are not included, but says nothing else about side effects, permissions, or limits. For a zero-parameter read-only list operation, this is acceptable but minimal.

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

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

The description is a single efficiently worded sentence with a useful parenthetical qualifier. Every word earns its place and the main action 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 zero-parameter list tool, the description is mostly sufficient, but with no output schema and no annotations it could say a bit more about what an account entry looks like or how this differs from list_mailboxes. Still, the core purpose is clear.

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

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

There are no parameters, so the input schema is effectively complete. The description adds a small but relevant semantic detail that the returned accounts are registered, which is the baseline-4 case for zero-parameter tools.

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?

Description clearly states that the tool returns the list of registered mail accounts, using a specific verb and resource. However, it does not differentiate from sibling list_mailboxes, so an agent cannot immediately tell which list tool to use.

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 that one should use this tool when a list of registered accounts is needed, but it gives no explicit when-to-use guidance or exclusions. No alternatives or relationships to sibling tools like list_mailboxes are mentioned.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does disclose that the tool returns a folder list plus cumulative status, implying a read-only operation. However, it does not clarify whether this contacts the IMAP server, how the status counts are computed, or what the output structure looks like.

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

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

The description is a single, front-loaded sentence with no redundant words. It efficiently states both the folder-list output and the additional status information, making it appropriately sized for a tool with only one parameter.

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

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

With no output schema and no annotations, the description should provide more context about return values and parameter usage. The unexplained terms 'discovered/excluded/effective' and the missing explanation of account_label leave significant gaps for an agent trying to invoke 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?

The schema has no descriptions for the single required parameter 'account_label', and the tool description does not mention it at all. The parameter name is somewhat self-explanatory, but the description fails to explicitly state that mailboxes are listed for the given account_label or what acceptable values are.

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 resource ('IMAP folder list') and an explicit return verb ('returns'), and it goes beyond the tool name by mentioning the additional cumulative status of discovered/excluded/effective mailboxes. However, the meaning of 'discovered/excluded/effective' is not explained, so the purpose is clear but partially ambiguous.

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

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

No guidance is given about when to use this tool versus siblings such as list_accounts, get_watched_mailboxes, or check_new_mails. The description does not state any exclusions, prerequisites, or alternative conditions, leaving the agent to infer usage from the name alone.

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 the max_chars behavior (default 5000, -1 for full) which is useful. However, it does not explicitly state that the operation is read-only (though the verb implies it), nor does it mention side effects, error behavior, or output format. Given the read-only nature, the risk is low, but more context would help.

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

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

The description is a single, efficient Korean sentence. It front-loads the core purpose and then adds the key parameter behavior. There is no fluff or redundancy, and every word adds value.

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

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

The tool has 4 parameters, no annotations, and no output schema, so the description must compensate heavily. It does not explain the required parameters (uid, account_label) or the mailbox default, nor does it describe the return value (email body) or any error cases. An agent would need to infer a lot from parameter names, making this insufficient for a complete call.

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

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

Schema description coverage is only 25% (only max_chars has a description). The description adds meaning for max_chars by explaining the default and the -1 sentinel, which goes beyond the schema. However, it does not explain uid, mailbox, or account_label, which are left to be inferred from their names. Since coverage is low, the description should compensate more but only partially does.

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

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

The description clearly states a specific action: reading the full body of a specific email. It uses the verb '읽습니다' (reads) with the resource '특정 메일의 전체 본문' (the full body of a specific email). It distinguishes itself from sibling tools, which are all about listing accounts, checking new mails, resetting, categorizing, or watching mailboxes – none overlap with reading an email body.

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

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

The description implies usage when one needs to read an email's body, but it does not explicitly state when to use this tool versus alternatives or provide context like prerequisites (e.g., having a uid from list_mailboxes). No exclusions or alternatives are mentioned, so the guidance is only implied, not explicit.

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

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

No annotations are provided, so the description must disclose side effects. It states it resets or sets a time, but does not explain the consequences, such as affecting future email checks, whether the operation is reversible, or if it only applies to a specific account. This is a significant gap for a state-changing tool.

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

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

The description is a single concise sentence with no filler. It front-loads the purpose but omits critical context. It is appropriately sized for a simple tool, though it could be more informative without losing conciseness.

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 tool with two parameters and no output schema, the description is incomplete. It does not clarify what 'last run' means, the effect of account_label, or the default behavior when set_to is empty (which is only in the schema). Given the tool's role among siblings, more context is needed.

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 describes set_to (ISO 8601, empty means 7 days ago) but account_label has no schema description. The tool description mentions neither parameter, adding no meaning beyond the schema. With 50% schema coverage, it fails to compensate for the undocumented account_label.

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 (reset or set the last run time) and the resource (the timestamp). It is distinct from sibling tools which handle accounts, mails, and mailboxes, so an agent can differentiate. However, it doesn't explain what 'last run' refers to, which slightly reduces clarity.

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 no guidance on when to use this tool versus alternatives. It doesn't mention that it affects scheduling or that it can be scoped per account. No context is given for when a reset is appropriate.

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, and it does so concretely: add_exclude excludes folders from scanning for '노이즈/대용량 폴더 등', remove_exclude restores '기존 제외 폴더', and reset_exclude initializes to '시스템 기본값'. It also discloses that folder discovery is automatic. Gaps remain for edge cases like combining reset_exclude with add/remove or invalid folder names, but the core side effects are clearly stated.

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 front-loaded: one sentence stating the purpose, three terse parameter definitions, a lookup instruction, and a concrete example. It contains no filler; each clause carries operational information and the flow from purpose to parameters to example is natural.

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 mutating configuration tool with no annotations and no output schema, the description covers the essential invocation context: target account, the three operations, folder-name source and case sensitivity, and an example. It omits success/error response behavior and interaction between operations, but such details are not necessary to make a correct call for the common cases.

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 already documents all four parameters (100% coverage), so the baseline is 3. The description adds real value beyond the schema: it explains that add_exclude targets noise/large folders, remove_exclude restores previously excluded folders, reset_exclude reverts to system defaults, and it adds the exact-case requirement for folder names ('대소문자 정확히') plus a concrete example mapping account_label:'다음개인' to add_exclude:['카페편지함'].

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 a precise statement: '계정의 폴더 제외 목록을 관리합니다' (manages the account's folder exclusion list) and immediately distinguishes this from automatic folder discovery: '폴더 발견은 자동이며, 여기서는 제외 목록만 관리합니다.' It enumerates the three concrete operations (add_exclude, remove_exclude, reset_exclude), making the tool's resource and actions unmistakable and separating it from siblings like list_mailboxes or get_watched_mailboxes.

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: this tool is for exclusion-list management only, not for discovery ('폴더 발견은 자동이며'), and it instructs the agent to verify folder names against 'list_mailboxes의 currentImap 목록' with exact case ('대소문자 정확히'). However, it does not explicitly reference get_watched_mailboxes as the tool for viewing current exclusions, so the when-to-read vs when-to-write distinction is left somewhat implicit.

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