Server Quality Checklist

Tool Scores

• rename_folderC
  2.5/5.0
  Behavior1/5

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

  No annotations are provided, and the description offers no behavioral details such as error handling, permissions required, side effects, or what happens if the old name doesn't exist. The description is entirely silent on these traits, placing full burden on the description, which it fails to meet.

  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 very short and front-loaded with the purpose, followed by a simple argument list. There is no superfluous text, making it efficient. However, the extreme brevity means it loses some value due to missing necessary context.

  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?

  Even though the tool is simple and an output schema is present, the description lacks essential context about failure conditions, naming rules, or behavior on invalid input. It doesn't explain what the output contains or when the operation succeeds. Given the minimal annotations, the description is incomplete for reliable tool invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description is the only source for parameter meaning. It provides 'old_name: Nuvarande namn' and 'new_name: Nytt namn,' but these are direct translations of the parameter names and add little beyond what the names already imply. The definitions are minimal and do not clarify formats, constraints, or edge cases.

  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 'Byt namn på en mapp' meaning 'Rename a folder,' which is a clear verb+resource pairing. It is unambiguous and distinct from sibling tools like create_folder or delete_folder, though it does not explicitly name those alternatives.

  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. The description only states the action and lists arguments, with no context on prerequisites, conditions, or situations where this tool is preferred.

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

• mark_email_unreadB
  3.1/5.0
  Behavior1/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 disclosing behavioral traits. However, it only says 'mark as unread' and provides no details about side effects, permissions, reversibility, or what the operation does beyond the literal action. This is insufficient for a tool that modifies email state.

  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 extremely concise: one sentence stating the purpose and a simple Args block. Every word earns its place, with no unnecessary fluff. The structure is clear and front-loaded, making it easy for an agent to parse quickly.

  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 tool, the description covers the essential operation and parameter meanings. However, it lacks any context about side effects, error conditions, or usage scenarios. Given the tool's simplicity and the presence of an output schema (which handles return values), the description is minimally viable but not rich. It would benefit from mentioning that it modifies the email's read/unread state.

  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 description provides brief explanations for both parameters (uid as the email's UID, mailbox as folder name with default INBOX). While the schema already includes names and a default, the description adds clarity by confirming the meaning of uid and mailbox. However, the explanations are minimal and do not go beyond what the parameter names hint at.

  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 'Markera ett e-post som oläst' (mark an email as unread), which is a specific verb+resource that directly distinguishes it from the sibling tool mark_email_read. The purpose is unambiguous and accurately reflects the tool's function.

  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?

  There is no guidance on when to use this tool versus alternatives. The description does not mention mark_email_read or any other context, and it lacks any when-to-use or when-not-to-use instructions. The only context is the tool name and sibling list, which are not referenced in the description.

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

• send_emailB
  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 bears the full burden. It mentions the return value (True if sent without error), but does not disclose side effects, irreversibility, authentication requirements, rate limits, or other behavioral characteristics typical of an email-sending tool.

  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 clean docstring format: a brief purpose line, a parameter list with descriptions, and a return value. Every line is functional and contributes to understanding, with no redundant or extraneous content.

  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 description covers all parameters and the return value, and an output schema likely exists. However, it lacks usage context, exclusions, and alternative guidance, which is important given no annotations and the presence of closely related sibling tools. It is adequate for a straightforward tool but leaves gaps.

  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 schema has 0% description coverage, but the description compensates by providing concise explanations for all 7 parameters, e.g., 'Brödtext i klartext' for body and 'Valfri HTML-version' for body_html. This adds meaning beyond the schema's type-only definitions, though some explanations are terse.

  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 'Skicka ett e-post' (send an email), clearly indicating a send operation with a list of parameters. It distinguishes from sibling tools like reply_to_email and forward_email by its name and focus on composing a new email, but it does not explicitly state this differentiation.

  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 provides no guidance on when to use this tool versus alternatives such as reply_to_email or forward_email. It is purely a parameter and return documentation with no contextual usage instructions.

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

• get_emailB
  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. It does not disclose side effects (e.g., whether the email is marked as read), authentication requirements, or error behavior. It only explains parameter formats and truncation behavior, which is parameter-level detail, not overall behavioral transparency.

  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 concise and front-loaded with the core purpose. The parameter documentation is structured and easy to scan, with every sentence serving a purpose. It is not overly verbose, but it is essentially a docstring rather than a narrative.

  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?

  Given that an output schema exists, return values are covered externally. However, the description lacks usage guidance, side-effect disclosure, and any error context. For a simple retrieval tool with well-documented parameters, this is acceptable but has clear gaps in behavioral and contextual clarity.

  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 input schema has zero description coverage, so the description compensates well by explaining each parameter: UID, mailbox default ('INBOX'), body_format options with meanings, and max_length truncation behavior (including None and ignoring for 'full'). This adds substantial meaning beyond the raw 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 says 'Hämta fullständigt innehåll för ett e-post via UID' which clearly states the verb (retrieve) and resource (email via UID). It implies full content retrieval, distinguishing it from sibling tools like get_email_headers or list_emails, though it does not explicitly name an alternative.

  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 the tool (when full email content is needed) but does not explicitly state when not to use it or name alternatives. The purpose is clear enough, but there is no direct comparison with sibling tools such as get_email_headers.

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

• create_folderB
  3.4/5.0
  Behavior2/5

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

  Annotations are absent, so the description carries the full burden. It does not disclose potential side effects, error conditions (e.g., duplicate folder names), permission requirements, or return behavior. Only the basic creation action is mentioned.

  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 extremely concise and well-structured. The purpose is front-loaded, and the Args section directly clarifies the parameter. Every sentence serves a clear function with no unnecessary text.

  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 tool with a single parameter and an output schema available, the description is largely sufficient. It clearly states the operation and parameter. While it could mention duplicate handling or permissions, these are minor gaps for a basic create operation.

  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 description includes an Args section explaining that 'name' is the name of the new folder ('Namn på den nya mappen'). This adds meaning beyond the schema, which only labels it as 'Name'. However, it does not provide additional details like allowed characters or length constraints.

  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 action: 'Skapa en ny mapp i brevlådan' (Create a new folder in the mailbox). It uses a specific verb and resource, and it is distinct from sibling tools like delete_folder or rename_folder.

  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 provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The description simply states what it does without contextualizing its use among siblings.

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

• delete_folderA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavior. It only states the empty-folder requirement, but does not mention that deletion is permanent, whether it fails on non-empty folders, or any permission requirements. This is minimal disclosure for a destructive operation.

  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 extremely short, with one sentence and an args block. Every word earns its place, and it is front-loaded with the action. No redundant content.

  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 single-parameter delete tool, the description is somewhat adequate but lacks context about error behavior or permanence. It does mention the critical empty-folder requirement, which is useful. The output schema exists but the description doesn't need to explain return values. However, given the tool's destructive nature, more context would help.

  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 input schema has a single 'name' string with no description. The description adds 'Namn på mappen att ta bort' (name of the folder to delete), giving semantic meaning to the parameter. However, it is essentially a restatement of the parameter's purpose and adds no format or validation details.

  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 action: 'Ta bort en mapp' (delete a folder). It also adds a constraining condition ('måste vara tom' – must be empty), which distinguishes this tool from rename_folder or create_folder. The verb and resource are specific.

  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?

  It provides a clear precondition that the folder must be empty before deletion. However, it does not mention when to use this instead of delete_email or rename_folder, nor does it specify any exclusion scenarios beyond emptiness.

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

• mark_email_readA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the core behavior (marking as read) but does not elaborate on side effects, idempotency, permissions, or return format. For a simple state-change operation, this basic disclosure is adequate, but additional context would be helpful.

  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 extremely concise—one sentence plus a compact Args list. Every element adds value, and the main verb+resource are front-loaded. No fluff or redundancy.

  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 tool with 2 simple parameters and an output schema, the description is minimally adequate. However, it lacks usage guidance, does not distinguish from the sibling 'mark_email_unread', and provides no context about error cases or behavior when the email is already read. More context 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?

  The schema has no descriptions (0% coverage), so the description compensates by explaining 'uid' as the email's UID and 'mailbox' as the folder name with a default. This adds meaning beyond structural field names, but it is minimal and does not explain how to obtain a UID or handle mailbox variations.

  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 action: 'Markera ett e-post som läst' (Mark an email as read). It uses a specific verb and resource, and immediately distinguishes from sibling mark_email_unread by the action it performs.

  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 is provided on when to use this tool versus alternatives. The description only explains the parameters and does not mention conditions such as 'use this to mark an email read, or mark_email_unread to mark as unread'.

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

• list_mailboxesA
  3.6/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden. It only says to list all folders/labels, but does not disclose details such as whether it returns a hierarchical structure, the order of results, authentication requirements, or if it only lists top-level folders. Minimal behavioral info.

  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, concise sentence that is front-loaded with the verb and resource. No wasted words.

  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?

  This is a simple tool with no parameters and an output schema exists (per context signals). The description adequately states the tool's purpose, and the output schema likely covers return structure. Missing details like sorting or nesting could be inferred or are non-essential for such a basic operation.

  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 takes zero parameters, and the schema coverage is 100% (vacuously). Per the baseline rule, a 4 is appropriate since there are no parameters to explain.

  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 action ('Lista' = List) and the resource ('alla mappar/etiketter i brevlådan' = all folders/labels in the mailbox). This is specific and distinguishes it from sibling tools like list_emails (which lists emails) and get_mailbox_status (which gets status).

  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 provided regarding when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions. It simply states what it does, leaving the agent to infer when it should be invoked.

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

• get_mailbox_statusA
  3.7/5.0
  Behavior2/5

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

  No annotations are present, so the description must carry the full burden, but it only states what the tool does without disclosing side effects, return structure, or required permissions. It does not even confirm it is a safe read-only operation, leaving the agent with uncertainty about its 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 concise: one purpose line and a parameter list. No filler or redundant repetition. It is front-loaded with the key function and structured clearly.

  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 the description lacks information about the return value format, whether counts are recursive, or how to obtain valid mailbox names (e.g., via list_mailboxes). Given no output schema and no annotations, this leaves gaps for an agent trying to use the tool correctly.

  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 0%, so the description must compensate, and it does. It explains that 'mailbox' is a folder name and provides the default value 'INBOX', which adds meaning beyond the schema's type and default fields. For a single parameter, this is adequate.

  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 retrieves the number of messages and unread messages in a folder, using a specific verb ('Hämta' / 'Get') and resource ('antal meddelanden' / 'number of messages'). This distinguishes it from sibling tools like list_mailboxes or get_email_headers.

  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 is self-explanatory for a status-checking tool, and the parameter is covered. However, it provides no explicit guidance on when to use this tool instead of alternatives, no exclusions, and no mention of prerequisites like first listing mailboxes.

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

• move_emailA
  3.7/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 full burden. It only states the action and args, without disclosing side effects like whether the email is removed from the source mailbox, if the target folder must exist, or if the operation is reversible. This is insufficient for a mutation tool.

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

  Conciseness5/5

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

  The description is extremely concise, with one sentence and a short argument list. Every element is relevant and there is no redundancy.

  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 tool with an output schema and full parameter descriptions, the description covers the essentials. However, it lacks usage context and behavioral details, making it only marginally complete for an agent that needs to understand consequences.

  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 schema has no descriptions for parameters (0% coverage), but the tool description provides clear Swedish explanations for uid, target_mailbox, and mailbox, including the default for mailbox. This compensates well for the missing schema text.

  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 action: 'Flytta ett e-post till en annan mapp' (move an email to another folder), with a specific verb and resource. It distinguishes from siblings like delete_email, mark_email_read, and send_email by focusing on moving between 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 gives no explicit guidance on when to use this tool versus alternatives. While the purpose implies usage for organizing emails, it does not mention exclusions or alternative tools for similar operations, such as copying or deleting.

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

• search_emailsA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It clearly specifies the return format (list of metadata dicts with uid, subject, from, date, flags), which adds value. However, it does not state whether the operation is read-only, how errors are handled, or any limitations (e.g., result caps, performance), leaving some transparency gaps.

  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 well-structured with Args and Returns sections, each line earning its place. It is concise, avoiding fluff, and front-loads the core purpose before providing parameter and return details. The format is scannable and efficient.

  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?

  The description covers the tool's purpose, all parameter semantics, and return value, which is substantial for a search/filter tool. The main omission is usage context relative to sibling tools, but this is more of a usage guideline gap. Given the tool's moderate complexity and the presence of an output schema, the description is nearly complete.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains all six parameters (mailbox, from_addr, subject, since, before, unseen) with concrete semantics, including format examples for dates and the tri-state unseen 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.

  Purpose4/5

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

  The description states 'Sök e-post med filter' (Search email with filters), which clearly identifies the tool's action and resource. It lists relevant filter parameters, but it does not explicitly distinguish itself from sibling tools like list_emails or get_email_headers, so it falls short of full differentiation.

  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 provides no guidance on when to use this tool versus alternatives such as list_emails or get_email_headers. It does not mention any prerequisites, exclusions, or comparison to other tools, leaving the usage context entirely up to the agent's inference.

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

• forward_emailA
  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. It does disclose the forwarding behavior (Fwd prefix and quoting), but lacks details on side effects such as whether the original email is modified, attachment handling, or permission requirements.

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

  Conciseness5/5

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

  The description is concise, with a brief summary followed by a tight argument list. Each sentence provides meaningful information, and the structure is easy to scan.

  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?

  The description covers the core purpose, behavior, and all parameters, and an output schema exists to define return values. It lacks explicit alternatives or edge-case information, but is reasonably complete for a simple forward operation.

  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?

  With 0% schema description coverage, the description compensates by providing a one-line explanation for each parameter: uid, to, body, and mailbox, including default for mailbox and optionality for body. However, it could clarify the expected format of uid and how multiple 'to' addresses are handled.

  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 action (forward an email) and the behavioral specifics (sets Fwd: prefix and quotes the original), which distinguishes it from sibling tools like send_email and reply_to_email.

  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?

  Usage is implied by the tool name and description, but there is no explicit guidance on when to use this over reply_to_email or send_email, nor any exclusions or alternatives mentioned.

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

• delete_emailA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral transparency burden. It explicitly discloses that the operation marks the email as deleted and expunges it, which reveals the destructive and potentially permanent nature of the action. However, it does not mention reversibility or required permissions, so it is not fully transparent.

  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 extremely concise—two sentences with a structured Args list. It front-loads the core action and then adds parameter details without unnecessary filler.

  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 two-parameter deletion tool with an output schema, the description adequately covers the action and parameters. It lacks edge-case or error-related details, but those are not essential for a tool of this complexity.

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

  Parameters5/5

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

  The schema has no description coverage for its two parameters, but the description's Args section compensates by explaining uid as the email's UID and mailbox as the folder name with a default of INBOX. This adds crucial meaning beyond the raw schema.

  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 in Swedish: 'Ta bort ett e-post' (delete an email) and elaborates 'markerar som borttaget och expungerar' (marks as deleted and expunges), which precisely defines the deletion behavior. This distinguishes it from sibling tools like move_email or mark_email_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 provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It merely describes the operation without contextual usage hints.

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

• get_email_headersA
  4.1/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. It discloses the core behavior (does not load body, returns header fields or None if not found) but lacks details on permissions, error handling, or rate limits.

  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 compact, with a clear purpose statement followed by Args and Returns sections. Every sentence adds value, with no filler or repetition.

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

  Completeness5/5

  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 an output schema, the description covers purpose, parameters, and return value. The explicit list of returned header fields and the None case makes it complete for an agent to invoke correctly.

  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 0%, but the description compensates by explaining both parameters: uid as the email's UID and mailbox with its default (INBOX). It adds meaning beyond the schema, though it doesn't specify UID format.

  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 'Hämta headers för ett e-post utan att ladda body' (Get headers for an email without loading the body), providing a specific verb and resource. It clearly distinguishes from get_email by emphasizing the exclusion of the body.

  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 only headers are needed (fast operation), but it does not explicitly mention alternatives like get_email or list_emails, nor does it state when not to use it.

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

• list_emailsA
  4.3/5.0
  Behavior4/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. It discloses pagination behavior (page-based), parameter semantics, and the exact return structure (messages, total, page, pages, has_more). It also notes 'metadata' to indicate non-full email content, providing useful behavioral context beyond just the tool's name.

  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 concise and well-structured: a one-sentence summary followed by clear Args and Returns sections. Every sentence adds value, and the format makes it easy for an agent to parse the essential information quickly.

  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?

  The description covers purpose, parameters, and the high-level return keys, which is sufficient for basic usage. However, it does not specify the structure of each message in the 'messages' list (e.g., id, subject, sender), which is a gap given there is no output schema. Still, it is fairly complete for a paginated list tool.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description fully compensates by explaining each parameter: mailbox (foldername, default INBOX), page (1-based page number), and page_size (number per page). It adds meaning to the schema by specifying defaults and the 1-based nature of page, which the schema does not provide.

  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: 'Lista e-post i en mapp med metadata' (list emails in a folder with metadata) with page-based pagination. This specifies the verb (list), resource (emails in a folder), and scope (metadata), distinguishing it from sibling tools like get_email (single email) or get_email_headers (headers only).

  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 for listing emails in a folder with pagination, but it does not explicitly state when to prefer this tool over alternatives like search_emails or get_email_headers. There is no when-not-to-use guidance or mention of alternatives, so usage context is only implied.

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

• reply_to_emailA
  4.3/5.0
  Behavior3/5

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

  No annotations are present, so the description must carry the full behavioral burden. It adds value by disclosing that In-Reply-To, References, and Re:-prefix are set automatically. However, it does not state other side effects such as whether the email is actually sent, whether the original is modified, or any authentication requirements.

  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 compact: a single sentence describing the action and behavior, followed by a concise list of parameters. Every sentence contributes essential information, with no 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?

  For a reply tool with 4 parameters and no annotations, the description covers the core behavior, parameter semantics, and a key behavioral detail (automatic header setting). It doesn't elaborate on return values, but an output schema is present, so that is not required. Missing details like side effects are limited but not severe.

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

  Parameters5/5

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

  The input schema provides only types and defaults, with 0% description coverage. The tool description compensates by explaining each parameter: uid identifies the email, body is the plain-text reply, mailbox defaults to INBOX, and body_html is an optional HTML version. This fully clarifies parameter meaning beyond the schema.

  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 opens with 'Svara på ett e-post' (reply to an email), clearly identifying the action and resource. It further distinguishes from siblings by noting automatic In-Reply-To, References, and Re:-prefix handling, which is specific to reply functionality.

  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 provides a clear context: it is for replying to an existing email, which differentiates from send_email or forward_email. However, it does not explicitly mention when not to use it or reference sibling tools as alternatives.

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