Fastmail MCP Server

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation3/5
Multiple email retrieval tools (search_emails, get_latest_emails, get_unread_emails, get_mailbox_emails) overlap in functionality, though descriptions explicitly clarify when to use each. Bulk actions also duplicate single-item operations, but most other tools have clear boundaries.
Naming Consistency4/5
Most tools use a consistent verb_noun pattern (get_, list_, create_, update_, delete_, send_, etc.). Minor deviations like 'one_click_unsubscribe' and 'check_function_availability' don't fit the pattern, and 'bulk_email_action' is inconsistent with 'bulk_add_labels'/'bulk_remove_labels'.
Tool Count2/5
47 tools is excessive for a single server, even covering email, calendar, and contacts. The granularity is inflated by many specialized bulk operations and retrieval variants (latest, unread, mailbox, search) that could be consolidated.
Completeness4/5
Email functionality is thorough, with full CRUD, search, drafts, labels, flags, and bulk actions. Calendar and contacts have basic CRUD, but calendar-level management (create/update/delete calendars) and a simple list-all-contacts endpoint are missing. These are workable gaps.
Average 3.9/5 across 47 of 47 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 3 community issues answered or closed in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on June 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 are provided, so the description must carry the full burden of behavioral disclosure. It lists supported actions but omits critical details such as whether delete is soft (trash) or permanent, partial failure handling, rate limits, or authorization requirements. The schema mentions permanent_delete, but the description does not clarify this distinction.
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, two sentences long, and front-loaded with the core purpose ('Perform an action on multiple emails at once'). Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk mutation tool with no annotations and no output schema, this description is underspecified. It lacks usage context, edge-case behavior, response expectations, and clear differentiation from similar sibling tools. The schema covers parameters, but the description still leaves significant gaps for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already thoroughly documents the parameters (emailIds, action, mailboxId). The description adds no extra parameter-level meaning beyond the action types already present in the schema, making the baseline of 3 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 it is a bulk email action tool, enumerating supported operations (mark read/unread, flagging/unflagging, moving, deleting). The phrase 'at once' differentiates it from single-email siblings like move_email or delete_email, giving it a distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for batch operations with 'at once', but it does not explicitly contrast with single-email alternatives or state when not to use this tool. No alternatives are referenced, leaving the usage guidance somewhat implicit.
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 behavioral disclosure. It states 'create' (implying mutation) but does not disclose side effects (e.g., whether the contact is immediately visible, if the operation is reversible, or what happens if the address book ID is invalid). It also doesn't mention required permissions or the return value. This lack of behavioral context for a mutation tool with no annotations warrants a 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point. There is zero wasted text, and it is front-loaded with the core action. It is appropriately sized for a simple create tool, even though it could have added more detail without becoming overly verbose.
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 10 parameters, no output schema, and no annotations. The description does not mention what the tool returns (e.g., the created contact or its ID), nor does it provide any usage context beyond the basic action. While the schema covers parameter details, the lack of return-value information and any caveats leaves the description incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage of all 10 parameters, so the schema already documents each parameter's meaning. The description adds no parameter-level detail, but the baseline for high schema coverage is 3. The schema even notes that addressBookId comes from list_address_books, which is helpful, though that is in the schema, not the tool description.
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 'Create a new contact in the Fastmail address book' uses a specific verb ('create'), a clear resource ('contact'), and a context ('Fastmail address book'). It clearly distinguishes this tool from sibling contact tools like update_contact, delete_contact, and get_contact, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the verb 'create'—if a user wants to create a contact, this is the tool. However, it provides no explicit when-to-use or when-not-to-use guidance, no mention of prerequisites (e.g., needing an address book ID from list_address_books), and no reference to alternatives. This is minimal but not misleading, so it earns a 3.
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 behavioral disclosure. It fails to mention key behaviors such as whether attachments are included, permissions required, side effects on the original email, or return values. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the action and avoids unnecessary words. Every word earns its place.
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 absence of annotations and output schema, and the tool's complexity (4 params, mutation), the description is too minimal. It doesn't address key contextual aspects like attachment handling, sending behavior, or response, making it incomplete for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all four parameters documented. The description adds minimal extra meaning beyond highlighting the optional message, aligning with the baseline score when the schema does the heavy lifting.
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 'forward' and identifies the resource 'existing email' and 'new recipients', clearly distinguishing it from sibling tools like send_email and reply_email. This is a clear and specific 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 when to use the tool (when forwarding an existing email) but does not explicitly contrast it with alternatives or provide exclusion criteria. It lacks explicit guidance on when to choose forward over reply or send.
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 must carry the full burden of behavioral disclosure. It indicates a mutating action but omits details about permission requirements, duplicate name handling, whether the operation is idempotent, or what the return value looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word contributes, with no repetition or filler.
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?
This is a simple two-parameter tool with full schema documentation, but no output schema or annotations. The description does not mention return values, error conditions, or behavioral details beyond creating a mailbox, leaving some gaps for a mutating operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions (name and parentId). The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 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 'Create a new mailbox (folder) in the Fastmail account' with a specific verb and resource. It distinguishes itself from sibling tools like rename_mailbox, delete_mailbox, and list_mailboxes by focusing on the creation 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 usage is implied from the description: use this tool when you need to create a mailbox. However, it does not explicitly mention when not to use it or provide alternatives, and relies on the schema to explain parentId for nested folders.
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 should disclose behavioral traits such as irreversibility, permission requirements, or side effects. The description simply states the action without any additional context about consequences, making it less transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and easy to parse.
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 simplicity of the tool (one parameter, no output schema), the description is minimal but adequately covers the basic operation. However, it does not mention the permanent nature of deletion or any error behavior, which would be useful context for a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the eventId parameter with 100% coverage, so the description adds minimal semantic value beyond restating that deletion is by ID. A baseline of 3 is appropriate when schema covers all 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 uses the specific verb 'Delete' with resource 'calendar event' and specifies the identifier method 'by its ID'. This clearly distinguishes it from sibling tools like create, update, or get calendar events.
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, nor does it provide exclusions or prerequisites. However, the verb and resource make it obvious that it is the tool for deleting an event, which is an implied usage scenario.
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?
There are no annotations, so the description must carry the burden. It only says 'Delete a contact by their ID' and does not disclose permanence, side effects, error behavior, or required permissions. Destructive nature is implied but not explicit.
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, clear sentence with no filler, fully front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits details about return values, error conditions, or irreversible consequences. With no annotations or output schema, this leaves gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's 'by their ID' merely restates the schema's contactId description. Since schema coverage is 100%, baseline is 3; no additional parameter semantics 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 verb 'Delete', the resource 'contact', and the method 'by their ID', which distinguishes it from get/create/update contact siblings.
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, but the action is self-evident and there is no other delete-contact sibling, making usage 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 carries the full burden. It discloses a key behavioral trait (preserving other mailbox assignments) but does not mention idempotency, error handling, or whether removal is permanent. This is adequate for a simple operation but leaves 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 a single, concise sentence that is front-loaded and contains zero fluff. It efficiently conveys the core purpose and a key constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description covers the purpose and a key behavior but does not mention return values or potential error conditions. This is reasonably complete but could benefit from a note about response or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (emailId and mailboxIds), and schema coverage is 100%. The tool description adds no additional parameter-level information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (remove), the resource (mailbox labels from an email), and a specific scope (preserving other mailbox assignments). It distinguishes from add_labels and bulk_remove_labels by focusing on a single email while preserving other assignments.
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 like bulk_remove_labels or move_email. The description states what it does but does not mention exclusions or preferred contexts.
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 burden of behavioral disclosure. It indicates a summary list is returned, but it does not explain search semantics (e.g., case sensitivity, default address book, pagination) or explicitly state that it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences that efficiently convey the tool's purpose and output. Every word contributes to understanding without 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?
The description gives a high-level overview and return type, but without an output schema, it lacks detail on result structure, pagination, and default search scope. The schema covers parameter semantics, but the overall description is minimal for an agent to fully understand invocation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters with descriptions (100% coverage), and the description only restates the 'name/email/criteria' concept without adding operational detail. The baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches contacts by name, email, or other criteria and returns a summary list. It is specific and distinct from sibling tools like get_contact, though it does not explicitly contrast with them.
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 finding contacts by search criteria, but it does not provide explicit guidance on when to use this instead of get_contact or list_address_books, nor does it mention exclusions or prerequisites.
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 carries the full burden of behavioral disclosure. It states the tool composes and sends, implying immediate action, but does not mention consequences like sent-item creation, error handling, rate limits, or whether the email is actually delivered immediately. This is minimal transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the primary purpose. Every sentence earns its place; the prerequisite is concise and actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description covers a key prerequisite (get_identities) and the basic action. However, it omits expected return values, failure modes, or any clarification about whether this sends immediately vs. queued. Given the complexity of email sending and the rich sibling set, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all parameters. The description adds only one piece of param-related context: connecting the identityId parameter to get_identities. This modest addition matches the schema-heavy baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Compose and send a new email' clearly specifies the action and resource, distinguishing it from sibling tools like reply_email, forward_email, create_draft, and send_draft. The phrase 'new email' differentiates it from reply/forward workflows.
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 useful prerequisite ('Use get_identities first') and implies this tool is for composing new emails rather than replying or forwarding. However, it does not explicitly compare with send_draft or other alternate sending tools, leaving some ambiguity that the agent must infer.
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 behavioral disclosure. 'Check' implies a read-only operation, but the description does not explicitly state that it is safe or non-mutating, nor does it describe output format, side effects, or prerequisites. The mention of 'setup guidance' hints at behavior but lacks specifics.
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 sentence, efficient and front-loaded with the main verb and purpose. However, the phrase 'sampling support' is ambiguous and slightly detracts from clarity. Overall, it is concise and well-structured for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and zero params, the description must compensate for missing context. It explains the tool's purpose and mentions setup guidance, but it does not describe what the output will look like or elaborate on 'sampling support.' Given the tool's low complexity, this is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% (vacuously). With 0 params, the baseline is 4, and the description does not need to add parameter-level meaning. The description's reference to 'major Fastmail feature groups' is not a parameter but the tool's subject.
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 a specific verb+resource: 'Check which major Fastmail feature groups are available for this account and MCP client.' It distinguishes from sibling tools, which all operate on specific resources (mail, calendars, contacts), by focusing on availability and setup guidance rather than performing a specific operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you need to know feature availability, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions. The phrase 'including setup guidance for missing...' provides some context but no concrete 'use when' or 'instead of' guidance compared to 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 the full burden of behavioral disclosure. It only states the action and prerequisite, but omits any details about response format, error behavior, idempotency, or side effects. For a state-changing write operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, each earning its place. The first states the purpose, the second gives a critical usage hint. There is zero fluff or redundancy, making it highly efficient.
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?
Despite having 12 parameters and no output schema, the description only covers the basic create action and a prerequisite. It does not explain what the response will look like, timezone handling, or any edge cases. For a complex tool with rich schema, this level of description is insufficient for an agent to fully anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for every parameter, so the baseline is 3. The description adds no parameter-specific information beyond what the schema already provides, but it also doesn't need to since the schema is thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new calendar event,' which uses a specific verb and resource, clearly distinguishing it from sibling tools like update_calendar_event and delete_calendar_event. The purpose is unambiguous and immediately actionable.
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 concrete usage guideline: 'Use list_calendars first to get calendar IDs.' This tells the agent a necessary prerequisite and hints at the workflow. However, it does not explicitly exclude use cases or compare with alternatives, but that is largely implied by the tool's name and purpose.
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 behavioral disclosure. It only states 'List emails' and 'pagination support', but pagination is already evident from the schema parameters. It does not disclose the return format (e.g., which email fields are included), whether the operation is read-only, sorting order, or if it includes email bodies. This leaves the agent with significant uncertainty about the tool's 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 three short sentences with no wasted words. It front-loads the purpose, then gives a usage scenario, and finally a prerequisite. Each sentence earns its place, making it highly concise and well-structured.
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?
With no output schema and no annotations, the description fails to specify what the response contains. It doesn't mention which email fields are returned (e.g., id, subject, sender), whether body content is included, or any other output details. This is a critical gap for an agent that must use the results. The tool is simple, but missing return-value information makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even without parameter info in the description. The description only reinforces using list_mailboxes to find mailboxId, which is already stated in the schema. It adds no extra semantic meaning beyond the schema, so a score of 3 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 uses the specific verb 'List' with the resource 'emails in a specific mailbox', clearly defining the tool's scope. It distinguishes from sibling tools like search_emails (search) and get_email (single email) by focusing on paginated browsing. The mention of pagination further clarifies its purpose.
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 states when to use the tool ('when browsing a folder's contents page by page') and provides a prerequisite ('Use list_mailboxes first to find available mailbox IDs'). However, it does not mention alternative tools like search_emails for non-browsing queries, so it lacks explicit exclusions.
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 behavioral disclosure. It mentions the prerequisite but omits important behavioral traits: what happens to the draft after sending (e.g., removed from Drafts), error conditions, permission requirements, or potential side effects. For a mutating operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word earns its place. It clearly states the action and the key constraint without any 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?
For a simple 2-parameter tool, the description covers the essential precondition. However, with no output schema and no annotations, the return value, error behavior, and post-send effects are left unspecified, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with useful descriptions for both emailId and identityId. The description adds no extra parameter semantics beyond restating the draft context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Send') and resource ('previously saved draft email'), and differentiates from siblings like send_email and reply_email by emphasizing the draft context and the requirement that it exists in the Drafts mailbox. This is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when a draft has already been saved and needs to be sent. It states the prerequisite ('must already exist in the Drafts mailbox') but does not explicitly name alternatives (e.g., use send_email for new messages), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states that the tool retrieves a specific calendar event, implying a read-only operation with no side effects. However, it does not disclose response format, error behavior (e.g., 404 if not found), or any authentication requirements. 'Full details' is vague about what exactly is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key information: what it does (get), what resource (calendar event), and how (by ID). Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool with 100% schema coverage and no complex nested objects, the description is nearly complete. It does not explain return values in detail, but 'full details' gives a reasonable hint. Given the low complexity and no output schema, this is adequate, though a bit more about the response structure would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, with eventId described as 'The calendar event ID to retrieve'. The description adds no additional meaning beyond 'by its ID', so the baseline of 3 is appropriate. No parameter info is missing that would require compensation.
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 ('Get'), the resource ('calendar event'), and the scope ('specific by its ID'). It distinguishes from sibling 'get_calendar_events' which presumably lists multiple events, and from create/update/delete variants.
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 usage is implied: you need full details of a single event given its ID. However, it does not explicitly mention when to use this instead of get_calendar_events or provide any exclusion criteria. No alternatives are named, so guidance is minimal but not misleading.
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 behavioral transparency burden. The verb 'Get' clearly indicates a read operation, and 'full details' hints at the comprehensive nature of the response. However, it does not disclose potential errors, permissions, or the exact return structure, leaving some ambiguity for an agent.
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, front-loaded with the action and resource, and contains no redundant words. It efficiently communicates the purpose without wasting tokens.
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 1-parameter, no-output-schema tool, the description is largely sufficient. It names the resource, the action, and the required ID. However, it lacks any usage guidance or mention of sibling alternatives, which would make it more complete in the broader tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter contactId with the description 'The contact ID to retrieve', achieving 100% schema coverage. The description adds no new semantic detail beyond 'by their ID', so the baseline score of 3 applies as the schema carries the explanatory weight.
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 'Get full details of a specific contact by their ID' clearly states the verb (Get), the resource (contact), and the scope (by ID). It distinguishes itself from sibling tools like search_contacts (searching) and get_identities (different resource), making it unambiguous which action it performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a contact ID and need full details, but it does not explicitly mention when not to use it or point to alternatives like search_contacts. The context is clear but lacks explicit guidance on choosing this over similar 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 provided, the description carries the full burden of behavioral disclosure. It only mentions 'compact' stats, which hints at the output nature, but doesn't discuss whether the operation is read-only, potential rate limits, permission requirements, or error conditions. The description is too brief to adequately inform an AI agent about behavioral expectations.
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 that get directly to the point. It front-loads the action and includes only essential information, with 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?
For a simple tool with one optional parameter and examples of return values, the description is largely complete. The schema handles the parameter details, and the description clarifies the tool's purpose. It could be improved by explicitly stating the behavior when mailboxId is omitted, but that is already in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter, mailboxId, which already includes its description and optionality. The tool description does not add any additional meaning beyond the schema, so the baseline score of 3 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 tool's function: retrieving compact mailbox statistics such as email counts, unread counts, and thread counts. It also distinguishes the tool from listing mailbox contents, which helps differentiate it from sibling tools like get_mailbox_emails.
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 an explicit use case: 'when you need an overview instead of listing mailbox contents.' This implies the alternative of listing contents, but it doesn't name specific sibling tools or state when not to use this tool. The guidance is clear for common scenarios, but lacks explicit alternative naming.
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 disclose behavioral traits. It only states the operation renames an existing mailbox, but does not mention permissions, side effects, or whether renaming affects child folders or references. Minimal behavioral context beyond the core action.
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, front-loaded with the action and object. The second sentence provides a useful pointer to list_mailboxes. No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description gives the essential info: the operation and a way to obtain the required ID. It lacks details on return values or error cases but is adequate for straightforward invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are documented in the schema itself. The description adds no extra parameter-level information, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rename') and resource ('existing mailbox (folder)'), clearly distinguishing it from sibling tools like create_mailbox and delete_mailbox. It also explains the synonymous term 'folder' for clarity.
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 instructs to use list_mailboxes to find the mailbox ID, which is a concrete prerequisite. It does not mention excluded scenarios, but the rename action is unambiguous and the guidance is sufficient.
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 disclose behavioral traits. It states that the tool uses the connected LLM and requires sampling support, which is a notable dependency. However, it does not explicitly confirm that the tool is read-only or describe error behavior if the email is not found or sampling is unsupported.
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 core action and output fields. The second sentence about sampling support is essential context and earns its place. There is no redundant or unclear wording.
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, output content, and a key dependency. Since there is no output schema, it appropriately specifies that the summary includes subject, sender, and body. It could mention the return format or failure handling, but for a one-parameter tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter emailId is fully documented in the schema, including guidance to use search_emails or get_latest_emails to find IDs. The tool description adds no additional parameter semantics beyond what the schema already provides, but the 100% schema coverage makes this adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a concise summary of an email's subject, sender, and body using the connected LLM. This specific verb+resource pairing distinguishes it from sibling retrieval tools like get_email and search_emails, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when a concise summary is desired, but it does not explicitly state when to use it versus alternatives like get_email or suggest_reply. It mentions a prerequisite of MCP client sampling support, but provides no when-not-to-use guidance.
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 important preservation behavior but does not detail error handling, permission requirements, idempotency, or what happens if some email IDs are invalid. This is partial disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and front-loaded. Every word adds value: 'Remove' (verb), 'one or more mailbox labels' (object), 'multiple emails' (scope), 'preserving other assignments' (key behavior). No 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?
The tool has two array parameters fully described by the schema, no output schema, and no annotations. The description explains the operation and a key side effect but omits possible return behavior, failure semantics, or rate limits. It is adequate for simple selection but lacks depth for a bulk mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters (emailIds and mailboxIds), including constraints. The description adds no extra parameter-specific meaning, so it earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' with a clear resource ('mailbox labels from multiple emails at once'). It distinctly covers bulk behavior, differentiating from sibling tools like remove_labels (likely single) and bulk_add_labels (opposite operation).
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 bulk removal ('at once', 'multiple emails') and states a key behavioral context ('preserving any other mailbox assignments'). However, it does not explicitly mention when to choose this over remove_labels or bulk_add_labels, nor does it state any 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?
With no annotations provided, the description carries the full burden. It discloses the key behavior (does not send) and the workflow with send_draft. However, it lacks details about what happens after saving (e.g., return value, draft identifier) or side effects like overwriting behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the main point front-loaded. Every word earns its place, and there is no repetition of schema content. It is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 params, no output schema, no annotations), the description covers the core purpose and relationship to send_draft but leaves gaps: it does not explain what the response contains, how to reference the draft later, or any constraints beyond the schema. This is adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all six parameters. The description adds no parameter-specific information beyond the schema, which gives the baseline score of 3. No additional semantics 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 tool's function: 'Save an email as a draft without sending.' This is a specific verb-resource combination that distinguishes it from send_email and send_draft. The mention of editing or sending later via send_draft further clarifies its role in the workflow.
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 clearly implies when to use this tool: when you want to save a draft rather than send immediately. It also points to send_draft as the alternative for sending later. However, it does not explicitly exclude other scenarios or mention any prerequisites, so it falls short of a perfect score.
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 behavioral disclosure burden. It correctly implies a read-only listing operation, but does not mention any limitations, return format details, or account-specific nuances. Since it is a simple list with no side effects, the minimal description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that wastes no words. It includes the essential information (what is listed and the scope) without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description is the only source for understanding the return value. While 'List all address books' implies a list of address books, it does not specify whether the response includes contact counts, ordering, or other metadata. For a simple tool, this is a minor gap but 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 tool has zero parameters, and schema_description_coverage is 100% by default. The description adds no parameter-specific semantics because none exist, and it implicitly communicates that no filtering is available. Baseline for zero parameters is 4.
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' and the resource 'address books (contact groups)' in the Fastmail account, distinguishing it from sibling tools like list_calendars and list_mailboxes. The parenthetical clarification disambiguates the term 'address books' from other possible meanings.
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 one needs all address books, but it does not explicitly state when to use this tool over alternatives like search_contacts or get_contact. No exclusions or alternative guidance are provided, which is acceptable for such a straightforward list operation.
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 does disclose a key behavioral trait: 'Only specified fields will be changed,' revealing partial-update semantics. However, it does not mention error handling, idempotency, permissions, or what the response contains, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and a concise clarification. Every word earns its place, with no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no annotations, and no output schema, the description provides only the fundamental update behavior and partial-update note. It lacks guidance on return values, error conditions, or prerequisites, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds value by clarifying that unspecified fields remain unchanged, which is not explicitly stated in the schema. This helps an agent understand that optional parameters only override when provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update an existing calendar event.' This clearly distinguishes it from sibling tools like create_calendar_event and delete_calendar_event. The additional clause 'Only specified fields will be changed' further clarifies the partial-update semantics.
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 context is implied by the verb 'Update' and the required eventId, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The guidance is minimal and relies on the tool's name and schema.
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 key behavioral trait (not removing existing assignments) but does not mention other relevant behavior such as idempotency, failure modes, or permission requirements. This is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no filler or redundant information. 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?
For a simple two-parameter tool with a clear schema and no output schema, the description adequately explains the core operation and its key constraint. It could explicitly mention that this applies to a single email (as opposed to bulk), but the schema and tool name make that evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for both parameters. The description adds no additional parameter-level detail beyond what the schema states, so it meets the baseline but does not enhance semantics.
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 ('add') and resource ('mailbox labels to an email'), and clearly states a key differentiator: it does not remove existing mailbox assignments. This distinguishes it from sibling tools like remove_labels and move_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 gives clear context by stating that existing mailbox assignments are preserved, implying when to use this tool (additive labeling). However, it does not explicitly mention alternatives like bulk_add_labels or when not to use it, so it falls short of explicit 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?
With no annotations provided, the description carries the full burden. It clearly states the core behavior (move to Archive mailbox) but does not disclose potential side effects such as whether read flags change, whether emails remain searchable, whether the action is reversible, or what permissions are required. This is typical for a simple mutation but leaves some uncertainty.
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, front-loaded sentences with no filler. Every phrase adds value: the first states the action, the second clarifies the typical use case.
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 single-parameter tool with no output schema and no annotation, the description is nearly complete. It identifies the target mailbox and the scenario for use. It could be slightly more complete by noting whether the archive operation is reversible or whether it affects read state, but the core tool behavior is sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only one parameter (emailIds). The description's phrase 'one or more emails' matches the schema's anyOf string/array definition but adds no new semantic information about the parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource: 'Move one or more emails to the Archive mailbox.' This precisely distinguishes it from sibling tools like move_email (generic move) and delete_email (destructive action). The added phrase 'archiving emails you've dealt with' reinforces the intended use case.
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?
It states a clear context: archive emails that have been dealt with, describing it as a 'convenient one-step operation.' However, it does not explicitly mention when to prefer this over move_email or delete_email, nor does it state any 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?
No annotations are provided, so the description carries the burden of conveying safety. The verb 'Get' suggests a read-only operation, but the description does not explicitly state that it does not modify events or disclose behaviors like default ordering or date inclusivity. It adds the date-range scoping but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that conveys the core purpose and options without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five optional parameters fully documented in the schema and no output schema, the description gives a high-level overview sufficient for an agent to decide to invoke it. It could mention limit/pagination, but the schema already covers parameter specifics, so the description is adequately complete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all five parameters. The description mentions 'calendar ID or search text' but does not add meaning beyond what the schema already provides. Baseline 3 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 tool's function: 'Get calendar events within a date range' with optional filters. The verb 'Get' paired with the resource 'calendar events' is specific and distinguishes it from the sibling tool get_calendar_event, which retrieves a single event.
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 listing events in a range and mentions optional filters, giving clear context. However, it does not explicitly mention when to prefer alternatives like get_calendar_event for a single event, so it stops short of providing 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?
With no annotations, the description carries the transparency burden. It explains that the tool retrieves raw headers and that it can use defaults, which is helpful. However, it does not disclose potential limitations such as whether missing headers are omitted, whether header names are case-sensitive, or what the response format looks like. This is adequate but has 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?
Two sentences, front-loaded with the action and resource, then a valuable default detail. No wasted words, and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema, no annotations). The description covers purpose, key behavior (no body), and defaults. It lacks a note about the response shape or error conditions, but for a lightweight getter this is sufficient. Slightly below a 5 due to these omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The description adds contextual meaning by stating the default header list and reinforcing that headers are selected/raw, which supplements the schema but does not significantly extend it. Baseline of 3 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 'Get', the resource 'selected raw email headers', and the scope 'for a message'. It also distinguishes itself from siblings by explicitly stating 'without returning the full body', which differentiates it from get_email and similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without returning the full body' indicates when to use this tool over alternatives like get_email. It also lists default headers, giving concrete context for typical use. However, it does not explicitly name alternative tools or mention scenarios where one might want to avoid this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List all' communicates a read-only enumeration, but it does not disclose potential caveats such as whether disabled or unverified identities are included, or any rate limits. Minimal behavioral detail beyond the obvious 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?
A single concise sentence with no wasted words. Front-loaded with the verb and resource, and the parenthetical adds essential clarification 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?
For a simple list tool with no parameters, no output schema, and no annotations, the description adequately explains the tool's function. It could potentially mention return format or sorting, but it is not strictly necessary for such a straightforward 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 zero parameters, and the schema provides 100% coverage by having no properties. The description adds semantic clarity by defining identities as email addresses, which is useful beyond the empty schema. Baseline for zero params is 4.
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 'sender identities', and the scope 'all', making it distinct from siblings like list_mailboxes or list_calendars. The parenthetical '(email addresses)' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'available for sending emails' implies the tool is relevant when sending messages, but it does not explicitly contrast with alternatives like list_mailboxes or provide exclusion criteria. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 restates the core action and intended use, without mentioning side effects, read-only nature, or any limitations. The description adds no behavioral context beyond the literal function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, then use-case and exclusion. Every word earns its place 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 tool with two optional parameters and no output schema, the description covers purpose, usage context, and an alternative. It could add detail on what 'recent' means or return format, but it is largely complete given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (limit, mailboxId) are already well-documented. The description adds no parameter-specific semantics; the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the most recent emails sorted by date. It also explicitly contrasts with search_emails, distinguishing it from a key sibling tool.
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?
Provides explicit guidance: 'Best for quickly checking recent activity without specific search criteria' and instructs not to use search_emails for this purpose. This gives clear when-to-use and when-not-to-use direction.
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 adds behavioral context by stating 'chronologically' and 'full discussion', which helps set expectations. However, it doesn't disclose whether full email bodies are included, pagination behavior, or any safety/permission traits. It is a read operation implied by 'get', but more transparency would be better.
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 front-loads the action and object. Every word adds value without redundancy, making it highly concise.
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 output schema), the description provides enough context for basic usage. It clarifies the chronological ordering and thread scope. However, it could be more descriptive about the return format (e.g., whether it includes attachments, bodies, or metadata), but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because threadId has a clear description. The tool description does not add anything beyond the schema's parameter description, so the baseline of 3 applies. No additional parameter meaning is provided by the description.
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 ('get') and resource ('conversation thread') and clearly distinguishes from siblings like get_email (single email) and search_emails (search-based retrieval). It also states the output scope ('all emails' in thread, chronological order), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when needing the entire conversation thread in chronological order. It doesn't explicitly name alternatives or exclusions, but the context is clear enough to differentiate from getting a single email or searching. No misleading guidance.
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 burden of behavioral disclosure. It adds the useful limitation 'Processes up to 500 unread emails at a time', which implies a batch operation and that only unread emails are affected. However, it does not mention idempotency, return value, or potential side effects like rate limiting, leaving 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 three short sentences: one for action, one for use case, and one for the batch limit. Every sentence earns its place with no wasted words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential aspects: what it does, when to use it, and its processing limit. It could optionally mention whether the operation is synchronous or what counts as success, but for a simple mutation tool, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes mailboxId as 'The mailbox ID whose emails should be marked as read (use list_mailboxes to find IDs)', which is clear and self-sufficient. The description text adds no extra parameter semantics beyond what the schema already provides, so baseline 3 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 'Mark' and the resource 'all emails in a specific mailbox' as read, making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like update_email_flags (which likely targets individual emails) by indicating mailbox-wide operation.
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 phrase 'Useful for clearing unread counts on a mailbox' provides a clear use case. It does not explicitly exclude alternatives like update_email_flags, but the mailbox-level scope implicitly separates it from per-email tools, offering adequate guidance.
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 useful context by stating it uses the connected LLM and requires sampling support. But it does not disclose the return format or whether the draft is actually sent/stored, which would be important for an agent to fully understand 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?
Two concise, information-dense sentences with no redundancy. Each sentence serves a purpose: describing the action and stating a critical requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and a key prerequisite, but lacks an explicit statement about the return value or that no side effects occur (e.g., it does not send or save the reply). Without an output schema, this would be helpful, though the simple nature of the tool makes it moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for both parameters (100% coverage), so the description adds little beyond the schema. Baseline 3 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 tool drafts a reply to an email using the connected LLM, with specific verb ('draft') and resource ('reply to an email'). This distinguishes it from siblings like reply_email (sending) and create_draft (generic draft creation).
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?
It conveys clear context: use this tool when you need an LLM-generated reply based on intent, and it notes a prerequisite (MCP client sampling support). However, it does not explicitly mention alternatives or when not to use it, leaving some ambiguity against reply_email or create_draft.
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 usefully clarifies that the tool affects read/unread and flagged/unflagged states, but it does not disclose permissions, reversibility, or response behavior. This is a moderate gap for a mutation tool, but the operation itself is straightforward.
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 verb and clearly scopes the tool. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This simple mutation tool has complete schema coverage and a clear, compact description. The description and schema together provide sufficient context for an agent to select and invoke it correctly. Missing response details are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptive comments, achieving 100% schema description coverage. The description adds no parameter-specific information beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as updating email flags, with a parenthetical that specifies the two flag types (read/unread and flagged/unflagged). This specific verb+resource scoping distinguishes it from sibling tools like move_email or add_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by focusing on 'email flags' and enumerating the exact flag types, implying when this tool should be used. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that deletion is reversible by default (Trash) and that permanent=true causes irreversible destruction. This is key behavioral information beyond what the input schema alone conveys.
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: two sentences, with the main action first, followed by the optional permanent parameter. Every word adds value, and the structure is clean and front-loaded.
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 low complexity (2 parameters, no output schema) and the clear description of default vs permanent behavior, the description is comprehensive. It provides all necessary context for an agent to invoke the tool correctly, including the critical distinction between reversible and irreversible deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (emailId and permanent) with 100% coverage, including the default and the 'cannot be undone' warning. The description restates this information without adding new semantics beyond the schema. Therefore, a baseline score of 3 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 'Delete' and the resource 'email'. It also clarifies the two modes (Trash vs permanent), distinguishing it from sibling tools like archive_email or move_email. The mention of 'permanently destroy' further clarifies the destructive nature when permanent=true.
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 explains the default behavior (moves to Trash) and the permanent option, which provides usage context for the tool itself. However, it does not explicitly compare against alternatives like archive_email or move_email, or state when not to use this tool. The guidance is implied rather than explicit.
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 of behavioral disclosure. It does not mention that this is a read-only operation, whether it searches across all mailboxes or only a specific one, or how results are ordered. While the schema covers parameter behavior, the description lacks these contextual 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?
Three sentences: first states the purpose, second gives usage guidance, third names alternatives. No redundant or filler content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and alternatives but lacks details about result format, default mailbox scope, ordering, or pagination behavior. Given 9 parameters and no output schema, the description could be more complete, though the schema fills in parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description groups filters (sender, recipient, subject, date range, full-text) which maps to parameters, but it does not add meaning beyond the schema's own field descriptions. It offers no extra insight into parameter semantics.
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 searches for emails with specific filters (sender, recipient, subject, date range, full-text query) and distinguishes it from simpler email retrieval tools. The verb 'search' plus resource 'emails' and explicit filter list leave no ambiguity.
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?
It explicitly states when to use this tool ('when you need to find specific emails matching particular criteria') and names two specific alternatives (get_latest_emails, get_unread_emails) with their use cases. This is clear, actionable guidance.
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 carries the full burden. It discloses the empty-required constraint, the force=true override, and the restriction on system mailboxes. It could also mention the permanent nature of deletion or that force moves emails to Trash, but the latter is covered by the force parameter description. The phrase 'delete with all contents' is slightly ambiguous but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and every sentence provides necessary constraints (empty requirement, force behavior, system mailbox exclusion). 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?
For a mailbox deletion tool, the description includes key operational constraints and exceptions. The schema handles parameter details, and there is no output schema to explain. It could mention return values or required permissions, but the description is largely complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (mailboxId and force), and the description only reiterates force=true without adding new parameter semantics. This meets the baseline of 3 for high 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 'Delete a mailbox (folder)' with a specific verb and resource, distinguishing it from sibling tools like delete_email and delete_calendar_event. Clarifying that a mailbox is a folder adds useful context.
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 clear usage conditions: the mailbox must be empty or force=true is required, and system mailboxes are excluded from deletion. However, it does not explicitly name alternative tools (e.g., delete_email) for when the user intends to delete individual emails rather than a whole mailbox.
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 full burden. It discloses the scope of the response (headers, body text, attachment info), which is not specified elsewhere. It does not cover error behavior or side effects, but for a simple 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 a single, well-formed sentence that immediately states the verb and object. It is concise and front-loaded, with 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?
With one parameter and no output schema, the description sufficiently communicates what is returned (headers, body text, attachment info). While it doesn't detail the return structure, it covers the key elements one would expect from a 'get email' operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the emailId parameter with its description. The tool description simply repeats 'by its ID' without adding format details, source guidance, or clarification of where to find the ID. Baseline 3 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 action 'Get the full content of a specific email by its ID' and enumerates what is included (headers, body text, attachment info). This distinguishes it from sibling tools like get_email_headers and get_email_attachments, which retrieve only those subsets.
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 the use case: retrieve the full email content when you have an email ID. However, it does not explicitly mention alternatives or when not to use it (e.g., if you only need headers, use get_email_headers). The context is clear but lacks explicit 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?
With no annotations provided, the description carries the behavioral transparency burden. It adds context about the optional mailbox filter and the use case, but does not disclose other behaviors such as whether the operation is read-only, how results are sorted, or the response format. However, the tool name and nature strongly imply a read-only operation, so this is not a major risk. The description gives some context but lacks depth.
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, concise, and front-loaded. It states the primary action first, then the usage context, then the alternative exclusion. Every sentence earns its place with no repetition or fluff.
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 read tool with two optional parameters, the description covers the core purpose, usage context, and alternatives. It does not describe the return structure, but no output schema exists and the tool's behavior is fairly predictable. It could mention sorting or pagination, but these are not essential for correct invocation. Overall, it is complete enough for an agent to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters (limit and mailboxId) with full descriptions (100% coverage). The description's phrase 'optionally filtered by mailbox' aligns with the mailboxId parameter but adds no new information about limit or parameter syntax. Since the schema does the heavy lifting, a baseline score of 3 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 tool's function: 'Retrieve unread emails, optionally filtered by mailbox.' The verb 'Retrieve' combined with the resource 'unread emails' is specific and unambiguous. It also distinguishes itself from sibling tools by explicitly ruling out search_emails for this purpose, which differentiates it from a likely alternative.
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?
It provides explicit usage guidance: 'Best for checking what needs attention' indicates when to use it, and 'Do not use search_emails for this purpose' explicitly excludes the most likely alternative. This is a clear directive that helps an agent choose this tool over search_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?
With no annotations, the description carries the full burden. It clearly indicates a read-only listing operation and specifies the output semantics (roles, email counts, IDs). It does not mention pagination, ordering, or permission requirements, but these are less critical for a simple list 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 a single, front-loaded sentence with no wasted words. Every phrase adds useful information about scope and return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description is largely complete: it states the resource and the key returned fields. It could optionally mention pagination or whether system mailboxes are included, but these are not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline is 4. The description adds no parameter details because none are needed, but it confirms the account-wide scope of the listing.
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'), identifies the resource ('mailboxes (folders) in the Fastmail account'), and states the returned data (roles, email counts, IDs). It clearly distinguishes this from sibling tools like get_mailbox_emails or create_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 use case is implied: use this tool when you need to enumerate all mailboxes in the account. However, the description does not explicitly mention when not to use it or name alternatives, leaving the guidance somewhat implicit.
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 convey behavioral traits. 'Move' implies a mutating action, but the description does not disclose potential side effects, required permissions, or return value. It is straightforward but minimal, adding little beyond the verb itself.
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. The first sentence states the core action, and the second provides a necessary usage detail. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter action with no output schema, the description gives enough information to invoke the tool correctly: it states the purpose and provides a workflow tip for finding mailbox IDs. It does not mention return values, but that is acceptable given the absence of an output schema and the tool's straightforward nature.
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 already describes both parameters with 100% coverage. The description adds a valuable tip: 'Use list_mailboxes to find mailbox IDs,' which helps the agent understand how to populate the mailboxId parameter correctly. This goes beyond the schema's basic 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: 'Move an email to a different mailbox (folder).' This uses a specific verb and resource, distinguishing it from sibling tools like delete_email or archive_email. The parenthetical '(folder)' adds helpful clarity.
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 direct usage instruction: 'Use list_mailboxes to find mailbox IDs.' This tells the agent a necessary prerequisite step for obtaining the destination mailbox ID. It does not explicitly mention alternatives or exclusions, but the guidance is clear and practical.
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 bears full responsibility for behavioral disclosure. It reveals that the tool only posts to safe HTTPS URLs and only when the List-Unsubscribe-Post header advertises one-click unsubscribe, which is important safety behavior. It does not describe the return value or what happens if conditions are unmet, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and a crucial safety qualifier. Every word earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the action and safety constraints well. However, it does not mention the return value or behavior when the tool cannot perform the unsubscribe (e.g., missing header), which would be useful in the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the only parameter (emailId) with 100% coverage: 'The email ID to unsubscribe from'. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 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 tool unsubscribes from a message using one-click unsubscribe headers, which is a specific verb+resource. It also specifies the scope by mentioning the safety constraint and the List-Unsubscribe-Post condition, distinguishing it from sibling tools like delete_email or archive_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 implies the use case: when you want to unsubscribe from a message via one-click headers. It also provides a clear condition for when the tool will act ('Only posts to safe HTTPS List-Unsubscribe URLs when List-Unsubscribe-Post advertises one-click unsubscribe'), serving as a guideline. It does not explicitly name alternatives, but none exist among the siblings for unsubscribing.
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 carries the transparency burden. It discloses two meaningful auto-behaviors: setting threading headers and determining recipients. However, it does not clarify whether the reply is sent immediately or created as a draft, nor mention response behavior, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose ('Reply to an existing email'), and every clause earns its place by adding behavioral context 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 no output schema and no annotations, the description covers the essential purpose and key automatic behaviors. It could mention return format or note that it sends immediately, but for a reply tool with a straightforward action, the description is sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have schema descriptions, so baseline is 3. The tool description adds no parameter-specific meaning beyond what the schema already states; the mention of auto recipient determination relates to overall behavior rather than clarifying individual params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Reply') and resource ('existing email'), and adds key differentiators ('Automatically sets threading headers... determines recipients'), which clearly distinguishes it from sibling tools like send_email, forward_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?
The description implies usage for replying to existing emails and highlights automatic header/recipient handling, giving context for when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, like the high-bar calibration example.
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 must carry the transparency burden. It clearly discloses the key behavioral trait of partial update ('Only the fields you provide will be updated; other fields remain unchanged'), which is essential for safe invocation. It does not mention permissions or error handling, but the core non-destructive nature is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, front-loaded with the action, and every word adds value. It conveys both the purpose and the crucial partial-update behavior in just two short sentences, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters but no output schema, the description plus the fully documented schema provide enough information for an agent to invoke it correctly. The partial-update semantics are the most important contextual detail and are clearly stated. Minor gaps include no mention of return value or not-found error behavior, but these do not impede correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing full parameter documentation and a baseline of 3. The description adds value by explaining that only provided fields are updated, which clarifies that all optional parameters are patch-style. This semantic context goes beyond simply listing 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 'Update an existing contact's information' with a specific verb and resource, unambiguously distinguishing it from sibling tools like create_contact, get_contact, and delete_contact. The term 'existing' also sets it apart as a modification operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs to modify an existing contact, but it does not explicitly state when to use this tool versus create_contact or get_contact, nor does it provide exclusions or alternatives. The word 'existing' hints at prerequisites but lacks explicit guidance.
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?
In the absence of annotations, the description carries the burden of disclosing side effects. It clearly states that existing mailbox assignments are preserved, which is a key behavioral trait for a mutation tool. It does not cover error handling or reversibility, but the central side effect is communicated.
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 of 17 words. It leads with the action, states the object, and adds a meaningful qualifier without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and the key side effect, but for a bulk mutation tool with no output schema and no annotations, it lacks details about partial failures, atomicity, or return values. The schema documents limits (max 100 emails, max 50 labels), but the description itself is not fully self-contained for the entire operational context.
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 100% schema coverage, the baseline is 3. The description adds value by explicitly stating 'preserving their other mailbox assignments,' which clarifies the semantics of both parameters: emailIds receive additions without removal, and mailboxIds are additive rather than replacement. This goes beyond the schema's terse field 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 adds labels to multiple emails at once, using a specific verb and resource. The phrase 'while preserving their other mailbox assignments' adds crucial scope and distinguishes it from a simple label-replacement tool, as well as from the single-email 'add_labels' sibling.
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 the intended use case for bulk labeling of multiple emails ('at once') and clarifies the additive nature ('preserving'). However, it does not explicitly name alternatives like 'add_labels' for single emails or state when not to use this tool, so it falls short of full guidance.
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 burden of behavioral disclosure. It reveals that the tool returns a compact summary and lists the included metrics, implying a read-only aggregate operation. However, it does not clarify how 'top mailboxes' are determined or whether the summary excludes certain email categories (e.g., deleted items). The behavioral disclosure is adequate but incomplete.
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: the first states purpose and content, the second gives usage guidance. It is front-loaded, concise, and every sentence adds value 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?
Given there are no parameters and the tool is a straightforward summary endpoint, the description covers the essential context: what the summary includes and when to use it. It lacks details on the exact definition of 'top mailboxes' or the return schema, but for this simple tool, it is reasonably 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 tool has zero parameters, so there is nothing to explain. Per the rubric, a baseline of 4 is appropriate when there are no parameters to document.
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 a compact account-level summary' with specific fields ('unique email totals, unread counts, mailbox counts, and top mailboxes'). It distinguishes itself from sibling list tools by emphasizing 'compact' and 'account-level' summary, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Prefer this over large list calls when you only need an overview.' This tells the agent when to use this tool and implies alternatives (large list calls like get_mailbox_emails or get_latest_emails), offering clear decision-making direction.
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 must disclose behavior. It states the operation is a listing operation with the attributes returned, which is transparent. It does not claim any side effects, and 'list' implies a read-only operation. However, it doesn't mention whether authentication is required or if pagination applies, but for a simple zero-parameter list this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads 'List all calendars' and appends the key attributes, making it efficient and well-structured.
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 tool is simple with no parameters and no output schema. The description explains what the tool does and what information is returned (names, colors, visibility status), which is adequate for an agent to select and invoke it. It doesn't specify the exact response format, but that's not critical for a 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?
The tool has zero parameters and the schema has no properties, so the description doesn't need to explain parameters. The mention of names, colors, and visibility status gives a hint about the response shape, which is useful. Baseline for zero parameters is 4.
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 specific verb 'List' with resource 'calendars' and specifies the account scope ('Fastmail account'), along with the returned attributes (names, colors, visibility status). This clearly differentiates it from sibling tools like get_calendar_events, which operate on events rather than calendar metadata.
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 makes the use case clear: it's for retrieving calendar metadata. However, it doesn't explicitly name alternatives or exclusions (e.g., 'use get_calendar_events for events'), so the guidance is implied rather than explicit. Since the tool name and description are unambiguous, the context is clear even without explicit alternatives.
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 carries the burden. It discloses return format (text vs base64), maximum file size (10 MB), and how to obtain the blob ID. This is valuable behavioral info, though it omits error handling and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, no fluff. The most critical info is front-loaded, and 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?
For a simple 2-parameter download tool with no output schema, the description covers purpose, prerequisite, return format, and size limit. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description reinforces that blobId comes from get_email and explains the name parameter as the filename, adding contextual meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Download an email attachment by its blob ID' with a specific verb and resource. It distinguishes itself from sibling tools like get_email_attachments by focusing on downloading a single attachment rather than listing 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?
Provides an explicit prerequisite: 'Use get_email first to find attachment blob IDs.' This gives clear usage context. It does not explicitly mention alternatives or when not to use, but the guidance is sufficient for typical use.
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 carries the burden. It discloses that it avoids returning the full email body and lists the specific attachment fields returned, which is helpful behavioral context. However, it doesn't explicitly state it's a read-only/no-side-effect operation, though that is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no wasted words. The purpose and usage guidance are packed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description adequately states what it returns (filenames, types, sizes, blob IDs) and when to use it. No exclusions or prerequisites are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter (emailId) is clearly described in the schema as 'The email ID whose attachments should be listed.' The description adds no extra parameter semantics, but the baseline of 3 applies since the schema fully handles it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list attachments) and the specific resource (a specific email), and distinguishes it from sibling tools like download_attachment and get_email by noting it avoids the full email body.
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?
Explicitly says when to use this tool ('when you only need filenames, types, sizes, and blob IDs') and names the alternative (download_attachment), giving clear context for tool selection.
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-server MCP server](https://glama.ai/mcp/servers/Jordonh18/fastmail-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Jordonh18/fastmail-mcp-server)

Score Badge

Copy to your README.md:

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

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/Jordonh18/fastmail-mcp-server'

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