mailpouch

by chandshy

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v3.2.0
Disambiguation5/5
Each tool serves a clearly distinct purpose, with well-defined differences between single and bulk operations, folder vs label moves, and explicit convenience wrappers. Overlaps like move_email and its convenience variants are documented as such, so agents can confidently select the right tool.
Naming Consistency5/5
All tool names use a consistent verb_noun pattern in snake_case, with modifiers like 'bulk_' or 'check_' for clarity. Even convenience wrappers follow the pattern (e.g., move_to_trash, archive_email). No mixing of conventions or ambiguous verbs.
Tool Count2/5
With 66 tools, the count is well above the recommended range for a coherent set. While many tools are justifiable for the domain, the proliferation of convenience wrappers (e.g., archive_email, move_to_trash) and separate bulk variants bloats the surface unnecessarily, making it harder for agents to navigate.
Completeness4/5
The tool set covers the full email lifecycle: CRUD, labels, folders, search, scheduling, reminders, contacts, analytics, and server management. Minor gaps exist, such as the absence of a single-email permanent deletion (only bulk empty_trash) and no tool for managing filters or rules, but these are reasonable omissions for a personal email server.
Average 4.3/5 across 66 of 66 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 4 community issues answered or closed in the last 6 months
- 68 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims to 'Clear the local FTS5 index' which is destructive, but annotations set destructiveHint=false. This is a direct contradiction. Annotations and description are inconsistent, misleading the agent about 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?
Three sentences, front-loaded with action and resource, no redundant information. Each sentence adds value: purpose, usage guidance, output.
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 simple input (one optional param), output schema exists (implied return value), and description covers purpose, usage, and result. No gaps for this tool's 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 coverage is 100% with one optional parameter (account_id) already well-described in schema. Description does not add new parameter meaning beyond what schema provides, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Clear and rebuild' and identifies resource 'local FTS5 index' with scope 'from messages cached (INBOX + Sent)', clearly distinguishing from siblings like fts_search and fts_status.
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?
Description explicitly states when to use: 'after major mailbox changes or when fts_search returns stale results'. Does not mention alternatives or when not to use, but context is clear for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnlyHint, idempotentHint, destructiveHint), so the description must convey behavioral traits. It states 'Move an email' implying mutation, but does not disclose side effects like whether the original copy is deleted, whether the operation is reversible, or permission requirements. The detailed sourceFolder parameter description is in schema but not in main description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the core purpose and differentiate from a sibling. Every word contributes, no 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?
Given the complexity of a move operation (especially with IMAP UID scoping and silent no-ops) and the presence of a detailed sourceFolder parameter, the description could be more complete. It does not mention important behaviors like what happens if the target folder doesn't exist, or strongly recommend providing sourceFolder. The existence of an output schema (not shown) mitigates but doesn't fully compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters have descriptions). The main description adds no parameter-level information beyond what's in the schema. It mentions 'Folders/' prefix but that is already implied by the folder parameter description. The emailId parameter lacks a description in the schema, and the main description does not address 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 'Move an email to a custom folder' and specifies the path format 'Folders/<name>'. It distinguishes from sibling tool 'move_to_label' by noting similarity but different target type, helping the agent choose.
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 some context by comparing to move_to_label, but lacks explicit guidance on when to use this tool versus other move-related siblings like archive_email, move_to_spam, or bulk_move_emails. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'toggle' but annotations indicate idempotentHint=true, creating a contradiction: toggling implies non-idempotent flip while setting a boolean is idempotent. This misleads about actual behavior. Beyond that, no side effects or permissions are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the action, the second adds critical usage detail. Perfectly 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?
For a simple mutation tool, the description covers the main behavior and a key usage note. However, the toggle ambiguity and lack of mention about return value or required permissions (though output schema exists) leave some 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 description adds value by stating the default for isStarred and the strong recommendation for sourceFolder. Although emailId is not described, the schema coverage is 50% and the description compensates with practical context.
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 'Toggle the starred (flagged) status of an email' which is a specific verb-resource pair. It distinguishes from siblings like bulk_star by focusing on single email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific guideline about passing sourceFolder when the UID came from a folder other than INBOX. However, it does not explicitly tell when to use this tool over alternatives like bulk_star or mark_email_read, leaving usage context 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?
Annotations already declare readOnlyHint=true, so the description adds only the sorting behavior (by fireAt). No additional behavioral traits like permissions or side effects are disclosed, which is acceptable given the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single line that perfectly front-loads the purpose and sorting detail. 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?
Tool is simple with one optional param and an output schema exists (not shown), so description doesn't need to detail return format. The description covers the essential purpose and sorting, but a note about the parameter could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-described optional account_id parameter. The description adds no further meaning beyond the schema, so 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?
Description clearly states the tool lists pending no-reply reminders sorted by earliest fireAt. The verb 'List' and resource 'pending reminders' are specific, and the sorting detail distinguishes it from other reminder-related tools like cancel_reminder or check_reminders.
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 wants to see pending no-reply reminders, but offers no explicit guidance on when to use this tool versus siblings like check_reminders or cancel_reminder. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not contradictory and indicate a non-read-only, non-destructive operation. The description adds behavioral insights: the 'confirmed' requirement for Trash/Spam, the folder-scoping of IMAP UIDs, and warnings about 'All Mail' and no-op moves. This context is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences but front-loaded with the core action. It efficiently covers key points without redundancy. Could be slightly more structured, but overall lean and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, output schema present), the description covers essential use cases, parameter dependencies, and common pitfalls. It does not explain return values or error conditions, but the output schema presumably handles that. Adequately complete for the 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?
Schema description coverage is high (80%), so the baseline is 3. The description adds value by explaining the 'confirmed' requirement in context and elaborating on 'sourceFolder' with IMAP UID scoping and the 'All Mail' pitfall. It goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move an email to a different folder' with specific verb and resource. It lists common targets, making the purpose obvious. However, it does not explicitly differentiate from sibling tools like 'move_to_folder' or 'move_to_trash', which could cause ambiguity.
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 clear conditions for using 'confirmed' and 'sourceFolder' parameters, but lacks explicit guidance on when to choose this tool over specialized siblings like 'move_to_spam' or 'move_to_trash'. The usage context is implied through examples but not fully detailed.
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?
Annotations indicate the tool is mutating and not idempotent. The description adds context about SMTP transport, supported email fields, and that it returns a messageId on success. It does not cover rate limits or delivery behavior, but the added details are sufficient for basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and concisely lists supported features. Every part adds value, 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 10 parameters and an existing output schema, the description covers the main purpose and supported options. It lacks details on error handling, sender identity, or immediate sending behavior, but is still fairly complete for a standard email send 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 coverage is 100%, so parameters are already documented. The description reinforces that addresses are comma-separated and attachments are base64-encoded, adding slight extra meaning. However, it does not substantially improve understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send an email via Proton Mail SMTP') and specifies the resource (email). It lists supported features like To/CC/BCC, HTML, priority, and attachments, distinguishing it from sibling tools like forward_email or reply_to_email which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives such as forward_email, reply_to_email, schedule_email, or save_draft. It only describes functionality, leaving the agent to infer usage without explicit decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly (writes), idempotent, and non-destructive. The description adds value by disclosing that 'silently returns false if the ID is unknown or the reminder already fired', which reveals edge-case behavior not captured in annotations.
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 efficient sentences front-load the action and add critical behavioral nuance. No redundancy or unnecessary words. Every sentence 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?
For a simple tool with two parameters and an output schema, the description captures the essential behavior and failure cases. It could mention the return type (likely boolean) but is otherwise complete given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (account_id has description, reminder_id lacks one). The description does not elaborate on either parameter beyond mentioning the ID in the action. It fails to compensate for the missing schema documentation, leaving the reminder_id parameter semantically underdefined.
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 'Cancel' and the resource 'pending no-reply reminder by ID', specifying both the action and the target. This distinguishes it from sibling tools like 'check_reminders' or 'list_pending_reminders'.
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 canceling a specific reminder by ID, but does not explicitly state when to use or not use this tool compared to alternatives. No exclusions or prerequisites are mentioned, but the context is clear enough for its simple purpose.
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?
Annotations indicate readOnlyHint=true. The description adds the important behavioral detail that the tool returns { available: false } when better-sqlite3 is not installed, which is beyond what annotations provide.
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 concise, front-loaded sentences with no wasted words. Every sentence adds value: the first states output, the second handles an edge case.
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 read-only status tool, the description is complete. It specifies exactly what is reported, handles the missing dependency case, and the output schema (exists) can detail the return format. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single optional parameter (account_id) with a full description. The description adds no additional parameter information, so it meets the baseline 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 the tool reports path, row count, and on-disk size of the local FTS5 index. The verb 'Report' and specific resource 'FTS5 index' distinguish it from sibling tools like fts_rebuild or fts_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Sibling tools exist (e.g., fts_rebuild, fts_search) but no context is given for when to prefer fts_status.
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?
Annotations declare readOnlyHint=true, and the description adds that sensitive fields are redacted, disclosing a behavioral trait beyond what annotations provide. No contradictions.
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, efficient sentence that front-loads the core purpose. No extraneous words.
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?
All three parameters are documented in the schema, an output schema exists, and the description covers the key behavioral aspect (redaction). For a simple read tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond what the schema already provides. It mentions filtering by level but doesn't elaborate further.
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 ('Retrieve'), the resource ('server log entries'), and key details (filtering by level, redaction). It is distinct from sibling tools which operate on emails, aliases, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when not to use it or provide context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (all false), so the description carries the burden. It discloses that the tool sends an email and returns a messageId, but does not elaborate on side effects (e.g., actual delivery, rate limits). This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the core purpose and usage guidance. While concise, it could be slightly more streamlined, but there is no waste.
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 and the presence of an output schema, the description covers the main points: purpose, return value, and usage context. It is sufficiently complete for an agent to understand when and how to 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 coverage is 100%, meaning the input schema already describes all parameters fully. The description adds no additional parameter semantics beyond what the schema provides, earning 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 clearly states the tool's purpose: to send a test email for verifying SMTP functionality. It mentions the return value (messageId) and distinguishes itself from the sibling send_email tool by advising to use it as a prerequisite.
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 recommends using this tool 'before relying on send_email in automated workflows,' providing clear context for when to use it. It does not include explicit when-not-to-use guidance, but the context strongly implies it is for testing only.
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?
Annotations show readOnlyHint=false, idempotentHint=false, destructiveHint=false. Description adds context by disclosing the transition to 'fired' status and that reminders won't appear in subsequent calls, which is consistent. Provides behavioral context beyond annotations without contradiction.
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, highly concise and front-loaded with core action. Every sentence adds value: action, side effect, and follow-up guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description adequately covers purpose, side effects, and next steps. It could mention that the tool returns the reminders, but the output schema likely handles that. Overall, complete for a tool with few parameters and no nested objects.
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% for the only parameter (account_id) with a clear description. Tool description does not add further information about the parameter, so 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?
Description clearly states verb 'return' and resource 'pending reminders whose deadline has passed'. It distinguishes from siblings like 'list_pending_reminders' by explaining the transition to 'fired' status, making it specific 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for checking overdue reminders and suggests follow-up action (search inbox), but does not explicitly state when to use this tool versus alternatives like 'list_pending_reminders' or 'cancel_reminder'. Lacks exclusions or comparative 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?
Beyond the destructiveHint annotation, the description adds valuable behavioral constraints: folders must be empty, system folders are protected, and a confirmation parameter is required. No contradiction with annotations.
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 purpose, each sentence adds essential information with no redundancy or waste.
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 action, preconditions (empty, not protected), and requirement (confirmed). With an output schema present, return values are not needed. Minor omission: what happens if preconditions fail, but likely implied.
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 baseline 3. The description mentions the confirmed requirement but essentially restates the schema description. No additional meaning is added for folderName or account_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the target resource ('empty folder or label'), and distinguishes from siblings by specifying the 'empty' condition and listing protected system folders that cannot be deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the confirmation requirement and protected folders, but does not explicitly guide when to use this tool versus alternatives like move_to_trash or empty_trash, leaving the agent to infer.
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?
Annotations already declare readOnlyHint=true, and the description adds value by disclosing that the tool returns null when no ICS block is found and supports RFC 5545 line folding and specific VEVENT properties. No contradiction.
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), front-loaded with the core action, and every sentence adds meaningful information. No 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?
Given the presence of an output schema (inferred from description), the description adequately covers input and behavior. It mentions supported properties and return format for missing ICS. Minor gap: does not mention possible errors or limitations (e.g., unsupported properties).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The tool description does not add significant meaning beyond what the schema provides; it focuses on the tool's overall behavior rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: parse an ICS file or inline VCALENDAR from an email and return structured meeting details. It specifies the return value when no ICS is found, distinguishing it clearly from sibling extraction tools like extract_action_items.
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 context by naming the input (email with ICS), but does not explicitly provide when-to-use or when-not-to-use guidance relative to sibling tools (e.g., extract_action_items). No exclusions or alternatives are mentioned.
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?
The annotations already declare readOnlyHint=true, and the description adds valuable behavioral context by specifying that it includes 'in-flight and outcome-unknown deliveries' and that results are sorted by 'scheduledAt ascending'. No contradictions.
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: the first states the action and scope, the second adds sorting. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and no additional parameters, the description covers the tool's functionality well. It could mention pagination or limits, but for a simple listing tool it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter, with a detailed description. The tool description does not add extra parameter information, so it falls back to baseline 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 clearly states the verb 'List', the resource 'scheduled emails', and specifies the scope 'including in-flight and outcome-unknown deliveries'. It also adds sorting order, making the purpose unambiguous and distinct from sibling tools like 'cancel_scheduled_email'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing scheduled emails but does not explicitly state when to use this tool versus alternatives like 'cancel_scheduled_email' or when not to use it. No prerequisites or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the tool sets/clears the IMAP 'replied to' marker, which aligns with annotations (readOnlyHint=false, destructiveHint=false). It does not disclose additional behavioral traits beyond what annotations provide, such as permissions or error conditions. Annotations already indicate idempotent and non-destructive, so the description adds minimal extra 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?
The description is two sentences long, front-loaded with the core purpose, and contains no unnecessary words. Every sentence adds value: the first states the action, the second covers parameter defaults and usage guidance.
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 medium complexity (4 parameters, 1 required) and the presence of an output schema, the description covers the main behavior and a key usage note. It lacks details on return values or error cases, but the output schema may handle that. It is adequate for a simple mutation 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 50%. The description explains 'answered' (defaults to true) and 'sourceFolder' (when to pass), adding value beyond the schema. The 'emailId' and 'account_id' parameters are not explained in the description, but 'account_id' has a schema description. Overall, the description compensates partially for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to set or clear the 'Answered' flag (IMAP 'replied to' marker) on an email. It is a specific verb-resource combination that distinguishes it from sibling tools like mark_email_read or mark_forwarded.
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 context for usage, such as the default value for 'answered' (true) and when to pass 'sourceFolder' (when UID came from a folder other than INBOX). It does not explicitly state when not to use the tool or mention alternatives, but the guidance is sufficient for correct invocation.
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?
Annotations indicate non-read-only, non-idempotent, non-destructive behavior. The description adds the constraint that protected system folders cannot be renamed, which is a behavioral limit. However, it does not detail side effects (e.g., impact on subfolders or email paths) beyond what annotations convey.
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 primary purpose. No superfluous information; every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (return values are documented), the description adequately covers the tool's role, constraints (system folders), and parameter count. It could mention folder existence prerequisites or error states, but it is reasonably complete for a rename 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 describes all 3 parameters with 100% coverage. The description adds no additional meaning beyond the schema—it does not explain expected formats, validation rules, or relationships between parameters. Baseline 3 is appropriate given 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 the tool renames custom folders or labels, with a specific verb ('rename') and resource ('custom folder or label'). It distinguishes from siblings like create_folder, delete_folder by specifying the action. The note about protected system folders adds 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?
While not explicitly naming alternatives, the description implies use when renaming custom folders/labels and not for system folders. It provides context by differentiating from other folder operations (create, delete, move) among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate no destructive behavior (destructiveHint=false), and the description adds context about pre-filling fields. However, it does not disclose potential side effects like marking the original email as replied or any permissions needed. With annotations covering basic safety, the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose and immediately provide actionable guidance on replyAll. Every sentence serves a clear purpose with no waste.
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 an output schema present, the description need not explain return values. It covers the core action and the primary variation (replyAll). It lacks details on error handling, prerequisites (e.g., email must exist), or behavior of isHtml, but these are minor gaps for a mutation tool with 6 parameters.
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 83%, so the schema already documents most parameters well. The description only adds meaning for the 'replyAll' parameter by explaining its usage. Other parameters like 'folder' and 'account_id' are not elaborated, but baseline 3 is appropriate given 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 the tool sends a reply to an existing email, specifies that it fetches the original to pre-fill fields, and distinguishes between reply and replyAll. This differentiates it from siblings like 'send_email' and 'forward_email'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using replyAll for including original CC recipients, implying the default is to reply only to the sender. It lacks explicit when-not-to-use scenarios or alternatives like 'forward_email', but the context is clear enough.
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?
Annotations indicate a non-idempotent write that is not destructive. The description confirms it saves to Drafts and does not send. No additional side effects (e.g., overwriting) are disclosed, but no contradictions exist.
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 cover purpose, field optionality, and return value without extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 optional parameters and an output schema (not shown here but referenced), the description highlights key aspects: save to Drafts, all fields optional, returns UID. This is sufficient for a draft-saving 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 90%, so the schema already documents parameters well. The description adds 'All fields are optional' but little else beyond what is in 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 'Save an email as a draft in the Drafts folder without sending it,' specifying the action (save) and resource (email draft). This distinguishes it from sibling tools like send_email or reply_to_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for composing drafts without sending, but does not explicitly compare to alternatives like send_email. However, the tool name and context make the use case clear.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description confirms the read-only polling behavior and adds the statuses checked. No contradiction; it adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, action-oriented sentences. No redundant phrases. Front-loaded with the core purpose.
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?
The description covers the tool's purpose and usage pattern. The output schema exists, so explaining return values is unnecessary. Completeness is high for this simple polling 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 coverage is 100% and the schema describes both parameters adequately. The description does not add further parameter details, 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 uses a specific verb ('Check') and resource ('escalation status'), and mentions three possible outcomes (approved, denied, expired), which clearly distinguishes it from sibling tools like request_permission_escalation.
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 poll after calling request_permission_escalation, providing clear usage context. It does not list exclusions or alternatives, but the polling nature is self-explanatory.
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?
Annotations already indicate it is not readOnly, not idempotent, not destructive. The description adds value by detailing that original headers are preserved and forwarded content is quoted, and optionally a message can be prepended. This provides useful behavioral context beyond annotations.
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 that front-load the primary action and key behaviors. No redundant or unnecessary words.
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 high schema coverage, annotations, and presence of an output schema, the description sufficiently explains the forward action behavior including quoting and optional message. No obvious gaps for this type of 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 baseline is 3. The description does not add new meaning to parameters beyond what the schema provides; it only mentions the optional message prepending which aligns with the 'message' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forwards an email to a new recipient, with specific details about original message inclusion and header preservation. This distinguishes it from sibling tools like reply_to_email or send_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for forwarding but does not explicitly mention when to use or avoid this tool compared to alternatives like reply_to_email, send_email, or move_to_trash. No exclusions or alternative tool references.
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?
Annotations already declare readOnlyHint=true, so the agent knows it is a safe read operation. The description adds that it returns the version, but does not disclose any additional behavioral traits such as whether the optional account_id affects the result, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Every word is functional. Front-loaded with the core action, followed by usage guidance.
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 version-check tool with one optional parameter and an existing output schema (as indicated by context), the description is complete. It covers purpose and usage without needing elaboration.
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% for the single parameter, so the schema already documents account_id sufficiently. The tool description does not add any extra meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and resource 'server version', clearly distinguishing it from all sibling tools which handle aliases, emails, folders, etc. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States to use 'to confirm which version is active before reporting bugs or checking for new features.' This provides explicit usage context. It does not mention when not to use it, but the tool is so focused that exclusion is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by disclosing that labels are lost when moving an email, which is critical behavioral information. Annotations only indicate non-readonly and non-destructive, but the description adds the side effect of label loss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences to convey purpose, relationship to move_email, and a critical side effect. It is front-loaded and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations are present, the description adequately covers the essential behavioral detail (label loss). However, it could mention edge cases like what happens if the email is already archived.
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 67% coverage with descriptions for account_id and sourceFolder, but the tool description does not add any extra meaning or usage guidance for the parameters 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 clearly states the tool moves an email to the Archive folder and explicitly distinguishes it as a convenience wrapper for move_email targeting Archive, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is a convenience wrapper for move_email but does not provide explicit guidance on when to use this tool versus alternatives like move_to_folder or move_to_spam. No when-not advice is given.
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?
Annotations already declare readOnlyHint and openWorldHint, so safety profile is clear. Description adds context about data included (counts, organization) but doesn't disclose any additional behavioral traits like rate limits or caching. Adequate but not enriched beyond annotations.
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, each essential and well-placed. First defines functionality, second provides usage guidance. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero required params, presence of output schema, and clear purpose/guidance, the description is largely complete. Lacks mention of pagination or handling of empty results, but still sufficient for typical 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 coverage is 100% with descriptions for all 3 parameters. Description adds minimal parameter-specific value beyond reinforcing the notion of 'ranked' list and recency weighting. Baseline 3 is appropriate as schema already carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Extract' and resource 'ranked contact list' with specific data points. Explicitly distinguishes from sibling tool get_correspondence_profile, making 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?
Provides explicit guidance: use this to choose recipients; use get_correspondence_profile for in-depth profile. Clearly states when and when not to use, with an alternative named.
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?
Annotations declare readOnlyHint=true. The description adds behavioral details: normalized Subject stripping, collection from INBOX+Sent, and folder restrictions for restricted agents. This adds valuable context beyond annotations.
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, front-loaded with purpose, then method, then use case. Every sentence provides 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?
Covers purpose, method, and restrictions. With an output schema present, return values need not be explained. Lacks discussion of edge cases like thread size limits or ordering, but sufficient for typical 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?
All four parameters have schema descriptions (100% coverage), so the description adds little extra parameter meaning. It mentions folder restrictions but does not elaborate on parameter details 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 explicitly states it returns all messages belonging to the same thread, using normalized Subject to collect from INBOX+Sent. This clearly distinguishes it from sibling tools like search_emails or get_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 indicates it's useful for summarizing long conversations, providing clear context for when to use it. However, it does not explicitly state when not to use it or compare to 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the context that it reads the 'All Scheduled' IMAP folder exposed by Proton Bridge, which is consistent with a read-only operation and provides operational detail beyond annotations.
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, both necessary: first states purpose and exclusions, second states data source. No redundancy, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers purpose, data source, and sibling differentiation. It could mention any default ordering or limit, but for a simple list tool with one optional parameter, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (account_id) is fully described in the input schema with 100% coverage. The description does not add any additional meaning beyond what the schema provides, meeting the baseline expectation.
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 specifies the resource as 'emails natively scheduled via Proton Mail web/mobile app'. It explicitly distinguishes from 'MCP-scheduled emails', referencing the sibling tool list_scheduled_emails. The specific IMAP folder source is also mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear contrast between native scheduled emails and MCP-scheduled emails, guiding the agent to choose this tool versus list_scheduled_emails. However, it does not explicitly state 'when to use' or 'when not to use' beyond that distinction.
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?
Annotations already indicate it's a write operation that is idempotent and non-destructive. Description adds value by disclosing the default for isRead and the critical behavior about IMAP UID folder-scoping and silent no-ops. No mention of rate limits or auth, but annotations cover the core safety profile.
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 succinct sentences with no wasted words. Front-loaded with the core action and immediately followed by key usage hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean toggle, the description covers the essential behavioral nuance (source folder). Annotations confirm safety. Output schema exists. Could mention that it operates on a single email, but that is implicit from the singular emailId parameter.
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 descriptions exist for account_id and sourceFolder, but isRead and emailId lack schema descriptions. Description adds the default for isRead and reiterates the importance of sourceFolder. With 50% schema coverage, the description partially compensates but could provide more detail on emailId format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets the read/unread status of an email, which is a specific verb and resource. It differentiates from siblings like bulk_mark_read (for bulk) and star_email (for starring).
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?
Description explicitly advises when to pass sourceFolder to avoid silent no-ops, but does not provide guidance on when to use this tool versus alternatives like bulk_mark_read or star_email. The instruction is helpful but not comprehensive.
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?
The description reveals additive behavior (email remains in original folder, multiple labels possible) beyond what annotations provide. Annotations indicate non-destructive but no further details; the description adds useful context about the operation's effect.
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, using three sentences to convey purpose, behavior, and usage guidance. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description covers the core functionality and key usage advice. It lacks mention of permissions or error cases but is sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents most parameters well. The tool description does not add additional parameter-level information beyond what is in the schema, thus it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a label to an email') and distinguishes from the sibling tool move_email by specifying when to use each. This provides a specific verb and resource, 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 explicitly contrasts with move_email, clarifying when to use this tool instead. However, it does not address other sibling tools like remove_label or bulk_move_to_label, leaving some potential confusion unaddressed.
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?
Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) indicate mutation but no idempotency or destruction. Description adds valuable retry behavior: definite failures retried up to 3 times, ambiguous deliveries never retried. This goes beyond the annotations, though it does not cover potential side effects like rate limits or credit consumption.
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 with no wasted words. The key constraints and retry policy are front-loaded, and the reference to sibling tools is efficient. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters (4 required) and an existing output schema, the description covers scheduling constraints, retry behavior, and related tools. It does not describe the output format or errors, but that is acceptable since an output schema is present. Slight gap: missing note that the email might be sent from a specific account, but the 'account_id' parameter is documented 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 82%, so most parameters have descriptions in the schema. The tool description does not add new parameter-level information beyond what the schema provides. The 'account_id' parameter is mentioned in the schema as well; the description doesn't elaborate further. 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?
Description clearly states 'Schedule an email for future delivery' with explicit time constraints (min 60 seconds, max 30 days). It distinguishes itself from siblings like 'list_scheduled_emails' and 'cancel_scheduled_email' by mentioning them as related tools, and implies differentiation from 'send_email' by focusing on scheduling.
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 clear context for when to use the tool (scheduling future emails) and mentions related tools for viewing and canceling schedules. However, it does not explicitly state to use 'send_email' for immediate delivery, which would strengthen 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?
Annotations declare idempotentHint=true and destructiveHint=false. Description adds that cancel returns false if ID not found or email sent, clarifying safety and idempotency. Provides enough behavioral context beyond annotations.
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: first defines action and target, second explains return behavior. No unnecessary words. Perfectly concise.
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 cancellation tool with clear annotations and a well-documented schema, the description is complete. It explains what happens under different conditions (ID found/sent or not) and implies the prerequisite steps (having scheduled an email). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with clear explanations for both parameters. The tool description does not add further information, but the schema already does the job. Baseline score 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?
Clearly states the tool cancels a pending scheduled email. The verb 'cancel' and resource 'pending scheduled email' are specific and distinct from sibling tools like schedule_email and list_scheduled_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?
Implies usage when an email has been scheduled but not yet sent. Mentions return false conditions for missing or already-sent emails. The id parameter description further guides obtaining IDs from schedule_email or list_scheduled_emails. Lacks explicit 'do not use if already sent' but is clear enough.
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?
Annotations already mark readOnlyHint and openWorldHint. Description adds behavioral details: id vs messageId distinction, pagination via cursor, summaryOnly effect, and folder path examples. No contradictions.
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, each serving a purpose: main function, field clarification, pagination and options. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Handles all 5 parameters, pagination, folder paths, account routing, and summaryOnly. Output schema exists, so return format is already covered. Comprehensive for a paginated list 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 coverage is 100%, baseline is 3. Description adds minor value for summaryOnly (leaner payload) and cursor (from previous response), but most parameter meanings are clear from 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?
Description clearly states 'Fetch a page of emails from a folder' with specific verb and resource. It details returned fields and distinguishes from get_email_by_id by mentioning its use for full content.
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 clear context for when to use (listing/triage, pagination) and mentions alternative get_email_by_id for full content. Does not explicitly exclude other scenarios like search, but context signals are 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?
Annotations already declare readOnlyHint and openWorldHint, so the description adds little beyond stating the scope. No contradictions, but no extra behavioral detail needed.
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 efficient sentences: first states purpose, second provides usage alternatives. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With high schema coverage, annotations, and an output schema (exists), the description plus structured fields fully cover the tool's behavior. Simple tool with no missing 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?
Schema coverage is 100%, so baseline 3. Description mentions 'caller-selected time window' which loosely refers to the days parameter, but adds no meaningful extra semantics 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?
Description uses specific verb 'Return daily sent/received volume' and explicitly distinguishes from siblings (get_email_analytics, get_unread_count), making the tool's purpose clear and unique.
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?
Directly states when to use this tool (for daily volume in a time window) and provides explicit alternatives with use cases (broader dashboard, current unread counts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details specific destructive actions (terminates bridge, disconnects IMAP/SMTP, scrubs credentials, exits) beyond the annotations, providing valuable context for the 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?
Two concise sentences cover all key points without unnecessary words, making it efficient and easy to parse.
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 complexity, the description covers graceful shutdown, effects, credential handling, and exit, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds marginal info for 'confirmed' but nothing for 'account_id', so it does not significantly enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'shut down' and the resource 'MCP server', distinguishing it from sibling tools like 'restart_server' and 'start_bridge'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the requirement for confirmation parameter and that it terminates Proton Bridge, but does not explicitly state when to use versus alternatives or when not to 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?
The description adds behavioral details beyond annotations, such as the 15-second wait for ports and the idempotent start behavior. Annotations already provide idempotent hint, but the wait time is additional useful 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?
The description is two sentences, front-loaded with the main purpose, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 and presence of output schema, the description covers all essential aspects: what it does, idempotency, wait behavior. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter description already exists. The tool description does not add additional meaning about the account_id parameter, so 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 launches the Proton Mail Bridge, with a specific verb and resource. It distinguishes itself from sibling tools by being the only tool related to starting the bridge service.
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 when the bridge is not running, but does not explicitly state when to use vs alternatives. However, the sibling context makes it clear, and the idempotent nature ensures safe repeated calls.
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?
Adds value beyond annotations by disclosing that it invalidates the folder cache and involves an IMAP network operation. No contradictions with annotations.
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 core action, no unnecessary words.
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?
With only one optional parameter, output schema present, and comprehensive annotations, the description covers purpose, timing, and behavioral effect completely.
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 optional parameter is fully documented in the schema with description. The tool description does not repeat param details, which is acceptable given 100% 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 uses specific verb+resource ('Refresh the folder list from IMAP') and provides concrete use cases, distinguishing it from sibling tools like sync_emails or create_folder.
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?
Explicitly states when to call (after client-side changes, or when counts seem stale) and implies when not to use. Could mention alternatives but not necessary given clarity.
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?
Annotations only show readOnlyHint=false, destructiveHint=false, idempotentHint=false. Description adds that the path must be unique across namespaces and that success is returned after Bridge acceptance, providing useful behavioral context beyond annotations.
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, no redundant words. Each sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage and annotations, description covers creation, naming, return behavior, and related operations. Could mention error conditions like duplicate path, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes both parameters (100% coverage). Description adds format examples (e.g., Folders/Archive) and uniqueness requirement, which adds slight value but does not substantially exceed schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create one new IMAP mailbox' and distinguishes from rename_folder by mentioning it as an alternative for changing existing mailboxes.
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 use Folders/Name or Labels/Name, name must be unused, and advises creating labels before adding with move_to_label. Also references rename_folder as alternative for modifications.
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?
Annotations already declare readOnlyHint=true, and the description adds that it is a local search dependent on fts_rebuild having populated the index. It does not contradict annotations and provides useful context about the search algorithm and index dependency.
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-loads the main purpose, and contains no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description adequately covers the search algorithm, supported syntax, and usage context. It mentions the dependency on fts_rebuild, which is important for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is fully documented (100% coverage), and the description does not add additional parameter semantics beyond the schema. 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 performs BM25-ranked keyword search over the locally indexed mail corpus, listing supported FTS5 syntax and explicitly distinguishing it from the sibling tool search_emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use search_emails for live, authoritative IMAP results; use this for faster ranked local search after fts_rebuild has populated the index.' This clearly states when to use this tool vs. the alternative.
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?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds value by noting that results are cached for 5 minutes and that response times are null when data is insufficient, which annotations do not cover. No contradictions.
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, each purposeful: first defines the output, second provides guidance on alternatives, third notes caching. Front-loaded and concise 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?
Given the complexity (dashboard with multiple metrics) and the presence of an output schema, the description is complete enough. It mentions caching and null values, though it could hint at data range or pagination if applicable, but overall adequate.
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% (the single parameter account_id has a detailed description in the input schema). The description does not add new parameter semantics beyond what the schema 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 uses a specific verb ('Return') and names the resource ('detailed inbox-and-sent dashboard') with clear data points. It distinguishes itself from sibling tools get_email_stats and get_volume_trends, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs alternatives: 'Use get_email_stats for a compact overview or get_volume_trends for a custom date window.' Also mentions caching behavior (5 minutes), guiding usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint and openWorldHint annotations by detailing that the tool returns message counts, folder types, and specialUse attributes. It also discloses the behavioral trait of labels appearing as folders with a prefix and warns about the \All special use, giving agents safe usage guidance.
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 front-loaded with the main purpose and then adds necessary details. It is well-structured but slightly longer than minimal; however, each 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?
Given the tool has a single optional parameter, annotations, and an output schema, the description covers all key aspects: listing folders with counts, folder types, specialUse, and the important warning about the \All union view. The agent has complete context to use 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?
With 100% schema description coverage, the input schema already fully documents the single optional parameter 'account_id'. The tool description does not add parameter-specific meaning, so 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 lists all email folders with message counts, and explains labels appear with 'Labels/' prefix. It distinguishes from sibling tools like 'list_labels' and 'sync_folders' by detailing folderType and IMAP specialUse attributes.
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 guidance on when to use this tool—specifically to identify the real Trash/Sent/Archive using specialUse attributes rather than English names. It also warns against moving mail into the \All (All Mail) union view. However, it does not explicitly mention alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint: true, but the description adds that it requires 'confirmed: true' to execute, which is a key behavioral constraint not captured by the annotation flags alone.
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 purpose and a clear behavioral note. Every word earns its place; 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 the simple nature of the tool, the description is mostly complete. Output schema exists but the description does not explain return values; however, the schema covers that. Could mention the effect on the email or any side effects, but it's sufficient for a straightforward action.
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?
With schema description coverage at 75%, the description does not add meaning beyond what the input schema already provides. It mentions the 'confirmed' requirement but that is also documented in the schema. No additional parameter insight is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move an email to the Spam folder' and identifies it as a convenience wrapper for move_email targeting Spam. This specific verb+resource combination distinguishes it from siblings like move_email or move_to_folder.
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 notes it is a convenience wrapper and that it is destructive requiring confirmation. It implies use when you want to move to Spam specifically, but does not explicitly contrast with alternatives or discuss when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral details beyond the annotations: labels are lost when moving (label copies not preserved) and the tool requires explicit confirmation. Since annotations already mark it as destructive, this additional context about label behavior and the confirmation requirement provides valuable transparency for the 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 extremely concise, consisting of only three sentences that are front-loaded with the core purpose. Every sentence adds value: the first states the function, the second explains it is a wrapper, and the third provides essential behavioral notes. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema and annotations, the description covers the key aspects: purpose, label loss behavior, and confirmation requirement. It is sufficient for correct invocation, though it could be slightly enhanced by noting that trashing is reversible (e.g., can be undone from Trash).
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 description coverage is 75%, so the schema already documents most parameters. The description adds only a reference to the confirmed parameter (mentioning the requirement), but does not elaborate on emailId, account_id, or sourceFolder beyond what the schema provides. This meets the baseline but does not add significant extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move an email to the Trash folder' and identifies itself as a 'Convenience wrapper for move_email targeting Trash', which clearly specifies the verb and resource while distinguishing it from the general move_email tool. This is highly specific and leaves no ambiguity about the tool's 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 implies that this tool should be used when moving an email to Trash (as opposed to other destinations) and notes the requirement for confirmation ('requires { confirmed: true }'). However, it does not explicitly mention when not to use it or compare it to alternatives like delete_email or archive_email, which would provide stronger 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?
Annotations indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds value by specifying the non-destructive nature (email remains in original folder) and the UID space nuance. This provides behavioral context beyond annotations. Could mention error handling or reversibility, but 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 two sentences, each carrying important information. It is front-loaded with the core action and immediately addresses the critical nuance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description effectively covers the core operation, the non-destructive effect, and a key caveat about UID space. It does not explain error conditions or what happens if the label doesn't exist, but overall it provides sufficient context for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds crucial meaning for the 'emailId' parameter by clarifying it must be the UID in Labels/{label} and not the inbox UID. This goes beyond the schema description. No extra context for 'label' or 'account_id' beyond schema, but the addition elevates the score.
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 'Remove a label from an email' and explains that the email remains in its original folder, distinguishing it from deletion or moving. This is specific and differentiates from sibling tools like 'delete_email' or 'move_to_trash'.
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 explicit guidance on the UID requirement: the UID must be from the Labels/{label} folder, not the INBOX. This tells the agent when to use this tool (only if you have the label-folder UID) and implies that if you have the inbox UID, you need to get the label UID first. However, it does not mention alternatives like 'bulk_remove_label' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint=true). The description adds value by explaining that deletion is recoverable (moved to Trash), that progress notifications are emitted if a progressToken is provided, and that return counts are provided. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a brief note about progress and returns. Every sentence adds essential information, with the core action and safety behavior 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 complexity (4 parameters, output schema exists), the description fully covers the action, confirmation requirement, folder parameter context, progress notifications, and return type. No gaps for an agent to misinterpret.
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 75% (emailIds lacks description). The description compensates by explaining the requirement for `confirmed` and the rationale for `sourceFolder` (folder-scoped UIDs). This adds meaning beyond the schema's parameter names and types.
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 verb ('Delete multiple emails') and the resource ('emails'), and importantly clarifies that it moves emails to Trash, not permanently deletes. This distinguishes it from siblings like 'delete_email' (single) or 'empty_trash' (permanent).
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 requires `confirmed: true` to execute, and advises passing `sourceFolder` when UIDs come from a folder other than INBOX. It provides clear context for use, though it could explicitly state when not to use it vs. siblings like 'bulk_move_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?
The description reveals that the operation is non-destructive to emails (they remain in folders) and highlights the UID space nuance. This adds valuable context beyond the annotations (readOnlyHint=false, destructiveHint=false). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two focused sentences. Each sentence serves a purpose: first states the action, second provides critical behavioral details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the straightforward nature of the tool (removing a label from emails), the description covers the key caveat (UID spaces) and the effect. The parameter descriptions in the schema are also complete, making the overall definition 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 coverage is 100%, so baseline is 3. The description adds meaning by explaining why emailIds must be from the label folder, reinforcing the schema's description. It also clarifies that the operation does not affect original folders.
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 (remove a label from multiple emails) and specifies the effect (emails remain in original folders). It also provides a critical distinction from siblings by explaining the UID space uniqueness.
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 explicit guidance that UIDs must come from Labels/{label} and warns that using INBOX UIDs will silently miss. It does not explicitly state when not to use this tool versus alternatives like remove_label, but the context is strong.
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?
The description adds value beyond annotations by stating that it emits progress notifications and returns success/failed counts. It also reveals the behavioral nuance of sourceFolder scoping. Annotations already indicate non-readOnly and non-destructive, and description complements them. It does not explicitly mention idempotency, but idempotentHint is true.
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 sentences with no redundancy. Each sentence serves a distinct purpose: stating the core action, mentioning side effects (progress notifications, return counts), and providing crucial usage guidance. 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 complexity (bulk operation with folder scoping) and the presence of an output schema, the description covers main behavioral aspects and the critical sourceFolder parameter. It could be more explicit about when to use this tool versus the singular star_email, but overall it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the missing schema description of isStarred by implying its role (star/unstar). It also reinforces the critical sourceFolder parameter with detailed usage guidance, adding meaning beyond the schema. Schema coverage is 75%, and the description fills gaps effectively.
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 'Star or unstar multiple emails,' specifying the verb (star/unstar) and resource (emails) in bulk. It also mentions progress notifications and return counts, adding clarity. It effectively distinguishes from sibling tools like star_email by emphasizing the bulk aspect.
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 explicit guidance for using sourceFolder when UIDs come from a folder other than INBOX, including a warning about 'All Mail.' However, it does not contrast with the singular star_email tool or specify when not to use this tool, leaving some room for ambiguity.
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?
Annotations already indicate idempotentHint=true and destructiveHint=false. Description adds specifics: clears specific caches and forces fresh IMAP fetches on next access. Provides good behavioral context beyond annotations.
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 short sentences. Front-loaded with action and purpose. No redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description covers purpose, when to use, what it does, and what it doesn't do. Complete for an AI agent to select and invoke 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?
Only one parameter (account_id) with 100% schema coverage. The schema description fully explains it. Description does not add extra meaning, 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?
Description explicitly states the tool clears all in-memory caches (email message cache, folder cache, analytics cache) and forces fresh IMAP fetches. It also distinguishes from fts_rebuild by stating what it does not do.
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?
Clearly says 'Use if you suspect stale data.' Also explicitly states when not to use: 'Does NOT rebuild the on-disk FTS index — run fts_rebuild to refresh fts_search results.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and description adds behavioral context: it's heuristic, best-effort on assignee/due-date, and non-destructive. It does not contradict annotations and provides sufficient transparency about the tool's limitations and 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?
Three sentences, no wasted words. Front-loaded with the core function, immediately followed by caveats. Each sentence earns its place.
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 3 parameters, presence of output schema, and readOnlyHint annotation, the description is complete. It explains what the tool does, its limitations, and usage context without needing to detail return values (handled by 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?
Schema description coverage is 100% with each parameter clearly described (folder, email_id, account_id). The tool description does not add additional meaning beyond what the schema provides, so 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?
Description clearly states it scans an email body for action-item-looking lines (bullets, TODO markers, @mentions) and returns structured list. Distinguishes itself from a real task extractor by noting it's heuristic and for quick triage. This leaves no ambiguity about 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?
Explicitly says it's not a replacement for a real task extractor and useful for quick triage, giving when-to-use and when-not-to-use guidance. However, it does not mention specific alternatives or sibling tools like extract_meeting for comparison, so it could be more explicit.
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?
Annotations declare readOnlyHint=true, and the description adds behavioral context: statistics are returned, with 'if computable' noting potential unavailability. No contradiction.
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 that efficiently convey purpose, usage, and behavioral nuance with zero waste.
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 output schema exists, description adequately covers inputs and behavioral expectations. Read-only annotation and parameter descriptions complete the picture for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning beyond schema: emphasizes 'single email address', explains account_id routing, and references settings UI for multi-account configs.
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 returns relationship statistics for a single email address, specifying exact data points (volume, first/last interaction, response time). It differentiates from numerous sibling tools by providing a specific use case: before drafting to match tone and 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 explicitly notes the tool is 'useful before drafting', providing clear guidance on when to use. While it doesn't list alternatives, the context sufficiently implies usage scenario.
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?
Annotations already declare readOnlyHint and openWorldHint. The description adds that it returns body, attachment metadata, isAnswered, and isForwarded flags, and explicitly excludes binary content. No contradictions.
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-loads the core purpose, and uses clear language with no superfluous content.
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?
With an output schema present, annotations, and clear parameter docs, the description provides all necessary information for correct invocation and understanding of return values.
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% with descriptions for all parameters. The description adds further context, e.g., that folder avoids UID collision and that account_id is for multi-account routing, which goes 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 it fetches a single email's full content including body and metadata, and explicitly excludes binary attachment content. It specifies the source of the ID (get_emails or search_emails), distinguishing it from sibling tools like get_emails and download_attachment.
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 instructs to use the ID from get_emails or search_emails, implying proper usage context. It does not explicitly list when not to use or directly compare to siblings, but the information is sufficient for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the behavioral safety profile. The description adds context of being a legacy wrapper, which is useful but does not disclose additional behavioral traits beyond annotations.
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 purpose and guidance. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown but indicated), the description adequately covers purpose and usage guidance. No additional context needed for this simple wrapper 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 coverage is 100%, so parameters are well-documented in the schema. The description does not add extra meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a legacy convenience wrapper for get_emails with a fixed folder set to Labels/<label>. It distinguishes itself from the sibling tool get_emails by specifying that get_emails is preferred for canonical pagination and summaryOnly options.
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 advises to prefer get_emails for canonical pagination and summaryOnly, providing clear when-to-use and when-not-to-use guidance. Names the alternative tool directly.
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?
Annotations already declare readOnlyHint and openWorldHint. Description adds caching duration (5 minutes), which is beneficial behavioral context beyond annotations.
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 efficiently cover purpose, usage guidance, and caching. No redundancy, well 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?
For a simple tool with one optional parameter and an output schema, the description fully covers what the tool does, its caching behavior, and when to use alternatives. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter account_id. Description does not add any additional semantics or context for the parameter beyond the schema, 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?
Clearly states the tool returns a compact inbox-and-sent dashboard with specific outputs (totals, unread count, most active contact, storage estimate). Mentions sibling tools for differentiation.
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 tells when to use (for a compact dashboard) and when not to (for deeper breakdowns or custom date windows), directing to get_email_analytics and get_volume_trends.
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?
Annotations indicate readOnly and openWorld hints. Description adds value by stating the call is cheap (performance trait) and specifying the return type (object mapping folder to count). No contradictions with annotations.
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, each serving a specific purpose: purpose statement, usage guideline, return format. No wasted words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and presence of output schema, the description sufficiently covers purpose, usage, behavior, and return type. No additional context needed for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for account_id. Description adds context about multi-account routing and omitting for active account, enhancing the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves unread email counts per folder, using specific verb and resource. It distinguishes from siblings like get_emails by noting it's a cheap call to use before fetching.
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?
Explicitly advises to use before get_emails to decide whether to fetch, providing clear when-to-use guidance. No exclusions or alternatives beyond get_emails are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds valuable behavioral context: the default value, the requirement for sourceFolder to avoid silent no-ops, and the warning against using 'All Mail' as source. No contradictions with annotations.
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: first defines purpose, second provides key usage guidance. Every sentence is necessary and adds value. No superfluous text.
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?
The description covers the essential behaviors (keyword, default, folder scoping) and integrates with the forward tool context. With output schema available (not shown), return values are presumably documented, so the description is sufficiently 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 coverage is 50% (descriptions for account_id and sourceFolder). The description adds only marginal value: it repeats the default for 'forwarded' (already in schema) and adds a warning about 'All Mail' for sourceFolder. No new info for emailId or account_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set or clear' and the resource '$Forwarded keyword on an email', explicitly linking it to the forward tool. This distinguishes it from sibling tools like mark_answered or mark_email_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on the default value for 'forwarded' and when to use 'sourceFolder' (when UID comes from a folder other than INBOX). However, it does not explicitly contrast this tool with alternatives or specify when not to use it, leaving some ambiguity.
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?
Beyond annotations, the description reveals internal behavior: it captures Message-ID and recipient, then fires after N days. This adds meaningful behavioral context beyond the readOnly/destructive hints.
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, no redundancy, front-loaded with key purpose. Every sentence serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description fully covers purpose, parameters, and related tools. It provides sufficient context for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds value by explaining the IMAP UID purpose, folder collision avoidance, account routing, and day range. This supplements the schema definitions effectively.
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 schedules a follow-up reminder for a sent message using its IMAP UID. It differentiates from sibling tools like check_reminders, list_pending_reminders, and cancel_reminder, making the purpose distinct 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 explains the input requirements (IMAP UID, days) and mentions related tools for lifecycle management. It lacks explicit 'when not to use' guidance but provides adequate context for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-idempotent behavior. The description adds valuable context: termination of Proton Bridge, graceful shutdown, spawning a new process, and autoStartBridge behavior. No contradictions with annotations.
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 sentences with no wasted words. It front-loads the purpose, then explains the process and a key requirement. Ideal length and structure.
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 server restart tool with 2 parameters, good schema/annotation coverage, and an output schema present, the description covers behavior, confirmation requirement, and auto-bridge nuance comprehensively. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well described. The description reinforces the 'confirmed' parameter but adds no new semantic meaning beyond the schema. 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 tool restarts the MCP server with specific actions (terminate, shut down, spawn fresh process). It distinguishes from siblings like shutdown_server (which only shuts down) and start_bridge (which only starts Bridge).
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 requires 'confirmed: true', providing a clear precondition. However, it does not directly compare to sibling tools like shutdown_server or start_bridge, leaving some ambiguity about when to use this vs 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?
Annotations already declare readOnlyHint=true, so safety is clear. The description adds behavioral details like 'returns the single next action' and 'always available', which go beyond annotations and help the agent understand what happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences, front-loaded with the imperative 'CALL THIS FIRST', and no redundant information. 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?
Given the tool has an output schema (not shown but referenced), the description adequately explains what it returns (single next action) and when it's available. It covers all necessary context for a diagnostic 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 covers the single optional parameter (account_id) with a clear description (100% coverage). The main description does not add new parameter details, which is acceptable given the schema quality, earning a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'CALL THIS FIRST' and clarifies it diagnoses end-to-end connectivity, listing specific checks (credentials, Proton Bridge reachability, agent access). It distinguishes itself from the sibling 'get_connection_status' by specifying the latter is for live IMAP/SMTP health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'CALL THIS FIRST' and 'Use get_connection_status afterwards'. It also notes it works even before the agent is approved or credentials are set, setting expectations for when to invoke.
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?
Annotations provide readOnly=false, idempotent=true, destructive=false. Description adds context about cache refresh and return behavior, no contradictions.
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: one for main action, one for usage guidance and sibling distinction. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values are covered. Description provides sufficient context for tool usage and parameter 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?
Schema coverage is 100%; description does not add parameter details beyond schema, but baseline for high coverage is 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?
Clearly states verb 'fetch' and resource 'emails from IMAP into local cache'. Distinguishes from sibling 'get_emails' by noting paginated access.
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 'Use this to refresh the cache after Bridge syncs new messages' and contrasts with 'get_emails for paginated access'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it mentions progress notifications, return counts, and warns about IMAP UID scoping and the risk of silent no-ops with 'All Mail'. The idempotentHint and destructiveHint are also consistent.
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, each adding essential information. It is front-loaded with the core action and quickly covers critical usage advice without 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?
The description covers the action, return format, progress notifications, and a key caveat about sourceFolder. Given the output schema likely documents return structure, it is reasonably complete, though it could mention error handling or when to prefer this over single mark_read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the sourceFolder parameter by explaining the folder-scoping issue and warning against 'All Mail'. It also notes the default isRead value. With 75% schema coverage, the description provides valuable extra guidance.
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 marks multiple emails as read or unread, distinguishing it from single-email alternatives like mark_email_read. It also mentions progress notifications and return counts.
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 advises passing sourceFolder when UIDs are from a non-INBOX folder, which is critical for correct operation. However, it does not explicitly compare to other bulk tools like bulk_star or bulk_move.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses progress notifications with progressToken, return format (success/failed counts), potential silent no-op without correct sourceFolder, and no-op when moving to same folder. These are important behaviors beyond the annotations (which only indicate readOnly=false, etc.).
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?
Every sentence adds unique information; no redundancy. Purpose is front-loaded. The description is compact yet covers all critical aspects.
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?
With 5 parameters, 100% schema coverage, and presence of an output schema (implied by return mention), the description sufficiently covers usage, edge cases, and behaviors. No gaps 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value: explains that emailIds are UIDs, clarifies sourceFolder's role with IMAP scoping and pitfalls, and reiterates the confirmed requirement for Trash/Spam. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Move multiple emails to a folder in one call,' clearly stating the verb (move) and resource (emails). It distinguishes from siblings like move_email (single) and bulk_move_to_label (different target type).
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 explicit conditions: requires 'confirmed: true' for Trash/Spam, and advises to pass sourceFolder when UIDs are from non-INBOX folders, warning against 'All Mail'. Does not explicitly compare to alternatives like single move, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, idempotentHint=false, destructiveHint=false, indicating a non-destructive mutation. The description confirms by stating 'Each email remains in its original folder and also appears in Labels/{label}', which aligns with and adds detail to the annotations. No contradictions.
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, each serving a purpose: first defines action and effect, second provides usage guidance and a note about progress. Concise 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 presence of an output schema and the clear explanation of behavior, sibling differentiation, and large-batch notifications, the description is complete for this tool's 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 coverage is 75% (3 of 4 parameters described). The description adds the label format detail ('Labels/{label}') beyond the schema's 'Label name without prefix', but the sourceFolder parameter is not mentioned in the description. The baseline is 3 due to high schema coverage, and the description adds only marginal extra meaning.
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 'Add a label to multiple emails' and explicitly distinguishes from the sibling bulk_move_emails by noting when to use that alternative. This provides a specific verb-resource pair with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('Each email remains in its original folder') versus the alternative bulk_move_emails ('only when messages should leave their source folder'). It also mentions progress notifications for large batches, guiding usage expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint: true, readOnlyHint: false), the description adds that the action is reversible (moves to Trash, not permanently deleted) and idempotent for already-trashed emails. It also explains the confirmation requirement.
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 sentences, front-loading the key action and behavior, with no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (implicitly covering return values) and the description covers purpose, usage conditions, parameter guidance, and behavioral nuances, it is fully complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for 'confirmed' and 'sourceFolder' parameters, explaining their necessity and usage context. The schema already covers the other parameters (emailId, account_id) with adequate descriptions, so the additional value is moderate.
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 moves an email to Trash (not permanent deletion) and specifies behavior for already-trashed emails. This distinguishes it from sibling tools like empty_trash or permanent delete actions.
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 guidance on requiring 'confirmed: true' and passing 'sourceFolder' when UIDs come from non-INBOX folders. However, it does not explicitly differentiate from the sibling tool 'move_to_trash', which may cause confusion about when to use which.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the behavioral detail that the output is base64-encoded content and explains why folder is needed. It does not contradict annotations and provides clear context beyond annotations.
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, no fluff. The first sentence clearly states the purpose. Each sentence adds essential information: output format, prerequisite, and folder parameter guidance.
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?
The output schema exists (not shown but context indicates true), so return values are covered. The description explains the output format (base64), prerequisite step (get_email_by_id), and the folder parameter need. This is complete for a download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by cross-referencing get_email_by_id for attachment_index, explaining the rationale for folder, and clarifying account_id optionality. It provides meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads binary content as base64-encoded string. It specifies the resource (email attachment) and the output format, and distinguishes from siblings by mentioning the prerequisite use of get_email_by_id to locate attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use get_email_by_id first to see attachments and indices. It also explains the folder parameter requirement for folder-restricted agents and the cross-folder UID collision reason. However, it does not discuss alternative tools or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations: emphasizes 'PERMANENTLY', 'UNRECOVERABLE', and 'bypasses the move-to-Trash safety net'. Clearly conveys destructive nature and requirement for confirmation.
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 with no waste. Front-loaded with the critical purpose and severity. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavioral details, and parameter requirement. With output schema present, return value explanation is unnecessary. Complete for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds context that 'confirmed' must be true and stresses unrecoverability, reinforcing schema info. Provides slight additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'PERMANENTLY delete' and resource 'every message in the Trash mailbox'. Distinct from siblings like move_to_trash and delete_email by specifying it bypasses the safety net and empties the entire trash.
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?
Explicitly states when to use (permanent deletion of all trash) and that it only touches Trash mailbox, never live mail. However, no explicit alternatives when not to use, though implication is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms a read-only health check. It adds specific behavioral details (returns status, TLS mode, host/port) without contradicting annotations. No destructive or side effects are implied, consistent with safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and output details, followed by a clear usage hint. No redundant information; every sentence is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, read-only, with an output schema), the description covers all necessary aspects: what it checks, what it returns, and when to use it. The output schema handles return value details, so no further elaboration 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 description coverage is 100% for the single optional parameter 'account_id', which is already well-documented in the schema. The description does not add new parameter meaning, 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 tool checks live SMTP and IMAP health after setup. It differentiates from sibling tools like setup_status by explicitly directing users to use setup_status first for credentials, Bridge reachability, or agent-approval diagnosis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use setup_status first for certain diagnostics, implying this tool is for after setup. This helps the agent decide when to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) are complemented by description specifying behavior: lists only Labels/ prefix, includes message counts, excludes regular folders. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded primary purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and only one optional parameter, the description fully covers purpose, usage guidance, and behavioral traits for effective agent 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?
Only one parameter (account_id) with full schema description. Tool description does not add further parameter-specific meaning beyond what schema provides, so baseline score 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?
Clearly states the tool lists Proton Mail labels with message counts, distinguishing from get_folders which includes regular folders. Verb 'list' + specific resource and scope.
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 tells when to use this tool vs. get_folders, stating that get_folders should be used when regular folders, folder type, or IMAP metadata are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses server-side IMAP SEARCH, local filtering for hasAttachment, folder cap of 20, and returns summaries. No contradiction with readOnlyHint and openWorldHint annotations.
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?
Fully informative and well-structured, but slightly long; still every sentence adds value, earning a high score.
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 high schema coverage, output schema existence, and detailed description, the tool is fully specified for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context beyond the high-coverage schema: explains search mechanism, folder behavior, and local filter for hasAttachment, making parameter usage clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the live mailbox' and enumerates many searchable fields, distinguishing it from sibling tools like fts_search and get_email_by_id.
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 tells when to use fts_search (faster local ranked search) and get_email_by_id (full content), and explains folder vs folders usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that approval requires a human action (opening UI and clicking Approve), which is critical behavioral context beyond annotations. It adds the URL and process, and notes the non-self-approvable nature. No contradiction with annotations.
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 containing all essential info: what it does, that agent cannot approve, where to approve, how to poll, and a note about downgrading. Every sentence earns its place; front-loaded with purpose.
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 complexity (requires human approval, polling for result), the description covers the full workflow: request, human approval step, polling. It also addresses downgrading. No output schema needed as the polling tool handles results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaningful advice beyond schema: 'Be specific' for reason, 'Omit to use the active account' for account_id, and 'Must be higher than current preset' for target_preset. Schema coverage is 100%, but description provides extra guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: requesting an increase in permission preset. It explicitly distinguishes from checking status (check_escalation_status) and notes that downgrading doesn't require this tool. The verb+resource is precise.
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 states when to use: to request higher permissions. It tells the agent it cannot approve and must poll via check_escalation_status. It also clarifies that downgrading never requires a challenge, implying not to use this for reduction.
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:

[![mailpouch MCP server](https://glama.ai/mcp/servers/chandshy/mailpouch/badges/card.svg)](https://glama.ai/mcp/servers/chandshy/mailpouch)

Score Badge

Copy to your README.md:

[![mailpouch MCP server](https://glama.ai/mcp/servers/chandshy/mailpouch/badges/score.svg)](https://glama.ai/mcp/servers/chandshy/mailpouch)

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/chandshy/mailpouch'

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