fastmail-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation (single vs bulk, different resources like emails, mailboxes, masked emails, sieve scripts). No two tools have overlapping purposes; descriptions clearly differentiate them.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., create_mailbox, delete_email, list_identities). Bulk operations are prefixed with 'bulk_', and there are no mixed conventions or abbreviations.
Tool Count3/5
With 43 tools, the server covers a wide domain (email, mailboxes, masked emails, siege scripts, vacation, identities). While each tool has its place, the count is on the higher side and could be streamlined by reducing redundant bulk variants.
Completeness4/5
The tool surface covers core email workflows (send, reply, draft, labels, move, delete, search) plus mailbox, masked email, and sieve script management. A notable gap is the inability to send emails with attachments (only download is supported).
Average 3.9/5 across 43 of 43 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It indicates destructive action and a failure condition, but does not mention irreversibility, side effects, or error handling beyond the given constraint.
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, but it sacrifices completeness for brevity, lacking important behavioral and parameter details.
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 the presence of an output schema and many sibling tools, the description is too minimal to fully contextualize when and how to use destroy_sieve_script effectively.
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?
Schema coverage is 0% and the description does not mention the script_id parameter, failing to add any meaning beyond its type and requirement.
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 (destroy/delete) and the resource (Sieve script), and it distinguishes itself by noting a specific constraint: cannot destroy the currently active script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage constraint (cannot destroy active script) but does not offer explicit guidance on when to use this tool versus alternatives like update_sieve_script or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides some behavioral context: it implies a soft delete (trash) rather than permanent removal. However, it does not disclose permissions, reversibility, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose without wasted words. It is front-loaded with the action.
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 an output schema present, the description need not explain return values. However, it lacks detail on recovery from trash, confirmation behavior, and differentiation from similar tools. Adequate but not comprehensive.
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 coverage is 0%, and the description does not elaborate on the 'email_id' parameter beyond its type. It adds no additional meaning to help the agent understand the expected format or source of the ID.
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 ('Move an email to the Trash mailbox'), specifying the verb and resource. It distinguishes from sibling tools like 'destroy_mailbox' (different resource) and 'bulk_delete' (bulk operation).
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 alternatives such as 'destroy_mailbox' for permanent deletion or 'bulk_delete' for multiple emails. The description does not mention prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description indicates irreversibility ('permanently delete'), but lacks details on side effects, permissions, or consequences, 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?
Extremely concise single sentence, front-loaded with key action and object, no wasted words.
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?
Minimal description for a simple destructive operation; missing usage guidelines and behavioral details, but output schema may compensate partially.
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 coverage is 0%, and description adds no meaning beyond the parameter name 'masked_email_id', which is self-explanatory but does not specify format or source.
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 destroys/permanently deletes a masked email address, with a specific verb and resource, distinguishing it from siblings like update_masked_email or list_masked_emails.
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 vs alternatives (e.g., when to destroy vs update), no prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states the basic operation and parameter formats, but omits side effects, idempotency, error handling, or whether partial failures occur. For a bulk mutation tool, this is insufficient.
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 plus a parameter list) with front-loaded purpose. Every word serves a function, and there is no redundancy or unnecessary 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?
While the description explains purpose and parameters adequately for a simple tool, it lacks details about the output, error conditions, or behavior in edge cases. Given that an output schema exists, completeness is adequate but not rich.
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 adds value by explaining that 'email_ids' are 'Comma-separated email IDs (max 50)' and 'mailbox_ids' are 'Comma-separated mailbox IDs to remove.' This clarifies the format and batch limit beyond the schema's plain string type.
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 'Remove mailbox labels from multiple emails,' specifying the verb (remove), resource (mailbox labels), and scope (multiple emails). It distinguishes this tool from siblings like 'add_labels' and 'bulk_add_labels' by indicating a removal operation.
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. Given sibling tools like 'remove_labels' (likely for single emails) and 'bulk_add_labels', the absence of usage context leaves the AI uncertain about selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It notes the action is removal (mutation) but does not specify side effects, permanence, authentication requirements, or rate limits. The lack of detail limits transparency.
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 (3 sentences) with the main purpose front-loaded. Every sentence provides essential information without redundancy or fluff.
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, the description is adequate but lacks details on the result of removal (e.g., success/failure, response structure). It does not specify that it operates on a single email (contrasting with bulk siblings).
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 description adds meaning to both parameters: 'email_id: ID of the email' and 'mailbox_ids: Comma-separated mailbox IDs to remove.' This explains the format and purpose, compensating for the 0% schema coverage.
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: 'Remove one or more mailbox labels from an email.' This is a specific verb+resource pair that distinguishes it from siblings like 'add_labels' and 'bulk_remove_labels'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., 'bulk_remove_labels' for multiple emails). The description only states what it does, leaving the agent to infer context from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states the action without disclosing side effects (e.g., draft status after sending), permissions required, or rate limits. Minimal transparency.
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?
Description is extremely concise: one-line summary followed by parameter descriptions. No extraneous text; front-loaded with core 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?
Adequate for a simple tool with two parameters and an output schema (which is not shown but exists). Lacks details on error conditions, draft state implications, and success response. Could be more complete.
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 description adds meaning beyond the schema by explaining identity_id default ('empty for default') and describing both parameters. Although schema coverage is 0%, the provided descriptions are useful and clear.
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?
Description clearly states the verb 'send' and resource 'existing draft email', distinguishing it from siblings like create_draft or send_email. The phrase 'existing draft' explicitly indicates it operates on previously created drafts.
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 alternatives like send_email or edit_draft. No conditions, prerequisites, or explicit comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While it indicates a mutation (update), it fails to disclose side effects, such as whether changes take effect immediately, if validation occurs, or permission requirements. The behavioral impact beyond the action is under-specified.
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, with a clear purpose upfront and a structured 'Args' section. However, the format repeats parameter names unnecessarily and could be more streamlined.
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 the 4 parameters with no schema descriptions and no annotations, the description adequately explains all inputs. However, it lacks usage guidelines and behavioral transparency, so while operationally complete for invocation, it is incomplete for contextual decision-making.
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?
With 0% schema description coverage, the description adds meaning to all four parameters. It clarifies that 'name' and 'content' can be left unchanged by sending empty strings, and 'is_active' can be left unchanged by sending null. This adds critical semantics beyond the schema's type-only information.
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 verb 'Update' and the resource 'Sieve script', and lists the updatable fields (name, content, or active state). The sibling tools include create, destroy, get, list, and validate scripts, making this tool's purpose distinct.
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 does not provide any guidance on when to use this tool versus its siblings. It lacks explicit context for when to update versus create or delete scripts, and does not mention prerequisites or conditions for update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose behavioral traits such as permissions required, potential side effects, idempotency, or any constraints beyond parameter descriptions. The output schema is present but not referenced.
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?
Extremely concise: one line summary followed by parameter descriptions. No wasted words, front-loaded with purpose. Every sentence serves a 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?
Given the tool's simplicity (2 params, output schema present), the description covers the core purpose and parameter semantics well. It lacks mention of return value or error handling, but the output schema likely fills that gap. Could be improved by noting that the created mailbox object is returned.
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 description adds meaning beyond the input schema by explaining the 'name' as a display name and 'parent_id' for nesting, with default value meaning top-level. Since schema description coverage is 0%, this is valuable. However, constraints like name length or allowed characters are missing.
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 'Create a new mailbox (folder)', using a specific verb and resource. It distinguishes from sibling tools like destroy_mailbox, update_mailbox, and list_mailboxes by being the creation counterpart.
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 alternatives. An agent must infer from the name and siblings. No conditions, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals that moving replaces all current mailbox assignments, which is key behavioral context. However, it does not mention authorization needs, rate limits, or what happens to previous assignments (e.g., whether the email is removed from all previous mailboxes).
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 short (two sentences plus Args list) and front-loaded with the main purpose. The Args section is structured but could be integrated into the prose to reduce length. Overall, efficient with no waste.
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 2 parameters, no enums, and an output schema existing, the description is adequate but has gaps. It lacks guidance on when to use this tool over bulk_move, does not mention error cases (e.g., invalid IDs), and does not elaborate on the effect on existing mailbox assignments beyond 'replaces all'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. The Args section explains each parameter ('ID of the email' and 'Target mailbox ID'), but this is minimal—essentially restating the field names. No format hints or examples are 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 clearly states the action: 'Move an email to a different mailbox' and includes a clarifying note that it 'replaces all current mailbox assignments'. This distinguishes it from siblings like bulk_move by indicating it handles a single 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?
No explicit guidance on when to use this tool vs alternatives such as bulk_move for multiple emails. The usage is implied by the single-email parameter, but no when-not-to-use or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states basic action without disclosing side effects, rate limits, or response details beyond the parameters.
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?
Exceptionally concise, two sentences plus args, front-loaded with core purpose, no unnecessary words.
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?
Adequate for a simple tool with output schema present, but lacks usage guidance and behavioral details; gaps in when-to-use and error handling.
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?
Adds meaning beyond schema: explains format and max for 'email_ids' and boolean mapping for 'pinned', compensating for 0% schema description coverage.
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?
Description clearly states verb 'pin (flag) or unpin', resource 'multiple emails', distinguishing it from sibling 'pin_email' which likely handles single emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied for multiple emails but no explicit when-to-use vs alternatives like 'pin_email' or 'bulk_add_labels'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It mentions the 'pending' state expiration, which is helpful, but does not disclose other behaviors like rate limits, idempotency, or error cases.
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 efficient and front-loaded with the purpose, then lists parameters. It is well-structured with minimal waste, though slightly verbose in the pending-state note.
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 presence of an output schema, return value documentation is unnecessary. The description covers the creation process and key parameter details. Missing prerequisites or context like authentication, but overall sufficient.
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?
Despite 0% schema coverage, the description explains all four parameters with roles and defaults (e.g., 'for_domain' as domain, 'state' with default 'enabled'). However, it lacks format constraints or examples.
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 the clear verb 'Create' with the specific resource 'masked email alias'. It distinguishes from siblings like 'update_masked_email' and 'destroy_masked_email' by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'update_masked_email'. The description implies usage for creating aliases but lacks when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the destructive nature and failure conditions, but it omits other behavioral traits such as permission requirements, reversibility, or the fate of mailbox contents. The existence of an output schema is noted but not leveraged.
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 that deliver the core purpose and a critical constraint. Every word serves a purpose, 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 simple destructive tool with a single parameter and an output schema, the description covers the essential context (action and failure triggers). It lacks details about prerequisites or side effects, but the tool's simplicity reduces the need for more.
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 single parameter 'mailbox_id' is not explained beyond its schema type. With 0% schema description coverage, the description fails to add context such as format, expected values, or how to obtain the ID. This leaves the agent to guess or rely on external knowledge.
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 ('Destroy (delete) a mailbox') and the specific resource. It adds a critical condition ('Fails if the mailbox has children or is a system role'), which helps distinguish it from other tools by clarifying its limitations.
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 you want to delete a mailbox) and provides a condition that must be met (no children, not a system role). However, it does not explicitly guide when to use this tool versus alternatives (e.g., update_mailbox for deactivation) or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It discloses that the content is downloaded from blob storage, which is a useful behavioral detail. However, it does not mention any side effects (none expected), required permissions, or rate limits. The description adds some value beyond the function name but is not fully comprehensive.
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, well-structured sentence that efficiently conveys the purpose and a key detail. No extraneous words; every word adds value.
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 low complexity (single parameter) and presence of an output schema, the description is fairly complete. It explains the action, resource, and a technical detail (blob storage). It could mention error scenarios or validation of script_id, but for a simple getter, it is sufficient.
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 single parameter 'script_id' has a 0% schema description coverage. The tool description merely says 'by ID', which repeats the parameter name without adding semantic details such as the expected format, example, or source. For a parameter with no schema description, the description should compensate more, but it 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 explicitly states the verb 'Get', the resource 'Sieve script', and adds specificity with 'by ID, including its full content (downloaded from blob storage)'. This clearly distinguishes it from sibling tools like list_sieve_scripts (which lists all scripts) and create_sieve_script (which creates a new one).
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 the tool is used when a specific Sieve script is needed, but it does not provide explicit guidance on when to use it vs. alternatives like list_sieve_scripts or when not to use it. No prerequisites or contexts are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions a max of 50 emails but omits error handling, partial success behavior, idempotency, or side effects beyond the basic 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?
Extremely concise, with two sentences plus parameter descriptions. No filler, all essential information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no enums) and presence of output schema, the description covers the core behavior. Could add more on failure modes or idempotency, but sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds format (comma-separated) and a limit (max 50) for email_ids, adding value beyond the schema's plain type definition.
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?
Clear verb 'Add' and specific resource 'mailbox labels to multiple emails'. Distinguishes from sibling tools like 'add_labels' (single) and 'bulk_remove_labels'.
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 a bulk operation but does not explicitly state when to use versus alternatives like 'add_labels' or when not to use it (e.g., for small batches). No exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the operation 'replaces existing mailbox assignments,' implying destructiveness. It also includes the max 50 limit. Without annotations, more behavioral details (e.g., idempotency, partial failure handling) would be beneficial.
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 two sentences and an Args section. No redundant or extraneous information is present.
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 has an output schema but no mention of return values (e.g., success count, failures). For a bulk operation, this is a significant omission. The description leaves out expected 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?
Schema description coverage is 0%, but the description adds meaning: 'Comma-separated email IDs (max 50)' for email_ids and 'Target mailbox ID' for mailbox_id, which are not present in 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 'Move multiple emails to a mailbox (replaces existing mailbox assignments),' which specifies the verb, resource, and effect. It distinguishes from siblings like 'move_email' (single) and 'bulk_delete' (different action).
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 mentions a max of 50 email IDs in the argument description, providing a constraint. However, it does not explicitly state when to use this tool over siblings (e.g., 'move_email' for single moves) or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits such as what happens on name conflict, syntax validation, or permissions. It only mentions the activation constraint, leaving other behaviors undisclosed.
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 plus a structured Args block, front-loaded with the main purpose. Every line adds value, and there is no unnecessary text.
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 the basic operation but lacks details on constraints like name uniqueness, content format, or expected output. However, the presence of an output schema reduces the need to describe return values.
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?
Given 0% schema description coverage, the description fully explains each parameter: name, content, and is_active with the activation note. This adds essential meaning beyond the schema type definitions.
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 verb 'Create' and the resource 'new Sieve filter script', which is distinct from sibling tools like update_sieve_script, destroy_sieve_script, and validate_sieve_script.
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 does not explicitly state when to use this tool versus alternatives like validate_sieve_script, but the is_active parameter note 'only one script can be active' provides some usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 correctly states the tool returns a summary (total emails, unread count, mailbox breakdown) but does not disclose that it is read-only, requires no parameters, or any authorization needs. The description is accurate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose ('Get an aggregate account summary') and lists key output components. Every word is necessary; there is no wasted 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?
Given the tool has no parameters and an output schema exists (context indicates true), the description is reasonably complete. It states the nature of the output, though the full output schema may define additional fields. The description suffices for a simple read 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 has no parameters, and the schema coverage is 100% (empty schema). Per guidelines, the baseline score is 4 when there are zero parameters. The description does not need to add parameter information.
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 an aggregate account summary with specific fields (total emails, unread count, mailbox breakdown). This distinguishes it from sibling tools that operate on individual emails or mailboxes, such as get_mailbox_stats, which is per-mailbox rather than account-level.
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 explicit guidance on when to use this tool versus alternatives. Siblings like get_mailbox_stats could be confused for similar functionality, but no contrast is offered. The usage context is only implied by the description of the output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It does not specify whether the tool is read-only, if it requires authentication, or what happens with invalid mailbox IDs. While it mentions the scope (one or all mailboxes), other critical behavioral details are missing.
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 two short sentences, all front-loaded with the main purpose. Every sentence adds value, and there is no redundancy or wasted text. The structure is efficient and clear.
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 low complexity (1 parameter, no nested objects) and the presence of an output schema, the description provides sufficient context for invocation. It explains the main behavior and parameter semantics. However, it does not detail what the 'email count statistics' include (e.g., total, unread), which could be inferred from the output schema but is not explicitly stated.
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 0% coverage (no descriptions), so the description must explain the parameter. It does so effectively: 'mailbox_id: Specific mailbox ID (empty for all mailboxes).' This adds clear meaning beyond the schema, specifying valid values and behavior, which compensates for the lack of schema descriptions.
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: 'Get email count statistics for one or all mailboxes.' It uses a specific verb ('Get') and resource ('email count statistics' for mailboxes), which distinguishes it from sibling tools like list_mailboxes or get_emails. The purpose is immediately understandable.
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 obtaining email counts but does not explicitly state when to use this tool versus alternatives, nor does it provide conditions or exclusions. No guidance is given on when not to use it or what other tools cover different use cases, leaving ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the core behavior (mark read/unread) but lacks details on side effects, authorization needs, or rate limits. Acceptable for a simple toggle.
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 concise sentences with no wasted words. Clear and 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 simple boolean toggle tool with output schema, the description is adequate. It covers the action and both parameters. Could mention output briefly, but not critical given 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?
Schema description coverage is 0%, so the description must compensate. It explains email_id as the ID and read as a boolean with default true, adding meaningful context beyond the schema's type definitions.
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 explicitly states 'Mark an email as read or unread,' which is a specific verb+resource combination. It clearly distinguishes from sibling tools like bulk_mark_read and other email actions.
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 does not provide any guidance on when to use this tool versus alternatives. There is no mention of 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description discloses pin/unpin behavior and default value for 'pinned'. Lacks details on side effects, permissions, or reversibility.
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?
Concise with clear format (Args listing). Efficient use of words, though slightly verbose for a simple tool.
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 output schema exists, description adequately covers purpose and parameters. Does not mention return values, but not required due to output schema.
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 coverage is 0%, but description fully explains both parameters: email_id as identifier, pinned as toggle with default True. Adds meaning beyond schema types and 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?
Description clearly states the action (pin/unpin) and resource (email). Distinguishes from sibling 'bulk_pin' by focusing on single email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'bulk_pin'. Implies single-email use but doesn't contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'send immediately' but does not disclose behavioral traits like error handling, rate limits, delivery guarantees, or irreversibility. While it lists parameters, it omits important behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise with a short opening sentence and a structured parameter list. However, the parameter list is slightly verbose with default values shown, and the format could be more compact. Still, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters (2 required), no annotations, and an output schema present, the description covers parameter semantics well but lacks usage context, errors, or return value details. It is complete enough for basic use but could benefit from mentioning threading behavior and error conditions.
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?
With 0% schema coverage, the description adds full meaning: it explains each parameter's purpose and format (e.g., 'comma-separated' for to/cc/bcc, 'use list_identities to see options' for identity_id). This goes far beyond the schema's minimal type information.
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?
Description clearly states the tool 'Compose and send an email immediately.' The verb 'send' and resource 'email' are specific, and it distinguishes from sibling tools like create_draft (which only creates a draft) and reply_email (which is a specific reply action).
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 immediate sending but lacks explicit guidance on when to use this versus alternatives such as create_draft or reply_email. No prerequisites or exclusions are provided, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds the behavioral trait that labels are added without removing existing ones. However, it does not disclose what happens if a label already exists (e.g., idempotent or duplicate), nor any side effects or permissions needed, which limits transparency.
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 purpose and two lines for parameter definitions. It is well front-loaded with the primary action, and every part is necessary.
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?
Given the tool's simplicity (two required string parameters, no nested objects) and the existence of an output schema, the description covers the essential information: what the tool does and how to specify the inputs. It is complete for the task.
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 coverage is 0%, but the description explicitly defines the parameters: 'email_id: ID of the email' and 'mailbox_ids: Comma-separated mailbox IDs to add,' adding semantic meaning beyond the schema's type-only specification.
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: 'Add one or more mailbox labels to an email (without removing existing ones).' It distinguishes itself from sibling tools like 'remove_labels' and 'bulk_add_labels' by specifying the additive nature.
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 'bulk_add_labels' or 'remove_labels'. It does not mention when to avoid using it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains parameter defaults and the effect of leaving fields empty ('to leave unchanged'), but does not disclose side effects (e.g., overwriting existing settings), authentication requirements, or whether the tool creates vs. updates.
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 uses a readable 'Args' list but is somewhat verbose (e.g., repeating 'Empty to leave unchanged' for multiple fields). It could be streamlined without losing clarity, but remains functional.
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 tool with 6 parameters and no annotations, the description covers all parameter semantics effectively. It does not describe the return value, but the presence of an output schema mitigates this gap. Overall, it is nearly complete for its purpose.
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 compensates fully by detailing each parameter: is_enabled (required), date formats (ISO 8601), and the meaning of empty strings. This adds significant value beyond the schema's type and default fields.
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 begins with 'Set or update the vacation / out-of-office auto-reply,' clearly stating the verb (set/update) and resource (vacation auto-reply). This accurately differentiates it from sibling tools, such as get_vacation_response (read) and other email operations.
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 does not explicitly state when to use this tool versus alternatives, such as get_vacation_response for reading settings. The usage is implied by the purpose, but no exclusions or contextual hints are provided, leaving the agent to infer based on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral disclosure. It mentions the basic operation and a constraint (max 50), but does not discuss idempotency, error handling, or partial failure 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 extremely concise, consisting of two short sentences and a bulleted args block. Every element is useful 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?
The description covers the core purpose, parameter details, and basic constraints. An output schema exists (though not shown), so return value explanation is not needed. However, it lacks details on behavior for invalid input or partial failures, which would elevate completeness further.
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. It explains that email_ids is a comma-separated list with a max of 50, and that read is a boolean with a default of true, adding meaning beyond the schema's type info.
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 specifies the action ('mark multiple emails as read or unread') with a specific verb and resource, distinguishing it from siblings like 'mark_email_read' (singular) and other bulk operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context (e.g., max 50 email IDs) but lacks explicit guidance on when to use this tool over alternatives or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the draft is not sent, implying non-destructive mutation, but does not disclose authentication needs, rate limits, or what happens with existing drafts. The behavioral profile is under-described for a creation 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 very concise: one sentence stating the core purpose followed by a clean bullet-style list of arguments. Every element earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 optional parameters, no annotations, no schema descriptions), the description covers the purpose, basic usage rule, and explains each parameter. The presence of an output schema further reduces the need to describe return values. It is complete for its context, though usage guidelines could be more thorough.
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 adds meaningful context for all 8 parameters, e.g., 'Recipients (comma-separated)' and 'Space-separated Message-IDs'. This compensates for the schema gap, though additional details (e.g., format validation) could improve.
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 saves a new email as a draft and specifies it is not sent. It uses a specific verb ('save') and resource ('email draft'), immediately distinguishing it from siblings like send_draft or send_email.
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 usage guideline: at least one of 'to', 'subject', or a body field should be provided. However, it does not explicitly contrast with alternatives like edit_draft or send_draft, missing an opportunity to guide when to use this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses the max_body_bytes limit, implying body truncation behavior, but does not explicitly state the tool is read-only or describe what 'all emails' entails (e.g., attachments, metadata). The output schema exists but the description could be more transparent about the operation's safety.
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 highly concise at 6 sentences, front-loading the purpose then listing parameters in a clear Args block. No redundant wording; every sentence serves a 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?
Given 3 parameters (0 required) and no annotations, the description covers the tool's core purpose, identifier options, and a key behavioral constraint (max body bytes). With an output schema present, the description does not need to detail return values. Minor gaps (e.g., error handling) do not significantly hinder usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It clearly defines email_id as an ID whose thread to fetch, thread_id as a direct ID, and max_body_bytes with default 5000. It implies mutual exclusivity of email_id and thread_id ('Provide either'), but does not explicitly forbid providing both. This adds value beyond the schema's types and defaults.
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 gets all emails in a conversation thread, specifying the verb 'Get' and the resource 'emails in a conversation thread'. It distinguishes from siblings like get_emails (which likely fetches emails from a folder) by focusing on thread grouping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on using either email_id or thread_id to specify the thread, but does not explicitly contrast with alternatives like get_emails or query_emails. It lacks when-not-to-use guidance, such as when a thread may be too large or when a simpler email list suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It states what is returned (name, role, parent, email counts) but does not disclose potential performance implications, authentication requirements, or any side effects. As a read-only list operation, no destructive behavior is implied, but more detail could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every sentence adds value. 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?
Given the existence of an output schema, the description sufficiently lists key return fields. It does not mention pagination or sorting, but since there are no parameters for those, it is complete enough for a simple list 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?
There are zero parameters, so the input schema fully covers the lack of inputs. The description does not need to add parameter information. The baseline score of 4 is appropriate.
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 verb 'list', the resource 'mailboxes', and the scope 'in the account'. It distinctly differentiates from sibling tools like create_mailbox, destroy_mailbox, and update_mailbox, and other list tools such as list_identities or list_masked_emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all mailboxes, but does not explicitly state when to use it versus alternatives or provide context such as 'use before moving emails'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It indicates a read operation ('Search... Returns') but does not explicitly state non-destructive nature, authentication needs, rate limits, or pagination behavior. The description is adequate but lacks explicit safety or constraint details beyond the return preview.
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 well-structured with a brief opening sentence followed by an Args list. It is concise but slightly lengthy due to the number of parameters. Every sentence adds value, and the main purpose 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 search tool with 14 optional parameters and an output schema, the description adequately covers the filtering capabilities, including the filter_json override. It explains limits, sorting, and date formats. However, it omits details on what the 'preview' return contains, though the output schema likely covers that. Overall 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 must compensate fully. It provides clear, per-parameter explanations in the Args section, adding meaning beyond the raw schema (which lacks descriptions). Each parameter's purpose, format (e.g., ISO 8601 for dates), and defaults are explained.
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 'Search for emails with structured filters. Returns matching emails with preview.' This effectively communicates a specific verb (search) and resource (emails), and distinguishes it from sibling tools like get_emails or get_recent_emails by emphasizing structured filtering.
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 filtered email search via parameter details, but it does not explicitly state when to use this tool versus alternatives such as get_emails, bulk operations, or get_recent_emails. No exclusion criteria or contextual guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states that the tool does not save, indicating a non-destructive read-only behavior. However, it does not disclose what happens on validation failure (e.g., error response) or any other 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: two sentences totaling 20 words. It is front-loaded with the main action and includes an args section for the parameter. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no nested objects) and the presence of an output schema, the description is fairly complete. It covers purpose, parameter, and main behavior. However, it could mention error handling or validation output format.
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 0% description coverage, so the description must compensate. It explains the single parameter 'content' as 'The Sieve script source to validate,' adding meaning beyond the schema's type-only definition. This is sufficient for a simple parameter.
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 purpose: 'Validate Sieve script syntax without saving.' This uses a specific verb (validate) and resource (Sieve script), and distinguishes it from sibling tools like create_sieve_script or update_sieve_script which perform saving actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to check syntax before saving, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. There is no guidance like 'use before creating a script' or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action (move to Trash) but does not mention whether the operation is reversible, concurrency limits, or success/failure responses.
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?
Extremely concise: two sentences, front-loaded with action and then parameter detail. No superfluous 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?
Adequately covers the tool's purpose and parameter requirements. While an output schema exists, the description does not explain return values, but for a simple deletion tool this is not critical.
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?
Adds significant value beyond the raw schema: specifies 'comma-separated' format and 'max 50' constraint. With 0% schema description coverage, the description fully compensates.
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?
Clearly states it moves multiple emails to Trash. The verb 'Move' and resource 'emails' are specific, and it distinguishes from siblings like delete_email (single) and other bulk operations.
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?
Implied usage for bulk email deletion, but lacks explicit guidance on when to use versus alternatives (e.g., delete_email for single, or bulk_add_labels for labeling). No exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It correctly notes that only metadata is returned, not content. However, it does not disclose permissions, rate limits, or any side effects, which is acceptable for a simple read 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 concise at two sentences, with the key distinction (metadata vs content) front-loaded. Every word adds value, and there is no repetition 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?
Given the tool's simplicity (one parameter, no nested objects, output schema exists), the description covers the essential behavior. It could optionally mention what metadata fields are returned, but the output schema likely handles that.
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 sole parameter 'email_id' is described as 'ID of the email', which adds meaning beyond the schema (which has no description). With only one required parameter and low schema coverage, the description adequately clarifies its purpose.
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 'List attachments' and the resource 'on an email'. It explicitly distinguishes from the sibling tool 'download_attachment' by noting it provides metadata only.
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 tells the agent to use 'download_attachment' for content, giving a clear when-not-to-use. It implies the primary use case is listing metadata, but does not explicitly state prerequisites or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains that max_body_bytes protects LLM context, and notes fetch_body defaults to true. However, it does not mention any other behavioral traits like rate limits or auth requirements.
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 reasonably concise and front-loaded with the purpose. The Args section is clear, but slightly verbose with defaults; could be slightly tighter.
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 that an output schema exists (not shown), the description does not need to explain return values. The parameter explanations are sufficient for a retrieval tool. Minor gap: no mention of error handling or batch size limits.
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 must compensate. It explains all three parameters: email_ids as comma-separated, fetch_body as boolean with default, and max_body_bytes with default and rationale ('protects LLM context'). This adds significant value 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 clearly states 'Get full details for one or more emails by ID', which is a specific verb+resource. It distinguishes from sibling tools like query_emails (search) and get_recent_emails (limited set).
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 fetching specific emails via IDs, and mentions defaults, but does not explicitly state when to use versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description discloses sorting order and parameter defaults. However, it does not mention error handling (e.g., if mailbox doesn't exist) or rate limits. For a read operation, this is fairly transparent but could add more safety details.
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 very concise: one sentence for the main purpose, then a bulleted parameter list. No redundant information. Every sentence is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to explain return values. It covers purpose, sorting, and parameter constraints. For a simple retrieval tool, it is sufficient but could mention potential failure modes or that results are paginated.
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 description adds meaning beyond the input schema by explaining mailbox as 'Mailbox name or role (e.g. 'inbox', 'sent', 'drafts', 'trash', or a custom name)' and limit as 'Max results (1–50, default 25).' This provides concrete constraints and examples, enriching the bare type definitions.
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 'Get the most recent emails in a mailbox (sorted by date, newest first).' It specifies the verb (get), resource (recent emails), and scope (mailbox). This distinguishes it from siblings like query_emails or get_emails which have different filters.
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 fetching recent emails but does not explicitly state when to use this tool vs. alternatives like get_emails or query_emails. No exclusions or alternative conditions are given, which is a gap given many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it lacks details about what the list returns (e.g., all scripts, filtering, pagination, or format). It adds minimal behavioral context beyond the verb '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 sentences long, front-loaded with the purpose, and contains no unnecessary words. Every sentence adds value.
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 no parameters and an existing output schema, the description adequately covers the tool's purpose and usage condition. It is complete enough for a simple list operation, though it could hint at the output structure.
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 no parameters, so the description does not need to explain them. Baseline is 4 for zero-parameter tools, and the description adds no semantic information about parameters.
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 'List Sieve filter scripts' with a brief explanation of what they are (server-side mail routing rules). This effectively distinguishes it from sibling sieve tools like create, get, update, destroy, and validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a prerequisite (requires sieve capability in JMAP session) and offers an alternative path via the Fastmail web UI if the capability is missing. This helps the agent decide when to use the tool and when to defer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the required capability but does not disclose other behavioral aspects such as the response structure (though an output schema exists), rate limits, or side effects. For a read operation, the description is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long: the first states the tool's purpose, and the second adds the required capability. Every word is necessary, and there is no fluff.
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?
Given the tool's simplicity (no parameters, output schema present), the description is complete. It provides the necessary context about what the tool does and the required capability.
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 0 parameters, so baseline is 4. The description adds no parameter information, which is acceptable as no parameters exist.
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 it retrieves the current vacation/out-of-office auto-reply configuration. It uses the verb 'get' and specifies the resource, distinguishing it from its sibling 'set_vacation_response'.
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 includes the required capability (urn:ietf:params:jmap:vacationresponse) as a prerequisite, providing useful context. However, it does not explicitly state when to use this tool versus alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the required scope, which is important, but does not detail other behaviors like authentication, rate limits, or error handling. Given the tool's simplicity, this is adequate but leaves some 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 extremely concise with two sentences: one stating the purpose and one specifying the required scope. Every sentence is essential, and there is no verbose or redundant information.
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?
Given the tool has no parameters, an output schema (presumably documenting return format), and the description covers the resource and scope, it is complete. The description adequately explains what the tool does and its prerequisite.
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 no parameters, so the baseline is 4. The description adds value by explaining that the tool lists 'sending identities (email addresses you can send from)', providing context 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 uses a specific verb 'List' and resource 'sending identities', clearly defining the tool's purpose. It distinguishes from sibling tools like list_mailboxes by specifying 'identities (email addresses you can send from)'.
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 usage guideline by stating the required scope ('requires the urn:ietf:params:jmap:submission scope'). While it does not explicitly mention when not to use it, the simplicity of the tool and distinct sibling tools make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral details about parameter semantics (empty values leave fields unchanged, 'null' moves to top-level). However, it does not mention permissions, side effects, or what happens if both name and parent_id are empty.
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 clear purpose statement followed by structured parameter documentation. No unnecessary 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?
Given the presence of an output schema, the description covers the core operation well. It explains both types of updates and parameter behaviors. Minor missing context includes error handling or prerequisites, but overall adequate.
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 provides clear explanations for all three parameters: mailbox_id, name, and parent_id, including special values like empty and 'null'. This adds significant value 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 clearly states the action ('update a mailbox') and the specific types of updates (rename or move under a different parent). It effectively distinguishes from sibling tools like create_mailbox or destroy_mailbox.
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 you need to rename or move a mailbox) but does not provide explicit guidance on when not to use it or alternatives. For example, it doesn't mention that creating a new mailbox should use create_mailbox.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It identifies the tool as a mutation ('update') and explains parameter effects, but does not reveal potential consequences (e.g., whether state='deleted' is reversible) or required permissions.
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: a single opening sentence stating the purpose followed by a bullet-point-style list of parameters. Every sentence adds value, and the structure is front-loaded and scannable.
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 has 5 parameters (4 optional) and an output schema exists, the description adequately covers parameter semantics and purpose. However, it could be more complete by noting that the masked email must already exist, and by explaining the return value (though output schema may handle that).
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 has zero parameter descriptions (0% coverage). The tool description fully compensates by explaining each parameter's purpose and acceptable values (e.g., state can be 'enabled/disabled/deleted'), adding 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 updates a masked email and lists the specific fields that can be changed (state, description, domain, URL). It distinguishes from sibling tools like create_masked_email and destroy_masked_email by naming the verb 'update' and specifying the resource.
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 implies usage for updating existing masked emails by listing the parameters to modify. However, it lacks explicit guidance on when not to use it (e.g., for creation use create_masked_email) or alternative tools, though siblings are listed separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the destructive nature ('creates a new draft and destroys the old one atomically') and immutability behavior, which is sufficient for understanding 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 concise, front-loaded with purpose, and includes a well-structured argument list. Every sentence adds value without 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?
Given the 7 parameters and no annotations, the description covers parameter behavior well. The output schema exists but is not described, which is acceptable per instructions. The description is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 listing each parameter with explanation, e.g., 'Empty keeps original.' This adds meaning beyond the schema's type/default fields.
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 'Replace a draft with updated content.' and explains the JMAP immutability, distinguishing it from siblings like create_draft (new draft) and send_draft (send existing).
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 explains that empty fields keep original values, guiding usage for partial updates. It doesn't explicitly state when not to use, but the context of 'replace' and sibling names implies usage for updating existing drafts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden for behavioral disclosure. It clearly states that the tool returns only the URL and has no filesystem writes, making it safe for hosted deployments. It does not detail auth requirements or rate limits, but for a read operation this is adequate.
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. It opens with a clear summary, adds a behavioral note, and then lists parameters in a clean 'Args' block. Every sentence adds value without redundancy.
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?
Given the tool's simplicity (3 parameters, 1 required, no nested objects) and the presence of an output schema, the description covers all essential aspects: what the tool does, how to use it, and parameter semantics. It appropriately omits return details since the output schema exists.
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 0% description coverage, so the description must compensate. It defines each parameter: blob_id as 'Blob ID of the attachment (from get_email_attachments)', name as 'Filename for the download', and content_type as 'MIME type for the download.' This adds meaningful context beyond the bare 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 purpose: 'Get a download URL for an email attachment.' It specifies the resource (download URL) and action (get), and notes that it does not write to the filesystem. This distinguishes it from siblings like 'get_email_attachments' which lists attachments.
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 effectively communicates when to use the tool: to obtain a download URL for an attachment. It also clarifies what the tool does not do (does not write to filesystem) and implies dependency on 'get_email_attachments' for the blob_id. However, it does not explicitly list prerequisites or provide guidance on 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.
Behavior4/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 clearly states the tool returns session information, implying no side effects. While it does not explicitly state 'read-only' or 'safe', the description is transparent enough for a low-risk informational 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 two short sentences with no unnecessary words. The first sentence states the core function and outputs; the second provides usage guidance. Every sentence earns its place, making it highly efficient.
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?
Given the tool's simplicity (no parameters, returns session info), the description is complete. It mentions the key output fields (capabilities, account IDs, username, feature availability) and provides a usage reason. The output schema exists to detail structure, so the description doesn't need to repeat that.
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 parameters with 100% description coverage (trivially). The description adds value by explaining what the output contains, which helps the agent understand the tool's purpose even without parameters. The baseline for 0 parameters is 4, and no additional parameter detail 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 clearly states the verb 'Return' and the resource 'JMAP session', listing key outputs (capabilities, account IDs, username, feature availability). It distinguishes itself from all sibling tools, which focus on email/mailbox operations, by being the only session discovery 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 advises using this tool to discover features and scopes available with the API token, giving a clear usage scenario. It does not provide when-not-to-use or compare to alternatives, but the context is sufficient for an agent to treat it as an initial informational step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the compact vs verbose behavior and pagination parameters, but lacks details on authentication needs or error handling, which is acceptable for a read-only list 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 concise and well-structured: a single-sentence purpose followed by a bulleted list of parameters. Every sentence adds value with no redundancy or fluff.
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?
Given the presence of an output schema (not shown), the description appropriately omits return value details. It fully covers pagination, filtering by state, and verbosity toggle, making it self-contained for a 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?
The input schema has 0% description coverage, but the tool description provides detailed explanations for all four parameters (state_filter, limit, offset, verbose), including defaults and allowed values, fully compensating for the schema gap.
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 'List masked (alias) email addresses with pagination,' using a specific verb-resource pair. It distinguishes itself from sibling tools like create_masked_email and update_masked_email by focusing on listing with optional verbosity.
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 explains when to use verbose vs compact output and how to paginate using limit/offset. However, it does not explicitly state when not to use this tool or contrast with potential alternatives (e.g., query_emails for regular emails).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors (immediate sending, draft capability, auto-header building) despite no annotations; lacks details on rate limits or authentication.
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 introductory sentences plus a clean bullet list of arguments; no fluff, every sentence adds value.
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?
Covers all parameters and core behavior; output schema exists so return value is not required in description. Sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds significant meaning to all 6 parameters, explaining their defaults and effects.
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?
Clearly states 'Reply to an email' and mentions automatic header building, effectively distinguishing from sibling tools like send_email and create_draft.
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?
Provides guidance on when to use send=true vs false, but does not explicitly differentiate from editing drafts or other reply-related tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fastmail-mcp MCP server](https://glama.ai/mcp/servers/eduardobrito21/fastmail-mcp/badges/card.svg)](https://glama.ai/mcp/servers/eduardobrito21/fastmail-mcp)

Score Badge

Copy to your README.md:

[![fastmail-mcp MCP server](https://glama.ai/mcp/servers/eduardobrito21/fastmail-mcp/badges/score.svg)](https://glama.ai/mcp/servers/eduardobrito21/fastmail-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/eduardobrito21/fastmail-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server