Server Quality Checklist

Tool Scores

• delete_mailC
  2.6/5.0
  Behavior2/5

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

  The description mentions the 'mail:manage' scope, which gives some permission context. However, since no annotations are provided, the description carries the full burden and does not disclose whether deletion is permanent or reversible, what side effects occur, or whether items are moved to trash.

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

  Conciseness3/5

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

  The description is very short and front-loaded, with no unnecessary words. However, it is under-specified even for a simple deletion tool, so the brevity is not fully appropriate.

  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 destructive one-parameter tool with no output schema and no annotations, the description leaves important context unstated, such as whether deletion is permanent and where the mail id comes from. An agent could invoke it with an id, but the missing behavioral details make it incomplete.

  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?

  The schema only defines 'id' as a required string with no description, and schema description coverage is 0%. The description does not explain what id refers to, where to obtain it, or its expected format; this is only implied by the tool name.

  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 ('delete') and the resource ('a mail'), and names the required permission scope. It is distinguishable from siblings like update_mail and delete_mailbox, though it does not explicitly call out that 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?

  There is no guidance about when to use this tool versus alternatives such as update_mail, delete_mailbox, or moving a mail to trash. The only contextual hint is the permission scope, with no exclusions or alternative conditions.

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

• create_labelC
  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, but it only adds the OAuth scope and the obvious fact that the operation creates a label. It does not address idempotency, duplicate names, return behavior, or side effects.

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

  Conciseness5/5

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

  The description is extremely concise: one sentence for the action and one for the required scope. It is front-loaded and contains no filler.

  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?

  The tool is simple, but with no output schema and no annotations, the description leaves return behavior, error cases, and duplicate-label behavior unstated. It is enough for selecting the tool, but not for fully anticipating the outcome of an invocation.

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

  Parameters1/5

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

  The description adds no parameter meaning. The color parameter is already documented in the schema, while the required name parameter remains undocumented in both the schema and the description, so the 50% schema coverage is not compensated.

  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?

  States a specific action and resource: 'Create a label.' This clearly separates it from sibling operations like list_labels, create_mailbox, or create_contact, and the scope line adds a permission signal.

  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 on when to use this tool over alternatives, nor any exclusions or prerequisites beyond 'tag:write'. The intended use is only implied by the resource name and sibling context.

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

• send_mailC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must carry the behavioral burden, but it only adds the scope hint 'mail:send'. It does not disclose side effects, auth needs beyond the scope string, draft behavior, failure modes, or whether the email is actually delivered or just queued.

  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 extremely brief and front-loaded, with no wasted words. It is shorter than ideal for a 9-parameter mutation tool, but as a concise statement of the operation it is effective.

  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?

  Given 9 parameters, no annotations, no output schema, and no description of return behavior, this description is insufficient. An agent cannot determine whether to provide body_text or body_html, how attachments are referenced, what draft_id implies, or what happens on success/failure.

  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?

  The description adds no parameter meaning beyond what the schema already provides. The schema covers 6 of 9 parameters, so some semantics exist, but cc, bcc, and subject remain undescribed in both places. The description only reinforces the mailbox concept already present in mailbox_id.

  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 ('Send an email') and the resource ('from a mailbox'), making the core purpose unambiguous. It does not differentiate from sibling tools, but no sibling directly overlaps with sending, so the lack of differentiation is minor.

  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 intended use is implied by the verb and resource, and this is the only sending-related tool in the sibling list. However, the description does not explain when to choose draft_id vs composing a new message, nor does it mention exclusions or prerequisites such as a valid mailbox or recipient format.

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

• create_contactB
  3/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 transparency. It discloses that this is a write operation and provides the required OAuth/API scope 'contact:write,' which adds useful context. However, it doesn't mention what happens on duplicates, whether the operation is reversible, or what response is returned.

  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 extremely short and front-loaded: 'Create a contact' immediately conveys the operation. The second clause adds scope information without padding. It is concise, though almost too sparse.

  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 two-parameter create operation with no output schema, the description is minimally viable. It tells the agent what to do and the required permission scope. However, it leaves important context unstated, such as duplicate handling and return values, so it is not fully complete.

  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?

  The schema has 0% description coverage, and the description adds no parameter-level information beyond the tool name itself. The property names 'name' and 'email' are somewhat self-explanatory, but no format, validation rules, or constraints are described. The description does not compensate for the low schema coverage.

  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 and target: 'Create a contact.' This distinguishes it from sibling tools like create_mailbox, create_folder, and create_label because the resource is explicitly named. It doesn't elaborate on what constitutes a contact, so it stops short of a 5.

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

  Usage Guidelines2/5

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

  There is no explicit guidance about when to use this tool versus alternatives, no prerequisites, and no mention of behavior if the contact already exists. The only contextual hint is the scope 'contact:write,' which implies authorization but does not explain usage conditions.

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

• create_folderB
  3.1/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 reveals the required OAuth scope (folder:write) but omits other relevant behavioral traits for a create operation, such as behavior on duplicate names, whether parent folder creation is supported, reversibility, or error conditions. The core side effect ('create') is apparent, but additional transparency is minimal.

  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 carry all the content: the core action and the required permission scope. There is no fluff, and the primary action is front-loaded. For a simple create operation, this is appropriately concise.

  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?

  The description is too sparse for a mutation tool with no annotations, no output schema, and no parameter descriptions. An agent is left to infer prerequisites, conflict behavior, and whether the mailbox_id must reference an existing mailbox. The operation may be simple, but critical contexual details are missing.

  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 must compensate. It adds only that the folder is created 'in a mailbox', which lightly clues the role of mailbox_id, but it does not explain name format, mailbox_id format, or any constraints. The bare property names provide the only meaning, which is thin for an agent.

  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 verb ('Create') and a specific resource ('a folder in a mailbox'), clearly distinguishing it from sibling tools like create_label and create_mailbox. The addition of 'in a mailbox' narrows the scope beyond the tool name itself, making the purpose unambiguous.

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

  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. There is no mention of when not to use it, no prerequisites (e.g., mailbox must exist), and no reference to sibling tools like list_folders or create_label. The only additional line, 'Scope: folder:write', is a permission scope, not usage guidance.

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

• create_mailboxB
  3.1/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 carry the behavioral disclosure burden. It mentions 'Scope: mailbox:write', which gives some permission context, but nothing about failure modes, uniqueness constraints, or whether creation is reversible. The description relies entirely on the verb 'create' to imply mutation.

  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 consists of two short sentences with no filler. The core operation is front-loaded and the scope note is concise. Every word contributes meaning.

  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 creation tool, the description is minimally adequate. But with no annotations and no output schema, there are missing details such as duplicate-handling behavior, whether the created mailbox is returned, and any prerequisites beyond the scope hint. These gaps make it adequate rather than complete.

  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 domain_id and local_part. The description adds no additional parameter meaning beyond what the schema provides. The baseline of 3 applies because 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 verb and resource: 'Create a new mailbox.' This distinguishes it from siblings like update_mailbox, delete_mailbox, and list_mailboxes. It doesn't explicitly call out those alternatives, but the operation is unambiguous.

  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. An agent must infer that creating a new box is distinct from updating or deleting an existing one. There is no mention of prerequisites, such as checking address availability first.

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

• update_mailboxB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full burden of disclosure, but it only states that the operation updates settings and notes the permission scope 'mailbox:write'. It does not explain whether the patch is partial or full replacement, what happens to unspecified settings, or whether the operation is reversible. The auth scope is useful transparency, but other behavioral details are absent.

  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, front-loaded sentence that immediately states the action and target, followed by the permission scope. It is concise with no filler, and the examples are placed after the main clause to preserve clarity. The 'etc.' is slightly indefinite but does not detract significantly.

  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 annotations and no output schema, the description omits important operational details such as whether patch is a merge or replace, which fields are valid inside patch, and whether existing settings are cleared if omitted. It does provide examples and a required scope, but an agent would need more detail to confidently update a mailbox without unintended changes. Given the complexity of a free-form patch object, the description is too thin.

  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 only describes 'patch' generically as 'Fields to update', but the description enriches this by naming examples ('display name, signature') that belong in the patch object. It does not explain the 'id' parameter, though its purpose is self-evident from context. With 50% schema coverage, the description only partially compensates for the undocumented properties of patch.

  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 uses the specific verb 'Update' and the resource 'mailbox', and gives examples of settings ('display name, signature') to define the scope of changes. It clearly distinguishes itself from sibling tools like create_mailbox and delete_mailbox because it targets existing mailbox configuration. However, it does not explicitly differentiate itself from related tools like get_mailbox, relying on the verb to imply the operation.

  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 a mailbox exists and needs settings modified—but provides no explicit conditions, exclusions, or references to alternatives. It does not say 'use this instead of create_mailbox' or mention prerequisites like the mailbox needing to exist. This leaves usage context mostly implicit.

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

• delete_mailboxB
  3.4/5.0
  Behavior3/5

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

  The description conveys that deletion is destructive and irreversible ('permanently') and indicates the required scope. However, it does not disclose what happens to associated data such as mails, labels, contacts, or signatures, and there are no annotations to fill this 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 two short, front-loaded clauses with no filler. The destructive nature and required scope are both communicated efficiently.

  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 one-parameter destructive action, the description covers the operation, permanence, and permission scope. However, with no annotations or output schema, it leaves material gaps around side effects, return values, and irreversibility details beyond the word 'permanently.'

  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%, and the description adds no information about the 'id' parameter beyond the schema's minimal string type and required flag. For a low-coverage schema, the description should compensate but does not.

  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 verb ('Delete') and resource ('a mailbox') with the critical qualifier 'permanently.' This clearly distinguishes it from siblings like delete_mail and update_mailbox by resource.

  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 for when to use this tool versus alternatives such as create_mailbox, update_mailbox, or delete_mail. The 'Scope: mailbox:write' note conveys permission requirements, not usage conditions or exclusions.

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

• get_statsB
  3.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. The verb 'Get' and 'Scope: storage:read' disclose that this is a read-only operation, which is useful. However, it does not describe what statistics are returned, whether the data is aggregated, or any response format, so it is only minimally 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 two short, direct sentences with the action and resource front-loaded. There is no filler or redundant wording.

  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?

  With no output schema and no annotations, the description should clarify what 'account statistics' means and what the response will contain. The storage:read scope helps, but the exact statistics and result shape are left vague, which could cause confusion with sibling tools like get_quota.

  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 and schema coverage is 100%, so there is no parameter meaning for the description to add. The 0-parameter baseline of 4 applies.

  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 uses a clear verb ('Get') and resource ('account statistics'), and 'Scope: storage:read' narrows the domain. However, it does not specify what statistics are included or explicitly differentiate the tool from siblings like get_quota.

  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 storage-related siblings such as get_quota or list_mailboxes. The description only states the function and scope, with no usage context, prerequisites, or exclusions.

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

• list_contactsB
  3.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, and 'Scope: contact:read' does add one behavioral trait: this is a non-mutating read operation requiring the read scope. However, it discloses nothing about response behavior — pagination, result limits, ordering, or whether full contact objects or summaries are returned — which matters for a listing 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?

  Two clipped fragments — the operation ('List contacts') and the scope tag — with zero filler words. The core verb and resource are front-loaded and every token earns its place. This is appropriately sized for the tool's simplicity.

  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 zero-parameter tool with no nested objects, the description covers the operation and the required auth scope, which is a solid baseline. But there is no output schema, and the description gives no hint about return characteristics (all contacts at once vs paginated, which fields are included), leaving the agent uncertain what the call will produce. A single clause about the result shape would round it out.

  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 and an empty input schema, so the rubric baseline of 4 applies. There is nothing for the description to supplement; it correctly omits param detail since none exists.

  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 uses a specific verb ('List') with a clear resource ('contacts'), and the 'Scope: contact:read' tag reinforces that this is the read-only listing operation, implicitly distinguishing it from the write-oriented create_contact sibling. It does not explicitly name or contrast any sibling, so it stops short of a 5, but there is no ambiguity about what the tool does.

  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 on when to use this tool versus alternatives. The description names no sibling, states no exclusion or alternative condition, and the only added context ('Scope: contact:read') is an auth/permission tag, not usage guidance. The agent must infer when to call it purely from the verb 'List', which is essentially restating the tool's name.

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

• list_mailsB
  3.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 behavioral burden. 'List' and 'Scope: mail:read' usefully indicate a read-only operation, but the description does not disclose return format, ordering, or how pagination interacts with the response. The schema covers basic defaults, so the gap is moderate.

  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 first states the action and the main optional filter, and the second provides the security scope. Every sentence contributes 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?

  For a paginated listing tool, the required mailbox_id and optional folder/page/per_page are clearly represented by the schema plus description, and the scope note adds useful auth context. It does not describe the returned shape, but no output schema exists and 'list' implies a collection; the main missing piece is sibling differentiation, already reflected in the usage-guidelines score.

  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 75%, so the schema already documents page, per_page, and folder. The description adds only 'filtered by folder', which aligns with the folder parameter, but does not add meaning for the required mailbox_id or any param values 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 specific verb and resource: lists mails in a mailbox, optionally filtered by folder. This distinguishes it from get_mail for single-mail retrieval and from mailboxes-related siblings, though it does not explicitly contrast with search_mails.

  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 on when to use this tool versus search_mails or other listing tools, and no exclusions or recommended contexts are given. The agent can only infer that this is for listing mailbox contents from the verb and resource.

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

• check_addressA
  3.5/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 behavioral disclosure burden. It adds 'Scope: mailbox:read,' indicating a read-only operation, but it does not explain what 'available' means, whether there are side effects, or how errors and responses are structured.

  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 front-loaded sentence plus a short scope qualifier. It contains no filler and every element contributes to understanding the tool's purpose.

  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 and its only parameter is well documented in the schema, but there is no output schema and the description does not specify the return value or the precise definition of 'available.' This makes the definition adequate but not fully complete.

  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 already fully documents the single 'address' parameter with an example ('hello@example.com'), so schema coverage is 100%. The description adds no additional parameter meaning beyond the schema, which is the baseline case for this dimension.

  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 ('Check whether') and a specific resource ('mailbox address is available'), which distinguishes it from sibling mailbox operations like get_mailbox or create_mailbox. The 'Scope: mailbox:read' qualifier reinforces that this is an availability predicate rather than a mailbox mutation.

  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 about when to call this tool versus alternatives such as create_mailbox or get_mailbox. The phrase 'is available' implies a pre-creation check, but the description never states that usage scenario explicitly or mentions any when-not-to-use conditions.

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

• search_mailsA
  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 burden of behavioral disclosure. It usefully discloses the required 'mail:read' scope, signaling a read-only operation, but does not mention pagination, result shape, or whether partial matches are returned.

  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, efficient sentences: purpose is front-loaded and the scope note follows without excess. Every word 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 single fully documented parameter keeps complexity low and the auth scope is helpful. However, with no output schema, the description still leaves uncertainty about what the search returns—full messages, summaries, or IDs—and whether pagination applies.

  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 schema already documents q as 'Search query'; the description's 'full-text' clarifies the kind of matching but adds no format or syntax details.

  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 specific verb ('search') and resource ('mails'), and 'full-text' distinguishes it from list-style siblings such as list_mails. However, it does not explicitly name an alternative, so it stops short of a full 5.

  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 use for full-text queries, but provides no explicit when-to-use or when-not-to-use guidance. It also does not point to sibling tools like list_mails for broader listing needs, leaving the usage context 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.

• update_mailA
  3.5/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 of behavioral disclosure. It reveals that the operation mutates mail state and names common update targets, and it adds the mail:manage scope requirement. However, it does not explain patch merge semantics, side effects of folder changes, or response 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?

  One efficient sentence with concrete examples and a scope note, all front-loaded. There is no filler 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?

  Given no annotations, no output schema, and a free-form patch object, the description provides enough to infer the basic call shape and intent, but it omits details like valid field formats, folder semantics, and return values. It is minimally adequate but has clear gaps.

  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 only documents patch generically as 'Fields to update, as a JSON object', and id has no description. The description adds useful examples (read/unread, flags, folder) that clarify patch contents, but it does not explain id or the exact shape of the patch object.

  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 ('Update') on a clear resource ('mail state') and gives concrete examples (read/unread, flags, folder). It is distinguishable from sibling tools like update_mailbox because it targets mail state rather than mailbox settings.

  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 such as get_mail, update_mailbox, or delete_mail. 'Scope: mail:manage' indicates a permission requirement but does not explain usage conditions or when another tool would be more appropriate.

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

• get_mailA
  3.6/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 context. 'Get' and 'Scope: mail:read' indicate a read-only operation, but the description does not disclose what 'full details' includes, whether it returns attachments, or how errors like missing IDs are handled.

  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 short phrases that immediately state the operation and scope. It front-loads the core purpose and contains no filler or redundant information.

  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 get-by-id tool with one parameter, the description is adequate for basic invocation. However, with no output schema and no annotations, the absence of information about the returned 'full details' structure, possible error cases, or authorization requirements beyond a terse scope label leaves notable gaps.

  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 should compensate by explaining the meaning of the 'id' parameter. It only says 'single mail,' leaving the agent to infer that 'id' identifies the mail to retrieve. No format, source, or validation guidance is provided.

  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 verb and resource: 'Get full details of a single mail.' This clearly differentiates it from list_mails and search_mails by focusing on a single mail rather than a collection or search result.

  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 this tool is for retrieving one specific mail, but it does not explicitly state when to prefer it over list_mails, search_mails, or get_mailbox, nor does it mention preconditions such as needing the mail ID from another call.

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

• list_foldersA
  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 full burden. It discloses the required access scope ('folder:read'), which implies a non-mutating operation, but it does not describe return format, pagination, or whether nested folders are included. This is a modest disclosure above the inherent behavior suggested by 'list'.

  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 concise sentences with no filler. The action and resource are front-loaded, and the scope note adds useful context without repetition.

  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 one-parameter tool with no output schema, the description covers the core action and parameter. However, it omits output shape, possible pagination, and any behavior around absent or empty mailboxes. It is adequate but not fully complete.

  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 0%, so the description must clarify the parameter. 'List folders of a mailbox' ties mailbox_id to the parent mailbox, but adds no details about id form, source, or accepted values. It provides minimal compensation for the undocumented 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 states a specific verb and resource: 'List folders of a mailbox.' This clearly distinguishes the tool from siblings like list_labels or list_mailboxes, and the scope 'folder:read' reinforces the read-only purpose.

  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: call this tool to enumerate folders for a given mailbox. However, it does not explicitly mention when to prefer this over list_labels or list_mailboxes, nor does it provide exclusions or alternative routing.

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

• list_labelsA
  3.8/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the behavioral disclosure burden. It communicates read-only access via 'List' and states an explicit OAuth scope 'tag:read', which is useful. However, it says nothing about output shape, pagination, ordering, or failure modes for a tool with no output schema.

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

  Conciseness5/5

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

  The description is extremely compact: one purpose sentence plus one scope annotation. Every element earns its place, and the core action is front-loaded with no distracting detail.

  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—zero parameters, no nested objects, and no output schema—the description provides sufficient context for invocation: what it lists and the required access scope. It does not describe the return representation, but for a simple list_labels operation this is a minor gap.

  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 and the schema description coverage is 100%, so there is no parameter meaning for the description to clarify. The baseline of 4 applies because no parameter information is needed.

  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 and resource pair: 'List labels.' The added scope 'tag:read' clarifies the read-only nature and distinguishes it from label-creation and other-resource listing tools such as create_label or list_mailboxes.

  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 about when to use this tool versus alternatives such as list_folders, list_mailboxes, or create_label. The resource name implies the use case, but the description does not state conditions, exclusions, or alternatives explicitly.

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

• list_rulesA
  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 bears the burden. It discloses the required OAuth scope 'filter:read' and 'List' implies a read-only operation, which adds some behavioral context. It does not mention return format, pagination, or error behavior, so it is only moderately 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: one sentence plus a scope note. Both statements carry meaningful information and the text is front-loaded with the core purpose.

  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 no-parameter, low-complexity tool, the description is nearly complete: it names the resource, the operation, and the required scope. The lack of an output schema and annotations slightly limits completeness, but nothing essential for making the call 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?

  The tool has zero parameters, and schema coverage is 100%. With no inputs to document, there is nothing the description needs to add. The zero-parameter baseline applies.

  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?

  It clearly states a specific verb and resource: 'List incoming-mail filter rules.' This distinguishes the tool from siblings like list_labels, list_mailboxes, and list_folders, since none of those cover filter rules. The additional scope note reinforces what the tool accesses.

  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, no context about prerequisites, and no exclusion cases. The description is accurate but does not help an agent decide between this and similar list-style tools.

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

• get_quotaA
  3.9/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. The scope 'storage:read' does disclose the read-only nature, which is useful, but the description doesn't mention what the response looks like (e.g., bytes, limits, per-resource breakdown) or any required permissions. For a simple getter this is adequate but not rich.

  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 waste. 'Get storage quota usage' names the action and resource, 'Scope: storage:read' adds the access context. Every word 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 simple with no parameters, so invocation is straightforward. However, there is no output schema, so the description must explain what the return value represents (usage in bytes, percentage, total quota, etc.) and it does not do so. Adequate for calling, incomplete for interpreting results.

  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 and the schema coverage is 100%, so there are no parameter semantics to document. The baseline of 4 for zero-parameter tools applies; the description doesn't need to add parameter 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 states a specific verb and resource: 'Get storage quota usage.' The scope annotation 'storage:read' reinforces the read-only nature. This clearly distinguishes the tool from sibling tools like get_mail or get_stats, none of which target storage quota.

  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 purpose is self-evident enough that an agent would infer when to use it, but there is no explicit guidance about alternatives or exclusions. 'Scope: storage:read' implies a read-only context, but it doesn't say 'use this instead of get_stats when you need quota details.'

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

• list_mailboxesA
  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 adds a useful behavioral detail by declaring 'Scope: mailbox:read', indicating the required permission. However, it does not disclose potential pagination, sorting, or return format, though the zero-parameter design makes the tool simple.

  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 exceptionally concise: two short sentences, with the primary action front-loaded. Every word adds value, including the scope annotation. There is no redundancy or 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 zero-parameter, no-output-schema list operation, the description is nearly complete. It states what the tool returns (all mailboxes) and the required scope. It could mention whether the result is limited or ordered, but this absence is not significant given the tool's simplicity.

  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 properties, so there are no parameter semantics to explain. The description appropriately focuses on the operation and scope. With 0 params, the baseline is 4, and the description does not need to compensate for missing parameter documentation.

  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 verb and resource: 'List all Smailr mailboxes.' This clearly identifies the operation and distinguishes it from sibling tools like get_mailbox (single mailbox) and create_mailbox (new mailbox). The added scope line reinforces the read-only nature.

  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: use this when you need to enumerate all mailboxes. However, it does not explicitly state when not to use it or mention alternatives such as get_mailbox for a specific mailbox. The context is understandable but left to inference.

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

• get_mailboxA
  4.2/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 signals a read-only operation through 'Get' and the explicit scope 'mailbox:read'. However, it does not disclose response format, error behavior, or whether any additional permissions are required, leaving some behavioral details unspecified.

  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 opens with the action and resource, then adds the required identifier and scope. Every word contributes useful 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?

  This is a simple read tool with one required parameter and no output schema. The description sufficiently conveys what the tool does and how to invoke it. It stops short of describing the returned detail fields, but for a 'get by ID' tool the provided scope and lookup key are largely enough.

  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 one undocumented 'id' parameter (0% schema description coverage). The description's 'by ID' directly clarifies that the parameter is the mailbox identifier, adding meaningful semantic context the schema alone 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 action ('Get'), the resource ('mailbox details'), and the lookup key ('by ID'). This distinguishes it from list_mailboxes, which returns multiple mailboxes, and from mutation siblings like update_mailbox.

  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 clear context: use this when you need details for a specific mailbox identified by its ID. It does not explicitly name alternatives or exclusions, but the intended usage is unambiguous enough given the sibling tool names.

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

• list_signaturesA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. 'List' implies a read-only operation and the 'Scope: signature:read' line adds useful permission context. However, it does not describe return format, ordering, empty-list behavior, or error cases, leaving some behavior implicit.

  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 contain only necessary information. 'List mail signatures' is front-loaded and 'Scope: signature:read' adds a relevant permission detail without wasting 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?

  For a zero-parameter list operation, this is nearly complete: it states the action, resource, and required scope. It omits the return shape, but the verb 'List' strongly implies a collection, and the absence of an output schema lowers the burden.

  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?

  There are zero parameters and the input schema is empty, so schema coverage is 100%. The description correctly does not need to explain parameter semantics; the baseline for a no-parameter tool applies.

  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 identifies the exact resource ('mail signatures'), making the operation unambiguous. It also distinguishes itself from sibling list_* tools such as list_mailboxes, list_labels, and list_mails by the resource name.

  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 intended use case is clear from the resource name and verb, and there are no exclusions. It does not explicitly name alternatives like list_mailboxes or list_labels, but since each sibling operates on a different resource, the differentiation is obvious without further guidance.

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

• upload_attachmentA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It communicates that this is a write operation ('upload', 'Scope: attachment:write') and explains the output contract (an attachment ID). It doesn't mention limits such as file size or cleanup, but the core behavior of creating an attachable artifact for send_mail is clearly disclosed.

  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 carry the operation, the return value, the downstream consumer, and the required scope. There is no filler, and all essential 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?

  For a one-parameter tool with no output schema, the description covers what the tool does, why to call it, what it returns, and the required scope. It could optionally mention failure conditions or size/type restrictions, but nothing needed for invoking it correctly is missing.

  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 describes file_path as 'Absolute path of the local file to upload' with 100% coverage. The description repeats the concept of a 'local file' but adds no format, size, or path-resolution details beyond the schema, so it doesn't meaningfully raise the baseline.

  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 ('Upload') with a clear resource ('a local file as a mail attachment') and states the key result: an attachment ID for send_mail. This distinct role is enough to separate it from all sibling mail operations, even without an alternative upload tool.

  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 explicitly says the returned attachment ID is for send_mail, which tells an agent when to call this tool: before sending a mail that needs an attachment. It doesn't explicitly list exclusions, but there are no competing upload alternatives in the sibling set to disambiguate against, so this guidance is sufficient.

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