Server Quality Checklist

Tool Scores

• archive_emailsC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states the action (moving to Archive) but does not mention side effects (e.g., does it remove from INBOX? does it change read status?), required permissions, reversibility, or any limitations. The note about UIDs being permanent is useful 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.

  Conciseness4/5

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

  Two concise sentences with the core action front-loaded. The second sentence adds a useful clarification about UIDs. No wasted words, though the description could have used the space to differentiate from move_emails or add usage guidance.

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

  Completeness2/5

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

  For a mutation tool with no output schema and no annotations, the description is incomplete. It omits critical context such as whether the operation is reversible, what happens to the emails in the source folder, potential failure modes, or any prerequisites. It also fails to clarify how it differs from move_emails, which is a sibling that likely has similar behavior.

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

  Parameters3/5

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

  The schema already documents both parameters with descriptions (uids: 'Array of UIDs to archive'; folder: 'Source folder'). The description adds no additional parameter semantics beyond the UID permanence note, which is not strictly tied to parameter usage. Given 100% schema coverage, baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the action (move/archive), resource (emails), and destination (Archive folder). It also explains UIDs are permanent identifiers, which adds specificity. However, it does not explicitly differentiate from the sibling move_emails, leaving slight ambiguity about the distinction.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives like move_emails or delete_emails. The phrase 'for long-term storage' implies a purpose but does not state conditions or exclusions. The agent is left to infer usage without direct direction.

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

• mark_as_unreadC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and that UIDs are permanent; it does not mention side effects, mutability, permissions, failure behavior, or what happens to the email state beyond marking it unread.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the main action, followed by a relevant clarification about UIDs. It contains no filler, though it could include a bit more useful context without becoming bloated.

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

  Completeness3/5

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

  For a simple two-parameter tool, the description plus schema is minimally adequate for invoking the tool. However, with no annotations and no output schema, it lacks information about expected return values, error conditions, or behavioral consequences, leaving noticeable gaps for an agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds a small amount of semantic value by noting that UIDs are permanent identifiers, which helps agents understand their stability, but it does not elaborate beyond what the schema already states.

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

  Purpose4/5

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

  The description clearly states the action ('Mark emails as unread') and the resource (emails), with a specific method (using UIDs). It is not a tautology and is distinguishable from most siblings by the 'unread' intent, though it does not explicitly differentiate itself from the closely related mark_as_read.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives like mark_as_read or read_email. It provides no use-case context, prerequisites, or exclusions, so an agent must infer when this tool is appropriate.

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

• flag_emailsB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that UIDs are permanent; it does not disclose that flagging mutates email state, whether the flag is reversible, what failures look like, or what the response contains.

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

  Conciseness4/5

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

  Two short, front-loaded sentences with no filler. The first sentence states the action and the target; the second efficiently clarifies the permanence of UIDs.

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

  Completeness3/5

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

  The schema fully covers the two parameters, so the main gaps are output behavior and failure semantics, which must be inferred for this mutating tool with no annotations. The low parameter count and simple action keep this gap moderate rather than severe.

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

  Parameters3/5

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

  Schema coverage is 100% — both uids and folder already carry descriptions in the schema, so the baseline is 3. The description adds a small value-add by explaining UIDs are permanent and stable, but adds nothing about the folder parameter beyond the schema.

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

  Purpose4/5

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

  States a clear verb+resource pair: 'Flag emails as important/starred using UIDs.' The 'important/starred' semantics implicitly distinguish it from siblings like mark_as_read, though the distinction is not made explicit by naming any sibling.

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

  Usage Guidelines3/5

  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 is given, and no alternatives are named. The note 'UIDs are permanent identifiers' hints that UIDs are preferred over transient message numbers, which is a mild usage hint but leaves scenario selection to inference.

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

• mark_as_readB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the mutation effect but does not mention idempotency, permanence of the read state, potential side effects, permissions, or response behavior. The 'UIDs are permanent identifiers' note adds some context but does not cover operational behavior.

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

  Conciseness5/5

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

  Two short sentences with no filler. The primary action is front-loaded and the follow-up sentence provides meaningful context about UIDs. Every word contributes.

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

  Completeness4/5

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

  For a simple, single-purpose mutation tool with no output schema, the description provides the essential context: the action, the resource, and the mechanism. It could be improved by noting reversibility (mark_as_unread exists) or the idempotent nature, but the low complexity means the current description is largely sufficient.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds semantic value by clarifying that UIDs are permanent identifiers, which helps agents understand that these are stable identifiers rather than transient session IDs. This goes beyond the bare schema descriptions of 'array of UIDs to mark as read' and 'folder containing emails'.

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

  Purpose4/5

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

  The description clearly states the action ('Mark emails as read') and the resource (emails), with the mechanism ('using UIDs') and a useful clarification that UIDs are permanent identifiers. While it differentiates from mark_as_unread through the word 'read', it does not explicitly call out sibling distinctions.

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

  Usage Guidelines2/5

  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 alternatives such as mark_as_unread, flag_emails, or delete_emails. The mention that UIDs are permanent identifiers implies why UIDs should be used, but there is no explicit context or exclusionary guidance.

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

• unflag_emailsB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action and notes that UIDs are permanent, but does not disclose what happens on invalid UIDs, whether the operation is reversible (unflagging can be undone by flag_emails), or any side effects. For a mutation tool with zero annotation coverage, this is a significant gap.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the action. The second sentence about UIDs being permanent is relevant and concise. No wasted words; the definition is efficiently structured.

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

  Completeness3/5

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

  The tool is simple, but without annotations, an agent needs to know error behavior or return values. The description does not cover what happens if UIDs are invalid, whether it confirms the action, or if any preconditions exist (e.g., folder must exist). Given no output schema and no annotations, this is incomplete for a complete usage scenario, but acceptable for a basic mutation.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already describes both parameters (uids array and folder with default). The description adds minimal extra: it clarifies that UIDs are permanent identifiers, which is useful context for why UIDs are used but not specific to parameter handling. The baseline of 3 is appropriate since the schema does the heavy lifting.

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

  Purpose4/5

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

  The description states a clear action ('Remove flag/star from emails') and the resource, with the mechanism (UIDs). It does not explicitly differentiate from sibling tools like flag_emails, but the opposite verb makes the distinction obvious. A 5 would require naming the sibling explicitly.

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

  Usage Guidelines3/5

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

  The description implies usage: when you have UIDs and want to unflag emails. It mentions UIDs are permanent, which hints at when they are available. However, it does not give explicit guidance about when not to use this tool or mention alternatives like flag_emails. The guidance is implied rather than stated.

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

• move_emailsA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the responsibility. It adds useful context that UIDs are permanent identifiers, which clarifies how to refer to emails. However, it does not disclose potential side effects such as whether the emails are removed from the source, what happens if the destination folder is invalid, or whether the operation is reversible. Some context is given, but a destructive mutation warrants more disclosure.

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

  Conciseness5/5

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

  The description is two sentences with no filler. The core action is front-loaded, and the additional information (UID permanence and list_folders reference) is relevant and concise. Every sentence earns its place.

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

  Completeness3/5

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

  The tool is a mutating operation without an output schema and no annotations. The description covers the action, prerequisites, and the permanence of UIDs, but it does not mention what response the agent can expect, error conditions, or any impact on source folders. For a straightforward move operation, this is adequate but not rich; a bit more detail (e.g., success indication) would improve completeness.

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

  Parameters3/5

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

  Schema description coverage is 100%, so each parameter is already documented. The description adds value by explaining that UIDs are permanent and referencing list_folders for folder names, which supplements the schema. However, it does not add deeper semantics beyond what the schema already states, so it aligns with the baseline of 3.

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

  Purpose5/5

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

  The description states a precise action ('Move emails to a specified folder'), a specific resource (emails by UIDs), and implies the target folder. It clearly differentiates from sibling tools like delete, archive, or mark_as_read by focusing on moving to a folder, and the mention of UIDs adds specificity.

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

  Usage Guidelines3/5

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

  The description provides a prerequisite by pointing to list_folders for available folders, which aids usage, but it does not explicitly guide when to prefer this tool over alternatives like archive_emails or delete_emails. The usage is implied rather than explicitly contrasted with siblings, so it earns a middle score.

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

• read_emailA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool reads email content, which implies no modification, but it does not explicitly confirm that it is non-destructive or mention any side effects (e.g., marking as read). It also does not describe behavior for invalid UIDs, missing folders, or rate limits. The description provides a useful fact about UID persistence but does not cover the tool's operational behavior.

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

  Conciseness5/5

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

  The description is exactly two sentences with no wasted words. It front-loads the core purpose ('Read email content using UIDs') and then adds a practical note about UID persistence and sourcing. This is concise and well-organized, earning a high score.

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

  Completeness3/5

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

  For a simple two-parameter tool with no output schema, the description covers the essential usage: it explains the input (UIDs), the source of that input, and the purpose. However, it does not mention error handling (e.g., invalid UIDs, non-existent folder) or the structure of returned content. Given the lack of annotations and output schema, a bit more detail about expected outcomes or failure modes would improve completeness, but the core usage is adequately covered.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters, giving a baseline of 3. The description adds value by explaining what UIDs are (permanent identifiers) and how to obtain them, which clarifies the semantic meaning beyond the schema's basic 'Array of UIDs' description. However, it does not add details on format (e.g., integer range, array length constraints) or edge cases, so it meets the baseline without exceeding it.

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

  Purpose5/5

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

  The description clearly states the tool reads email content using UIDs and differentiates from siblings by mentioning that UIDs are permanent and obtained from list_emails or search_emails. It specifies the resource (email content) and the action (read), which distinguishes it from listing, searching, or mutating tools.

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

  Usage Guidelines4/5

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

  The description gives a direct usage hint ('Get UIDs from list_emails or search_emails') which establishes the source of the required input. It implies the tool is for reading full content rather than listing metadata, but it does not explicitly state when to avoid using it or compare with alternative tools beyond the UID sourcing. The context is clear enough for an agent to infer the intended use case.

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

• list_emailsA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It states what is returned (UIDs and metadata) and implies a read-only 'list' operation, but does not explicitly confirm no side effects, auth requirements, or rate limits. It also does not clarify how 'recent' is determined, which is a behavioral gap.

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

  Conciseness5/5

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

  The description is a single sentence with no fluff. It front-loads the action and resource, then adds return details, with every phrase conveying necessary information.

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

  Completeness4/5

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

  Given a simple list operation with no output schema or annotations, the description gives a solid overview of purpose and return contents. However, it omits an explicit read-only assurance and does not enumerate all metadata fields, which an agent might need for parsing without an output schema.

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

  Parameters3/5

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

  All three parameters (count, folder, offset) are fully documented in the schema with descriptions, defaults, and max, so the schema provides high coverage. The description adds minimal parameter meaning beyond 'recent,' which hints at recency ordering but does not elaborate on how count interacts with the list.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'List recent emails from a Yahoo Mail folder.' It specifies the resource (emails) and scope (folder), and names the return type (UIDs, metadata). This distinguishes it from siblings like read_email, search_emails, and list_folders.

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

  Usage Guidelines3/5

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

  The description provides implied usage but no explicit when-to-use or alternative routing. The only cross-reference is in the folder parameter schema ('Use list_folders to see available folders'), not the main description. Agents must infer that listing is the appropriate tool for browsing a folder rather than searching or reading.

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

• delete_emailsA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the core behavior (move to Trash, recoverable) but does not detail side effects, permissions, or what happens to related metadata. Basic transparency is present, but it could go deeper.

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

  Conciseness5/5

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

  Two short sentences with zero fluff. The action and key attributes are front-loaded, making it easy to scan and understand.

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

  Completeness4/5

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

  For a two-parameter tool with no output schema and no annotations, the description covers what it does, how it works, and one critical behavioral note (recoverability). It doesn't mention the folder parameter, but the schema already covers that, so nothing critical is missing.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining 'UIDs are permanent identifiers', giving context beyond the schema's property description. This helps an agent understand the data format and stability of UIDs.

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

  Purpose5/5

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

  The description states a specific action ('Move emails to Trash folder'), the method (UIDs), and the key distinction from a hard delete ('soft delete, recoverable'). It clearly identifies the resource and operation, distinguishing it from siblings like move_emails or archive_emails.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool via 'soft delete, recoverable', but it does not explicitly name alternatives or specify conditions when this tool is preferred over siblings like archive_emails or move_emails. Usage is inferred rather than stated.

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

• list_foldersA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (list folders) but does not explicitly note that it is read-only or side-effect-free, nor does it mention any authentication or pagination details. The action implies safety, but absence of explicit disclosure leaves some room for doubt.

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

  Conciseness5/5

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

  A single, grammatically complete sentence states the purpose without redundancy or filler. Every word earns its place, and the key information is front-loaded.

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

  Completeness4/5

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

  Given the tool's simplicity (no parameters, no output schema, no annotations), the description is largely complete for an agent to invoke it correctly. It tells the agent what the tool lists and the account scope. A minor gap is the lack of any mention of the return structure (e.g., folder names vs. full paths), but this is not critical for a low-complexity tool.

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

  Parameters4/5

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

  The tool has zero parameters, so schema coverage is effectively 100%. The description needs to add nothing about parameters; the baseline for no parameters is 4, and the description does not detract from it.

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

  Purpose5/5

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

  The description uses a specific verb 'List' and names the exact resource 'all available IMAP folders/mailboxes' within the scope 'Yahoo Mail account'. It is immediately clear what the tool does and distinct from sibling tools like list_emails or search_emails.

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

  Usage Guidelines3/5

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

  The description gives no explicit guidance on when to use this tool versus alternatives. While it is self-evident that this is for folders and not emails, there is no mention of exclusions or conditions, leaving the agent to infer its place among siblings.

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

• search_emailsA
  4/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the burden. It adds useful non-obvious behavior: UIDs are permanent and do not change when emails are deleted, which helps agents trust them for future calls. It does not explicitly state read-only status, though 'Search' 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.

  Conciseness5/5

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

  Three sentences, all contributing value: the purpose is front-loaded, the UID permanence note is meaningful, and the chaining guidance is actionable. No filler or redundancy.

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

  Completeness4/5

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

  With no output schema, the description adequately explains the return value (UIDs) and how to use it. It covers the important chaining behavior and leaves parameter specifics to the highly detailed schema, 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.

  Parameters3/5

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

  Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds no parameter-level meaning beyond the generic 'advanced filters' phrase, which does not enhance the schema.

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

  Purpose4/5

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

  The description clearly states the tool searches emails with advanced filters and returns UIDs, which are stable identifiers. It distinguishes itself via the focus on UIDs for downstream operations, but does not explicitly contrast with sibling tools like list_emails, and the phrase 'using UIDs' is slightly awkward.

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

  Usage Guidelines4/5

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

  The description tells agents to use this tool when they need UIDs for subsequent operations, providing a clear context. It does not explicitly state when to prefer list_emails or exclude alternatives, 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.