Proton Mail Bridge MCP

by googlarz

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: v1.18.10
Disambiguation2/5
Many tools have overlapping purposes, e.g., multiple delete tools (delete_email, bulk_delete, trash_email, empty_folder) and multiple search tools (search_emails, search_indexed_emails, count_messages). Descriptions help partially but still require careful reading to avoid misselection.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., batch_email_action, bulk_delete, send_email). Minor inconsistencies: 'flag_thread' vs 'apply_thread_action', 'star_email' vs 'update_message_flags', and mixing 'email' and 'message' references.
Tool Count2/5
48 tools is excessive for a mail bridge server. The granularity leads to many single-purpose tools that could be consolidated, making the surface overwhelming and over-decomposed for the domain.
Completeness3/5
Covers core email operations (send, receive, move, delete, search, sync) but missing basic draft creation tools (despite references in descriptions) and folder listing tools, which are notable gaps.
Average 4.5/5 across 47 of 48 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 8 of 8 community issues answered or closed in the last 6 months
- No commit activity data available
- Last stable release on September 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
View related servers

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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint=false, which is consistent. Description adds that flags can be added or removed, but doesn't detail other behavioral traits like rate limits, side effects, or behavior when flags already exist. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words, front-loaded with purpose and usage guidelines. Highly concise.
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 5 parameters and no output schema, the description provides usage context but omits details on dryRun (test mode) and acrossFolders scope. Return value not mentioned, but for a flag-modification tool, that may be acceptable. Moderate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only messageId has a description). The tool description does not explain dryRun, flagsToAdd, flagsToRemove, or acrossFolders. This leaves agents without crucial parameter context. Fails to compensate for low 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?
Clearly states the tool adds or removes IMAP flags across all messages in a thread using the Message-ID header. Distinguishes itself from sibling apply_thread_action by specifying when to use each.
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 to use this tool when you have the raw Message-ID and want to flag an entire conversation, and to prefer apply_thread_action with specific actions when you have a local threadId. Provides clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the read-only nature, so the description adds little beyond 'saved' and 'by id'. It does not disclose behavior on missing IDs, error handling, or the exact return structure, but remains consistent with the annotation without 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, clear sentence with no wasted words. It front-loads the verb and resource, making it concise and easy to parse.
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 one-parameter getter, the description covers the core purpose and scope. It does not mention what happens if the template is not found or the response format, but given the readOnlyHint and the simple nature, it is largely complete. Slightly brief but 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 input schema has full coverage for the single 'id' parameter, including a helpful description referencing create_template and list_templates. The tool description itself adds no parameter details, but the schema sufficiently documents it, 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 verb 'Get' and the resource 'single saved email template by id', making it distinct from list_templates (plural) and create/delete operations. It is specific and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—fetching a template by its ID—but does not explicitly mention when to use it instead of alternatives like list_templates or render_template. No exclusions or alternate scenarios are provided, leaving usage to be inferred.
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 is consistent with the readOnlyHint annotation, and it adds scope by saying 'all saved templates.' However, it does not disclose return format, ordering, pagination, or any other behavioral details beyond the annotation already offering the read-only safety signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that directly states the function with no filler or redundancy. It is perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing operation, the description is adequate: it names the resource and the operation. It could mention output shape, but with no output schema and no parameters, this is not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter information because there are no parameters to explain, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'all saved email templates,' clearly distinguishing it from sibling tools like get_template or create_template. It is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_template or search tools. There are no usage contexts, exclusions, or mention of related tools.
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 annotations include destructiveHint: true, which already signals that the operation is destructive. The description adds that it deletes a 'saved' template, but this is a minor addition. It does not disclose side effects like permanence or whether the deletion can be undone, but with the destructive hint, the agent is aware of the risk.
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 one short sentence, front-loaded with the action, and contains no unnecessary words. It is concise and well-structured.
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 deletion operation with one parameter and a destructive hint, the description is sufficiently complete. No output schema is present, so no return value explanation is needed. The parameter is fully documented, and the tool's purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter `id` with a description 'The template id,' providing 100% coverage. The description does not add any further detail about the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and the resource 'saved email template,' which clearly distinguishes it from sibling tools like create_template, list_templates, and get_template. It's not a tautology because it specifies that the template is 'saved.'
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 no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. However, the phrasing 'saved email template' implies that this tool is for deleting templates, not drafts or emails, so usage is implicitly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the optional saveTo parameter that can write to disk, which implies side effects. However, the annotation declares readOnlyHint: true, suggesting no state change. This is a contradiction, as the tool can mutate disk state. Hence score 1 due to annotation 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?
Four sentences, front-loaded with purpose, every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description hints at return values for saveTo case. It could be more explicit about the metadata structure, but overall sufficient given sibling tools and 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 coverage is 100%, baseline 3. The description adds value by explaining the default for includeBase64, the need for environment variable for saveTo, and configuring inline size threshold. This 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 'Fetch metadata for a specific email attachment and optionally return its base64-encoded content inline,' which is a specific verb+resource. It distinguishes itself from siblings like save_attachment and list_attachments by mentioning when to use the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when you need to read or process attachment data in-memory' and 'Prefer save_attachment to write the file to disk instead,' providing clear context and alternative.
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. The description does not add behavioral context such as side effects of syncBefore parameter (e.g., index refresh). With annotations present, the bar is lower, but the description provides no extra transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. The first sentence captures the core purpose; the second provides usage guidance and alternatives. Perfectly sized and 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?
With no output schema, the description should explain what the tool returns (e.g., thread IDs, metadata). It does not describe the return format. However, given the usage guidelines and parameter details, it is adequate for basic invocation. Could be more 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 100%, so the schema already documents all parameters. The description lists example categories but adds no semantic detail beyond the schema definitions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find'), the resource ('email threads'), and the scope ('likely containing important document attachments...'). It distinguishes from siblings by noting it works without knowing exact sender or subject, and explicitly names an alternative tool for custom queries.
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 says when to use ('locate attachment-heavy threads by category without knowing exact sender or subject') and when not to ('Prefer search_indexed_emails with hasAttachment:true for custom attachment queries beyond the built-in categories').
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 annotation readOnlyHint=true already indicates a safe read operation, and the description adds context by specifying the queue source (send_email with PROTONMAIL_SEND_DELAY_SECONDS, schedule_draft) and the returned fields (id, status, sendAt). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core action and resource. It efficiently conveys the queue's origin and the purpose of the tool, though splitting it into two sentences could improve readability slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, read-only annotation, and no output schema, the description is sufficiently complete. It explains what is listed, where the items come from, and how the result should be used (to obtain the id for cancel_send), without requiring further detail for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (status) with a clear description ('Filter to one status. Omit to list everything.'), so the description does not need to add much. It mentions status as part of the output, but this is not additional parameter semantics beyond the schema's 100% 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 lists every item in the local undo-send/scheduled-send queue, including id, status, and sendAt. It distinguishes itself from siblings by explicitly mentioning the use case of rediscovering the id for cancel_send, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool, specifically to recover a lost id needed for cancel_send. It does not explicitly exclude alternatives, but the reference to cancel_send and the queue origin (send_email with delay, schedule_draft) implies the appropriate usage scenario.
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 indicate readOnlyHint: true, so the safety profile is clear. The description adds context about the scope ('every snoozed email') and the return fields (id, status, wakeAt), but does not cover other behavioral aspects like pagination or potential large result sets. With annotations covering the read-only nature, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that fronts the action and key details. It includes the purpose, the scope ('every'), the return fields, and the primary use case without any 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?
The tool is simple with one optional parameter and no output schema. The description covers what the tool returns (id, status, wakeAt), the optional filtering (status), and a concrete use case. This is complete enough for an agent to know when and how to use it.
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 'status' is fully documented in the schema with an enum and description. The description does not add extra semantic detail beyond the schema's own description, so it relies on the schema for parameter meaning. Baseline 3 is given because schema coverage is 100%.
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 'snoozed email', and the specific fields returned (id, status, wakeAt). It also distinguishes the tool's purpose by linking it to rediscovering the id needed for cancel_snooze, making it distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use: 'use this to rediscover the id needed for cancel_snooze if it was lost with the conversation.' It does not provide direct when-not-to-use guidance or name alternative list tools, but the use case is concrete and actionable.
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 discloses partial update behavior ('Only provided fields are updated — omitted fields retain their current values'), which is valuable. However, it misleadingly instructs to call sync_draft_to_remote after updating, contradicting the syncToRemote parameter that defaults to true and auto-syncs when IMAP is available. This creates confusion about whether the tool syncs automatically. Annotations only provide destructiveHint: false, offering minimal safety context, so the description carries the transparency burden and partially fails.
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, no filler. Every sentence contributes to understanding the tool's function, usage, or next steps. The structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, partial update behavior, and follow-up actions, but the sync guidance is misleading and omits the existence of the syncToRemote parameter behavior. Given the tool has 12 parameters and no output schema, this is a notable gap that could cause incorrect invocation. It is adequate but not fully reliable.
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 92%, so the baseline is 3. The description adds meaningful parameter behavior beyond the schema by explaining that omitted fields retain their current values — a critical semantic that is not apparent from individual field descriptions. It also clarifies the draftId refers to a 'locally saved draft.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: 'Update an existing locally saved draft's recipients, subject, body, or other fields.' This distinguishes it from create_draft (creates new), send_draft (sends), and sync_draft_to_remote (syncs). The partial update semantics further clarify the tool's 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?
The description explicitly states when to use it ('Use to edit a draft before sending') and provides alternatives for subsequent actions ('call send_draft to send or sync_draft_to_remote to push to Proton Drafts'). This clearly separates it from sibling tools.
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 annotations set destructiveHint to false, which aligns with the non-destructive nature of adding/removing labels. The description mentions the operation but does not detail behavioral aspects like idempotency, rate limits, or what happens with duplicate operations. With annotations covering the safety profile, a 3 is appropriate.
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 filler. Each sentence conveys essential information: purpose, when to use, and parameter constraint. It is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, a nested object (match), and no output schema, the description adequately explains the two modes of operation and the maxBatchSize safeguard. It is complete enough for correct invocation, though more detail on return values or error cases could be added.
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 86%, so most parameters are already described. The description adds value by explaining the XOR relationship between emailIds and match+folder, noting default maxBatchSize (500), and giving an example for labelsToAdd. This improves 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 tool's function: 'Add or remove Proton labels on multiple messages simultaneously.' It specifies the resource (labels) and action (add/remove), and distinguishes it from sibling tools like 'bulk_move'.
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: 'Use when the same label change should apply to several messages.' It also explains the XOR constraint between emailIds and match+folder, helping the agent choose parameters. However, it does not explicitly advise against using for single messages.
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 provide destructiveHint: false, which is minimal. The description compensates by disclosing key behaviors: placeholder auto-detection and storage, and failure on duplicate names. This adds meaningful context beyond the sparse annotation, though it does not mention return values or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. The first sentence states what the tool does; the second adds important behavior and failure mode. There is no filler, tautology, or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with full schema coverage, the description covers the essential elements: purpose, placeholder behavior, and duplicate handling. It does not explain return values, but no output schema exists and the tool's simplicity mitigates the need. It is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all four parameters, so the baseline is 3. The description adds a small behavioral note about placeholders in subject/body but does not materially enhance parameter semantics beyond the schema. It correctly leaves detailed parameter meaning to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Save a reusable email template', a specific verb+resource that clearly defines the tool's function. It distinguishes from sibling tools like list_templates, get_template, delete_template, and render_template by focusing on the creation action. Additional details about placeholders and uniqueness add clarity without 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?
The description clearly implies when to use this tool (to save a new reusable template) and provides a practical guideline: it fails on duplicate names, so you must delete the existing template first to replace it. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the destructiveHint annotation by explaining the automatic selection of the latest inbound message and the return of a draftId. However, it does not disclose potential side effects such as syncing to remote (though syncToRemote parameter implies this). With annotations only covering destructiveHint, the description provides moderate additional transparency but not comprehensive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then usage guidance, alternative, and return value. Every sentence adds value with no fluff, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters and no output schema, the description covers key context: purpose, use case, alternative, selection behavior, and return value. It does not elaborate on all parameters or potential caveats, but with full schema coverage this is sufficient. Slightly incomplete due to lack of mention of sync behavior or error cases, but generally complete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description aligns with the preferLatestInbound parameter by mentioning automatic selection of the latest inbound message, adding minimal extra meaning beyond schema. No significant parameter details are missing, but the description does not need to compensate.
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 creates a reply draft from a threadId, with the specific behavior of automatically selecting the latest inbound message. It distinguishes itself from create_reply_draft by noting the preference when an emailId is available, and from other draft tools by its thread-based focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use when you have a threadId from get_threads or get_actionable_threads and want to stage a reply for review' and 'Prefer create_reply_draft when you already have a specific emailId.' This clearly states when to use the tool and when to use an 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 only include destructiveHint=false, so the agent knows it is not destructive. The description adds valuable non-obvious context: the tool writes raw RFC822 content to disk and requires an environment variable to be set. It does not contradict annotations, and the extra behavioral details (e.g., .eml format, backup use) go beyond what structured fields 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 is two sentences, front-loaded with the core action and immediately providing use-case and configuration context. Every sentence adds value, and there is no redundant or filler content.
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 2-parameter export tool with no output schema, the description covers purpose, use case, and a configuration prerequisite. It does not explicitly state what happens when outputPath is omitted, but the schema already marks it optional. Given the low complexity and strong schema coverage, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (emailId in FOLDER::UID format, outputPath as optional file/directory). The description does not add much parameter-specific semantics beyond mentioning the .eml extension and the environment variable requirement. With 100% schema coverage, the 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 uses a specific verb ('Save') and resource ('full raw source (RFC822/.eml)') and clearly states the intended use case ('backup or migrating a message elsewhere'). This distinguishes it from sibling tools like save_attachment (which saves only attachments) and import_email (which brings messages in).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use for backup or migrating a message elsewhere') and provides a critical prerequisite (PROTONMAIL_ALLOW_FILE_DOWNLOAD_DIR configured, same as save_attachment). It does not explicitly state when not to use it or compare against alternatives, but the context is clear enough for an agent to select it appropriately.
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 is not required to reiterate safety. It adds context about ranking by urgency and filtering for action, but does not disclose deeper behavioral traits like indexing behavior or response format. With annotations covering the safety profile, a score of 3 is appropriate.
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 only three sentences, each with clear purpose: first sentence states the core function, second gives usage context, third references alternatives. No wasted words, front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description provides adequate context: what the tool does, when to use it, a key parameter (pendingOn), and sibling distinctions. It does not explain the return format or pagination, but with high schema coverage and read-only annotation, it is sufficiently complete for correct usage.
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 schema already documents all parameters. The description adds a small extra note about the pendingOn filter ('to distinguish threads waiting on you vs. them'), which reinforces the schema. However, it does not significantly extend understanding beyond the parameter descriptions, 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?
The description clearly states 'Return mailbox threads ranked by reply urgency, filtered to those requiring action' with a specific verb and resource. It distinguishes from siblings by naming get_inbox_digest and get_threads, explaining their different scopes.
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 says 'Use for daily triage to surface what needs a response from you' and provides alternative tools with reasons: 'Prefer get_inbox_digest for a broader summary including stale items' and 'Prefer get_threads for an unranked thread list'.
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 context that it reads from a local index (auto-refreshed if stale or empty) and reflects the last sync. This explains the data source and freshness behavior beyond the annotation. It also clarifies that results are frequency-derived, not from an address book, adding transparency about data provenance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the primary function, then usage, then data source caveats. Every sentence adds value, with no fluff 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 tool's simplicity (one optional param), the description covers purpose, usage, behavioral traits (read-only, auto-refresh), and caveats. It lacks explicit return format info, but no output schema exists and the tool is simple enough that this is not critical. It effectively compensates.
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 with a single 'limit' parameter that has a default and description ('Maximum contacts to return'). The description does not add extra semantics beyond that, but since the schema is self-explanatory, a 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 what the tool does: returns the most frequently contacted email addresses ranked by interaction volume within the analytics sample window. It distinguishes itself from sibling tools like top_senders and search tools by specifying frequency-derived ranking and usage for identifying key correspondents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use to identify key correspondents or to pre-populate recipient lists,' which provides clear context for when to use it. However, it does not explicitly state when NOT to use it or alternatives, though the note about not being a Proton contacts address book implicitly warns against using it for address book purposes.
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 states the action (move) without adding significant behavioral details beyond the annotation destructiveHint=false. It does not disclose whether the move is reversible, whether permissions are required, or what happens to the original location. However, the annotation already covers the non-destructive 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?
The description is very concise, consisting of two clear sentences. It front-loads the core action and provides immediate guidance on when to use it versus the alternative, with 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 tool has 4 parameters, no output schema, and only a destructiveHint annotation, the description provides sufficient context for an agent to understand the core functionality and when to apply it. It could mention default behavior of acrossFolders or return value, but it is largely complete for a moving 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?
With 75% schema description coverage, the schema already explains most parameters. The description adds minimal semantic value beyond the schema, such as how messageId identifies the thread and that acrossFolders searches additional folders. This is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action (move thread), the method (using RFC 5322 Message-ID), and distinguishes it from the sibling tool apply_thread_action which is preferred when a local threadId is available.
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 (when you have the raw Message-ID) and when to prefer the alternative (apply_thread_action with action 'move' when you have a local threadId from get_threads or get_actionable_threads).
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 discloses the primary side effect (writing to disk) and the return value (written file path). Annotations only include destructiveHint:false, so the description adds context about the side-effect nature. However, it does not clarify the relationship between saveTo and outputPath, which could confuse users about behavior. 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 three sentences, with the first sentence stating the core action, the second giving usage context, and the third pointing to an alternative. Every sentence is purposeful and there is 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?
The description covers the primary purpose and basic usage, and it differentiates from a key sibling. However, it lacks clarity on the two optional path parameters and does not describe the return format beyond 'written file path' (e.g., whether it includes size). The absence of an output schema makes these gaps more consequential.
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 descriptions cover 100% of parameters, but the descriptions of saveTo and outputPath are overlapping and ambiguous. The tool description does not clarify the distinction, leaving users uncertain which to use. This undermines parameter semantics despite high 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 identifies the tool's function as saving a single attachment to disk using attachmentId and returning the file path. It distinguishes from the sibling save_attachments by emphasizing 'single' and 'specific attachmentId'. This gives a specific verb, 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?
It explicitly states when to use this tool—when you have a specific attachmentId from list_attachments—and when to prefer save_attachments (for all/filtered attachments). This is a clear alternative-guiding statement.
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 provide destructiveHint=false, so the agent knows it's not destructive. The description adds no major behavioral context beyond the move semantics (e.g., it doesn't mention whether archival removes from the current folder, whether it's reversible, or permission needs). Since the annotation already covers the safety profile, a score of 3 is appropriate—adequate but with room for more behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the core action, the second gives usage context, and the remaining three sentences list alternatives. Every sentence adds value, with no redundancy or fluff. It is front-loaded and easy to scan.
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 parameter and no output schema, the description fully covers what the tool does, when to use it, and which alternatives to prefer. The annotation covers destructiveness, and the schema covers the parameter. No additional context is 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%, with the emailId parameter clearly documented as 'Composite email id in FOLDER::UID format, as returned by get_emails or search_emails.' The description does not add extra parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Move a single email to the standard Archive folder.' It specifies the verb (move), resource (email), destination (Archive folder), and scope (single). It also distinguishes itself from sibling tools by naming trash_email, move_email, and batch_email_action as alternatives, making it unmistakable.
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 when-to-use guidance: 'Use for messages that are resolved but worth keeping long-term.' It also gives clear exclusions and alternatives: 'Prefer trash_email when the message is no longer needed. Prefer move_email to route to a custom folder. Prefer batch_email_action for archiving multiple emails at once.' This fully addresses selection 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 only provide destructiveHint=false, leaving behavioral disclosure to the description. The description adds meaningful context: messages are inserted via IMAP APPEND, nothing is sent, and raw can corrupt or reject legacy 8-bit content, with rawBase64 as the safe alternative. It does not cover return values or duplicate-handling, but the disclosed behavior is substantial.
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?
Three sentences, each earning its place: purpose, use cases, and encoding caveat with parameter selection. The phrase 'inserts a message directly into the mailbox' is slightly redundant with 'IMAP APPEND', but it serves to emphasize the non-sending nature. The content is well front-loaded and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, use cases, behavioral nuance, and parameter selection; the schema fully documents each parameter. No output schema exists, but the description adequately prepares an agent for an import operation with encoding pitfalls. Minor omissions like return values or behavior when a target folder does not exist are acceptable given the tool's moderate 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 description coverage is 100%, so baseline 3 applies. The description adds real value by explaining the charset pitfall and explicitly recommending rawBase64 for non-UTF-8 content, reinforcing the schema's 'exactly one required' constraint. markAsRead and targetFolder are already fully covered by the schema, so no additional description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Import a raw RFC822 message (.eml content) into a folder via IMAP APPEND.' It states the mechanism, destination, and explicitly differentiates from sending ('Does not send anything'), which makes it distinct from send_email/draft siblings.
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?
Concrete use cases are given: 'restore a backed-up message or migrate mail from another provider's export.' It also provides parameter-level guidance, directing users to rawBase64 for non-UTF-8 content. It does not explicitly name sibling alternatives, but the 'Does not send anything' clause implicitly excludes send_email, so context is clear without fully explicit exclusions.
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 is consistent with a read-only operation (listing). The description adds valuable context about the specific IMAP folder source and the type of drafts (unsynced), which goes beyond the annotation's bare safety hint.
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: purpose, usage guidance, prerequisite. No redundant words. Information is front-loaded with the action and scope in the first sentence.
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 list tool with two parameters and no output schema, the description explains purpose and usage well, but does not mention what fields the returned draft messages contain (e.g., subject, id, date). Since there is no output schema, this omission leaves the agent slightly underinformed about the response structure.
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 (limit, offset) fully documented with descriptions and defaults. The description adds no further param details, but the schema already handles that adequately.
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 specifies the verb 'List', the resource 'draft messages', and a specific scope ('stored in the Proton Drafts IMAP folder on the server'). It also distinguishes from the sibling tool 'list_drafts' by contrasting local vs. server drafts, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('see drafts created via Proton webmail or mobile app that have not been synced locally') and when not to ('Prefer list_drafts to see drafts managed by this server'). It also notes a prerequisite ('Requires an active IMAP connection'), providing clear decision support.
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 include destructiveHint: false, which the description does not contradict. Beyond that, the description discloses a major behavioral trait: the wake is not reliable if the server stops, which is not inferable from annotations. However, it does not detail the cancellation mechanism's side effects (e.g., whether email wakes immediately), but given the explicit warning, it adds significant value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph with a strong imperative verb and correct placement of the critical warning. It avoids fluff and is concise, though the long warning sentence could be split for readability, but this does not detract from substance.
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 mutates an email's location and has a time-dependent behavior, the description fully covers the essential context: what happens on move, when it returns, the fragility of the timer, and the cancellation path. The lack of an output schema is acceptable as the description clarifies state changes, and the sibling tools like cancel_snooze are logically referenced. Minor omission: it does not state whether the original folder is restored exactly, but the operation is clear enough.
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 cover 100% of parameters, providing clear definitions for emailId and wakeAt. The description adds no extra parameter details beyond what the schema provides, such as example formats or constraints, but since the schema already covers them, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move an email out of sight into Folders/MCP-Snoozed') and the mechanism for returning it ('bring it back to its original folder at wakeAt'). It uses specific verbs and resources, and distinguishes itself from suffixed siblings like 'cancel_snooze' and 'list_snoozed'.
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 emphasizes the critical scheduling constraint ('wake only fires while this MCP server process stays running') and warns about the fallback behavior if the app closes. It also mentions cancellation via 'cancel_snooze', providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint: true, and the description adds context that actions are 'reversible' and supports dryRun for previewing impact. It also mentions scoping via unreadOnly and index refresh via syncBefore. This goes beyond the annotation without contradicting it.
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: purpose, usage, and alternative. Front-loaded with the essential description, no filler, 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 7-parameter tool with no output schema, the description covers the core action, use case, key scoping options, and alternative. It doesn't detail return values or failure mode, but the schema covers parameters and destructiveHint covers risk. Very solid overall.
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 high (86%) and all parameters have descriptions. The description reiterates dryRun, unreadOnly, and syncBefore but doesn't add new parameter-level meaning beyond what the schema already supplies. Minimally viable, not lacking but not additive.
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 ('Apply') and identifies the resource ('every message in a normalized thread'), immediately distinguishing it from single-message tools. It also names example actions ('archive or mark-read') and differentiates from batch_email_action by threadId vs emailIds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('Use when you want to act on a full thread identified by threadId') and when to prefer an alternative ('Prefer batch_email_action when you have explicit emailIds rather than a threadId'). This gives clear decision 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?
Despite minimal annotations (only destructiveHint: false), the description discloses key behaviors: returns canceled: false if already sent, and throws when PROTONMAIL_SEND_DELAY_SECONDS is 0. It doesn't mention the success return value, but it covers edge cases well.
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 concise sentences with no filler. The main action is front-loaded, and limitations are stated efficiently without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers the operation, edge cases, and error behavior. It lacks an explicit success return value, but the overall context is sufficiently complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter (id) with 100% coverage, and the description adds no additional parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel a send_email call that was queued', using a specific verb and resource. It also differentiates from sibling tools like cancel_snooze by referencing the PROTONMAIL_SEND_DELAY_SECONDS mechanism.
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 states when to use the tool (while the item is pending) and when not to use it (if delay is 0, it throws). It also clarifies the outcome if the item has already sent, giving clear usage 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 already declare readOnlyHint=true, indicating no side effects. The description adds transparency by stating it counts without fetching message data, confirming lightweight 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, extremely concise, front-loaded with key action and purpose. No unnecessary words or repetition.
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?
No output schema, but the description implies a count result. For a simple count tool, it adequately covers what the tool does and when to use it. Could explicitly state return value (number) but not critical.
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 all 15 parameters documented. The description does not add specific parameter meaning beyond schema descriptions, only stating 'live IMAP search criteria' broadly. 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 counts messages matching live IMAP search criteria, explicitly noting it does not fetch message data. It explains the purpose (preview count before running a search) and distinguishes from folders_stats.
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 says when to use (to preview how many results a search would return before running it) and when not to use (prefer folder_stats for simple unread/total count on one folder without filters), providing a clear 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 only provide destructiveHint=false, so the description carries most of the behavioral burden. It discloses key behaviors: the original message is quoted, attachments are preserved unless configured otherwise, no immediate send occurs, and a draftId is returned for later update or send. This goes well beyond the annotation while remaining accurate.
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 tight sentences with no filler. The primary action and key behavior are front-loaded, and the alternative and return value are each covered in one sentence, giving maximum signal per word.
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 10-parameter tool with no output schema and sparse annotations, the description covers the essential operational context: what the tool does, when to use it, the key alternative, and what it returns (draftId). It could mention the required recipient parameter or sync behavior, but those are already visible in the schema, so the description is sufficiently complete for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters, establishing a baseline of 3. The description adds some context—'quoted body' clarifies how body relates to the original message, and 'preserving its attachments' gives meaning to includeAttachments—but it does not substantially enrich the parameter docs overall.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create a forward draft'), a clear resource ('an existing email'), and core behaviors (pre-filling the original as quoted body, preserving attachments). It distinguishes this tool from forward_email by highlighting the staging-for-review purpose, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it: when you have an emailId and want to stage a forward before sending. It also names the alternative — 'Prefer forward_email to send immediately without saving' — giving a clear when-not-to-use condition.
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 destructiveHint: true, so the bar is lower. The description adds useful behavioral context by noting the action is immediate and without review, and states a permission requirement. It doesn't detail the confirmation prompt for irreversible sends, but that is already partially covered by the destructive hint.
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: function, usage trigger, and alternative/prerequisite. Information is front-loaded and 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 tool with 15 parameters, full schema documentation, and a destructive annotation, the description provides adequate context: what it does, when to use, what to prefer, and a key permission. It doesn't detail return values, but no output schema exists and the schema covers parameters thoroughly.
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 parameters are well documented there. The description adds minimal extra meaning by mentioning 'preserving original attachments' and 'optional note', but these are already reflected in schema parameters like includeAttachments and body/markdownBody. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'forward', the resource 'existing email', and key behaviors (preserving attachments, prepending optional note). It explicitly mentions the alternative create_forward_draft, distinguishing it from siblings.
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 ('when you have an emailId and want to re-route the message without review') and when to prefer an alternative ('Prefer create_forward_draft to stage a forward for review first'). Also mentions a prerequisite (PROTONMAIL_ALLOW_SEND).
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 useful behavioral context: the log is persistent, on-disk, spans sessions, and records write operations (sends, moves, deletes, drafts). It does not contradict the annotation. No mention of return format or ordering, but enough safety/behavior 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?
Three concise sentences: purpose, use case, and explicit alternative. Front-loaded and every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only listing tool with readOnlyHint annotation and pagination params in schema, the description covers purpose, scope, persistence, and sibling differentiation. It does not describe return fields, but the absence of an output schema is partially mitigated by the clear 'entries' language and usage 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 description coverage is 50%: only offset has a description. The tool description does not elaborate on limit/offset, but offset is self-documented in the schema and limit has a default. This is adequate but adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return recent entries from the persistent on-disk audit log of all write operations performed by this server.' It clearly distinguishes this from sibling tools by contrasting with get_logs for in-session debugging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: use for reviewing mutations across sessions, and explicitly says 'Prefer get_logs for debugging in-session behavior and transient connection errors.' This names an alternative and gives exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, setting the safety baseline. The description adds valuable behavioral context: the response includes a security block (dkim/spf/dmarc pass-fail, Proton's spam score/action, encryption metadata) for phishing triage. It also warns about not constructing the emailId manually. 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 tightly written sentences. The first states the action, the second gives usage context, and the third discloses the security block. Every sentence earns its place with zero redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters and no output schema, the description covers the key facets: the composite ID format, usage sequence, and the security block in the response. It could be more explicit about the full return structure (e.g., standard email fields), but 'full content' plus the detailed schema descriptions for preferHtml and showHeaders provide adequate 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 coverage is 100%, so the baseline is 3. The description enhances the emailId parameter by explaining the format 'FOLDER::UID' and reinforcing that it must come from a prior tool call. This adds meaning beyond the schema's terse 'Composite email id from previous tool output.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetch the full content of a single email using a composite emailId.' It also distinguishes itself from siblings by stating 'Use after get_emails or search_emails to read a specific message in full,' 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?
Explicitly states when to use: 'Use after get_emails or search_emails to read a specific message in full.' It also gives a critical usage caveat: 'always use the id returned by a prior tool call; do not construct it manually.' It does not explicitly mention alternatives like get_emails_by_ids, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that it provides a summarized view and avoids reading all messages, implying lightweight read operation. No contradictions. Additional detail about non-modification could be included but not required.
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 what it returns, second states usage context. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description sufficiently covers purpose, usage, and content. Could optionally specify that no pagination is needed but not required 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?
Schema already has 100% description coverage for the single parameter (threadId). The tool description does not add extra detail beyond the schema, meeting the baseline for high 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 it returns a summarized view of a single thread and lists specific components (inbound/outbound preview, attachments, recommended action). It differentiates from the sibling get_thread_by_id by indicating that tool provides full raw data.
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 recommends use for quick status checks without reading every message and directs to use get_thread_by_id for full raw data. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds that it returns stable attachmentIds, filenames, content types, and sizes, providing useful behavioral context beyond the annotation.
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 with no fluff, front-loaded with the tool's purpose. 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?
Description covers key aspects: what it returns, when to use, and alternatives. Lacks mention of pagination or limits, but given typical usage (few attachments per email) and full schema, it 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 100%, so parameters are fully described in the schema. Description does not add new meaning to parameters beyond the schema, meeting the baseline but not exceeding 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?
Description clearly states it lists attachments on a specific email, providing stable IDs, filenames, content types, and sizes. It distinguishes itself from sibling tools like get_attachment_content and save_attachment.
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 using this tool before get_attachment_content or save_attachment to discover attachments and get IDs, and suggests save_attachments for bulk download. Provides clear context and 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 only provide destructiveHint=false. The description adds that the tool sets the IMAP Seen flag, which is the core behavioral effect. It does not list any side effects or permissions, but for a simple flag-setting operation, this is adequate and does not contradict 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. The first sentence defines the purpose and behavior; the second provides usage guidance with an alternative. No wasted words, and 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?
For a simple tool with two parameters and no output schema, the description covers purpose, usage, and distinguishes from a key sibling. It lacks explicit error conditions or return value info, but these are less critical given the tool's simplicity and the presence of schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers emailId well, and the description reiterates that. For isRead, the description implies its role ('mark as read or unread') but does not explicitly state that true means read and false means unread, nor does it describe the default. Schema description coverage is 50%, and the description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Mark a single email as read or unread by setting the IMAP Seen flag.' It uses a specific verb ('mark') and resource ('email'), and distinguishes from batch tools by specifying it handles a single email and can toggle read state.
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 use case: 'Use for individual triage or to reset read state.' Also provides an alternative: 'Prefer batch_email_action... when updating multiple emails at once.' 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description carries the behavioral burden as annotations only include destructiveHint=false. It clarifies that the tool moves (not copies) a single email, and the get_folders advice implies the target must exist. 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?
Three sentences, all useful and front-loaded with the action. It includes usage guidance, alternatives, and a prerequisite without waste 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?
The tool is simple, no output schema, and the description covers what, when, and prerequisites. It could be more complete by noting the email is removed from the source folder, but the 'move' verb already implies this. Overall adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: emailId is well-described, targetFolder is not. The description adds semantic context by referring to 'specified mailbox folder' and 'target folder path', but does not fully define the expected format or examples for targetFolder. It partially compensates 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 'Move a single email to any specified mailbox folder' with a specific verb and resource. It distinguishes from sibling tools like archive_email, trash_email, and bulk_move by specifying single-email scope and custom folder targeting.
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 provides when to use: 'Use when routing a message to a custom folder.' It also names alternatives: 'Prefer archive_email to move to the standard Archive folder, or trash_email to move to Trash.' The prerequisite 'Use get_folders first to confirm the target folder path' adds clear 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?
Given the readOnlyHint annotation, the description adds meaningful behavior details: results are 'sorted by recency' and syncBefore 'Refresh the local mailbox index from IMAP'—a side effect not evident from the annotation. There is 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?
Three concise sentences, front-loaded with the core purpose. The first sentence states the action and scope, the second gives usage timing, and the third covers input requirements and output format. No redundant phrasing.
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 read-only prep tool, it covers input constraints, output sorting, and intended use. It lacks further detail on return thread structure or edge cases (e.g., no matches), but given no output schema exists, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds a key cross-parameter constraint ('Provide at least one of person or domain') that is not visible from individual schema entries, boosting the value beyond 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 'Fetch recent threads and communication history for a person or company domain to prepare for a meeting or call.' It identifies a specific action, resources, and purpose, and distinguishes itself from generic thread-fetching tools by focusing on meeting preparation.
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 'Use before a scheduled meeting' and provides input constraints ('Provide at least one of person or domain'). However, it does not name alternative tools or give explicit 'when not to use' guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (destructiveHint: false) by stating 'Existing messages are preserved in place.' It adds valuable behavioral context beyond annotations: 'Refreshes the local folder cache after the operation.' There is 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 consists of three sentences, all front-loaded with the core action. Each sentence conveys unique, essential information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation, preservation of messages, system folder warnings, and cache refresh. Given the lack of an output schema, it could optionally mention the return value (e.g., success status), but overall it is sufficiently complete for a rename/move 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% with clear descriptions for both parameters ('Existing folder path.', 'New folder path.'). The description adds no additional semantic value beyond what the schema provides, so the 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 action: 'Rename or move a mailbox folder to a new IMAP path.' The verb is specific, and the resource (mailbox folder) is unambiguous. It distinguishes this from sibling tools like delete_folder 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?
The description provides an explicit prohibition: 'Do NOT rename system folders (INBOX, Sent, Trash, Archive, Spam).' It also notes that existing messages are preserved. However, it does not mention when to use this tool vs alternatives like move_email or create_folder, which slightly reduces guidance comprehensiveness.
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 include destructiveHint=false, so the agent knows the tool is non-destructive. The description adds that it returns a list of written file paths. However, it doesn't disclose overwriting behavior or error conditions, but given the annotation coverage, the description is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by usage and distinction. Every sentence adds value with 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?
The description explains the core function, filters, return value, and when to use the sibling. It doesn't cover edge cases like error handling or file naming conventions, but for a batch download tool with good annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description reinforces the filter parameters but adds minimal new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (save), the resource (all qualifying attachments from an email), and the qualifying conditions (optional filters). It distinguishes itself from the sibling 'save_attachment' by indicating batch vs. single attachment retrieval.
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: 'Use to batch-download attachments from a single email.' It also provides an alternative: 'Prefer save_attachment when you need to save one specific attachment by its attachmentId.' This is clear 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?
The readOnlyHint annotation already indicates a safe read operation. The description adds behavioral context by mentioning 'live IMAP filters', 'optional local post-processing', and implicitly that Bridge IMAP availability is required (since the alternative works without it). This goes beyond the annotation, though it does not mention potential latency or result size implications.
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 deliver the core purpose and usage guidance without any filler. The first sentence states the function, and the second provides decision-making context. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 24 parameters and no output schema, the description covers the main purpose, when to use it, and the alternative. It does not explain return values or pagination, but the schema's 'fields' parameter and 'limit' parameter imply this. The description is adequate for a complex search tool, though a brief note on result structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description's mention of 'optional local post-processing for attachments and labels' conceptually groups parameters like label, threadId, and attachmentName, but the schema already notes 'applied locally' for those. Thus the description adds little beyond the schema's parameter 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 'searches emails via live IMAP filters with optional local post-processing for attachments and labels'. It distinguishes itself from the sibling search_indexed_emails by emphasizing real-time searching and local post-processing, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use when you need real-time results or must find messages received after the last sync.' It also names a specific alternative (search_indexed_emails) with clear conditions and benefits, stating it is 'significantly faster and works even when Bridge IMAP is unavailable.' This fully addresses when to use this tool 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?
The description adds behavioral context (uses IMAP Flagged flag, so it's a metadata change) beyond the destructiveHint annotation, which is false. It doesn't contradict annotations and gives enough detail for a simple flag toggle, though it doesn't mention idempotency or error 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, each earning its place: purpose, use case, and batch alternative. Front-loaded with the core action, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation with no output schema and minimal annotations, the description covers the essential purpose, use case, and alternative. It doesn't mention return values or error conditions, but these are less critical for such a straightforward 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 50% (emailId described, isStarred not). The description's 'Star or unstar' implies the isStarred parameter's purpose but doesn't explicitly map boolean values to actions. It adds some meaning but not enough to fully compensate for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Star or unstar a single email using the IMAP Flagged flag.' It clearly differentiates from siblings like batch_email_action (multiple emails) or mark_email_read (different flag).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear use case ('bookmark an important message for later follow-up') and explicitly directs users to batch_email_action when flagging multiple emails, giving both a when-to-use and an alternative.
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. The description adds valuable behavioral detail: keyed on sender address, not display name, to avoid spoofing. 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, no fluff, front-loaded with core purpose. 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?
The description covers purpose, key behavioral trait, and use cases. With good schema annotations, it is mostly complete, though it could optionally clarify the return format more explicitly.
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 additional parameter details beyond what the schema provides, but hints at folder and date range.
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 'Return a frequency table of the top senders' with specific verb and resource, and distinguishes from siblings by mentioning keying on sender address to avoid spoofing. Use cases are explicitly listed.
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 use cases (inbox analytics, unsubscribe triage, contact discovery), giving context. It does not explicitly mention when not to use or alternatives, but the sibling list implies differentiation.
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 indicate destructiveHint=false. The description adds meaningful behavioral context: it does not move the message, requires labels to exist under the Labels/ namespace, and is intended for single-message operations. This goes beyond the minimal annotation.
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, front-loaded with purpose, followed by usage guidance and a prerequisite. No wasted words, easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, alternatives, and prerequisites. With no output schema and minimal annotations, it provides sufficient context for a straightforward label modification tool, though it omits potential return values or error 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%, so the schema already documents all parameters with rich examples. The description reinforces the namespace convention but does not add significant new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: adding or removing Proton labels on a single message. It distinguishes itself from bulk_update_labels and indicates it does not move the message, making it specific to message label modification.
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 to use for one message at a time, directs users to bulk_update_labels for multiple messages, and instructs to create missing labels first with create_folder. Provides clear usage context and alternatives.
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 destructiveHint=false annotation by explaining the side effect (moving back to original folder) and the error behavior (throws if no longer snoozed). This is transparent about state changes and failure modes.
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 action, and includes necessary edge-case behavior in the second sentence. Every word adds value 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?
For a simple tool with one well-documented parameter and no output schema, the description fully covers what happens, when it throws, and the side effect. 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?
The input schema already provides 100% coverage for the single 'id' parameter, including a clear description ('The id returned by snooze_email'). The description does not add extra semantic detail, but none is needed because the schema is sufficient.
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 ('Wake') and resource ('snoozed email'), and clarifies the action ('moving it back to its original folder before wakeAt'). It clearly distinguishes from the sibling tool 'snooze_email' by being its inverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies when to use (when an email is currently snoozed and you want to wake it early) and provides an important boundary condition ('No effect (throws) if already woken or canceled'). However, it does not explicitly reference alternatives or mention that re-snoozing can be done with snooze_email.
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 include destructiveHint=false, so description carries the burden. It discloses local SQLite persistence, optional sync to the Proton Drafts IMAP folder, and the return of a draftId for later operations, adding meaningful context beyond the annotation.
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 storage, then usage, alternatives, and return value. Every sentence earns its place with no 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?
Despite having no output schema, the description explains the draftId return and the draft lifecycle (update, sync, send). With a rich input schema and clear alternatives, the description is complete enough for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 91%, so the schema handles most parameter meaning. The description adds context for sync behavior and return value but does not detail individual params; 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 and resource: 'Save a new outbound message as a local draft in SQLite', clearly distinguishing it from sibling tools. It also explicitly contrasts with create_reply_draft and create_forward_draft.
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 usage guidance: 'Use to compose and review before sending' and directs to specific alternatives for replying ('create_reply_draft') and forwarding ('create_forward_draft').
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 destructiveHint: false only. The description adds behavioral details: it creates a folder via IMAP, disallows system folders, and returns the created path on success. This adds context beyond the minimal annotation.
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 adding essential information: action, path conventions, prohibited folders, and return value. 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?
For a simple 1-parameter tool with no output schema and minimal annotations, the description covers the key aspects: what it does, how to use it, constraints, and expected outcome. No 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?
Schema coverage is 100%, so baseline is 3. The description adds value by providing concrete path examples ('Folders/Receipts', 'Labels/') and warning against system folders, which enhances understanding beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Create a new mailbox folder via IMAP.' It specifies the resource (mailbox folder) and distinguishes between user folders and labels using the 'Folders/' and 'Labels/' prefixes, which differentiates it from sibling tool 'create_label'.
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 when not to use the tool (system folders) and how to construct paths (using 'Folders/' and 'Labels/' prefixes). It implies usage context (for user-created folders and labels) but does not explicitly name alternative tools like 'create_label'.
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=false annotation, the description adds idempotency context, though it does not cover potential error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with clear, front-loaded information and zero wasted 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?
For a simple tool with one parameter and no output schema, the description adequately covers purpose, safety, and alternative, 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 schema already describes the parameter, and the tool description repeats the prefix behavior without adding new info. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Proton label under the Labels/ namespace, distinguishing it from create_folder which creates folders under Folders/. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 the sibling create_folder, and notes idempotency implying safe re-call.
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 declare destructiveHint=false. The description adds valuable behavioral context: pre-fills To/Subject/quoted body, stages reply for review (not sent), and returns a draftId. It stops short of explaining draft persistence or sync implications, but for a non-destructive draft tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no fluff. Purpose is front-loaded, followed by usage and return value. Every sentence contributes actionable information 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?
Despite 9 parameters, the schema fully documents them. The description covers what the tool does, when to use it, key alternatives, and return value (draftId). This is complete enough for an agent to select and invoke correctly without additional 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 covers all 9 parameters with individual descriptions (100% coverage), so description doesn't need to re-articulate each parameter. It does add context around emailId's role ('original message') and that the body is prepended, but this is not a major addition 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?
Clearly states the action: 'Create a reply draft for a specific email, pre-filling To, Subject, and quoted body from the original message.' Distinguishes from siblings by explicitly naming create_thread_reply_draft (threadId) and reply_to_email (send immediately), so the tool's unique role is evident.
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 usage conditions: 'Use when you have an emailId and want to stage the reply for review before sending' and gives direct alternative guidance: 'Prefer create_thread_reply_draft when you only have a threadId. Prefer reply_to_email to send immediately.' This is textbook when-to-use vs alternatives.
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 include destructiveHint=true, and description expands by explaining the permanent parameter behavior (permanently expunges vs. moves to Trash). Also notes the tool is destructive by deleting all messages in the thread.
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 covers purpose and parameter behavior, second provides usage guidance. No extraneous content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and key parameter (permanent), but does not address dryRun, confirmed, or acrossFolders. For a destructive tool with 5 parameters, this leaves gaps. No output schema exists, but return values are not explained.
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?
Schemas description coverage is only 20% (only messageId described). Description adds meaning for the permanent parameter but does not explain dryRun, confirmed, or acrossFolders. While some value is added, it does not fully compensate for the low 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?
Clearly states the tool deletes all messages in a thread using RFC 5322 Message-ID. Distinguishes from sibling tools like apply_thread_action by specifying when to use each.
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 (when you have raw Message-ID) and when to prefer apply_thread_action (when you have local threadId from get_threads or get_actionable_threads).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the live nature, the fact that no messages are fetched, and the speed/accuracy tradeoff of scanLimit. It does not explicitly mention read-only or side-effect-free behavior, but 'without fetching messages' strongly implies it. This adds meaningful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences: core function, use case, and explicit alternatives. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter input and lack of output schema, the description provides return value names, use cases, alternatives, and performance tradeoffs. It is complete for a lightweight read-only stats tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters completely, including defaults and the speed/accuracy tradeoff. The description adds no new parameter-level detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live message count, unseen count, uidNext, and uidValidity for a single mailbox folder. It distinguishes itself from sibling tools by specifying it does so without fetching messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool (checking unread counts or folder health) and provides alternatives: count_messages for filtered queries and get_email_stats for aggregate summaries. This is strong when/when-not 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 already declare readOnlyHint=true, so the description carries a lower burden. It adds value by describing the output structure (unread counts, actionable/overdue threads) and mentions the syncBefore parameter behavior, supplementing annotations with 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?
Two sentences, no wasted words. First sentence describes what the tool returns, second gives usage guidance. Efficient 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?
Despite no output schema, the description adequately explains the return value (unread counts, top actionable threads, overdue threads) and the syncBefore parameter behavior. For a summary tool with three parameters, this is complete and 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 description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides; it focuses on the tool's purpose and output.
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 returns a structured inbox summary with unread counts, top actionable threads, and overdue threads. It distinguishes itself from the sibling tool get_actionable_threads by positioning itself as the starting point for an inbox review.
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 provides usage guidance: 'Use as the starting point for an inbox review session' and recommends get_actionable_threads for deeper filtering, giving clear context for when to use this tool 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?
The readOnlyHint annotation already marks it as read-only, and the description adds important context: logs are ephemeral and not persisted across restarts. This is valuable beyond the annotation, though it does not cover details like log rotation or memory limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the main purpose, then the usage context, then a caveat and alternative. Every sentence earns its place with no filler.
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 tool with no required parameters and no output schema, the description covers purpose, when to use it, the ephemeral nature of logs, and directs users to the persistent alternative. This is fully 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 low (only offset has a description, level has an enum, limit just has a default). The description repeats the level enum values but provides no additional meaning for limit or offset, leaving a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Return recent in-memory server log entries,' which is a specific verb+resource construction. It also explicitly distinguishes itself from get_audit_logs, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use the tool ('Use to diagnose unexpected tool behavior or connection errors during the current session') and explicitly names an alternative for persistent logs ('use get_audit_logs').
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 readOnlyHint annotation already signals a safe read, and the description adds meaningful behavioral context: it reads from the local index, auto-refreshes if stale or empty, and does not hit live IMAP, so results reflect the last sync. This goes beyond the annotation and helps set expectations about data freshness.
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 filler: purpose first, then use cases, then data-source caveat and alternative. Every sentence earns its place and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with no output schema, the description is complete: it states the return value (daily inbound/outbound counts), the trailing-window scope, when to use it, and the data-source behavior. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'days' is fully documented in the schema with a default and description. The tool description does not add extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return daily inbound and outbound message counts for a trailing window.' It clearly states what the tool does and differentiates it from the sibling get_email_analytics by noting that tool handles sender-level breakdowns and hourly patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are provided: 'spot volume spikes, identify quiet periods, or track communication trends over time.' It also gives an explicit alternative: 'Prefer get_email_analytics for sender-level breakdowns and hourly patterns,' which tells the agent 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds the specific behavioral constraint that it only lists locally saved drafts and not server drafts, which is useful beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The main action is front-loaded, and the description efficiently uses words to convey scope and alternatives.
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 boolean parameter, read-only annotation, no output schema), the description covers all necessary aspects: purpose, returned fields, scope, usage guidelines, and alternatives. It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (includeSent) is fully described in the schema with 100% coverage. The tool description does not add any additional meaning about this parameter, 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 specifies the verb 'list', the resource 'locally saved drafts', and the fields returned (status, subject, timestamps). It also distinguishes from sibling tools like list_remote_drafts and get_draft, 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?
Explicit instructions on when to use ('review in-progress or unsent messages'), when not to use (for server-only drafts), and which alternative to use (list_remote_drafts, get_draft) are provided.
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 annotation destructiveHint: false already covers non-destructiveness. The description adds valuable context by explaining that messages retain the label under the new name, which clarifies the actual behavioral effect of the rename. It doesn't discuss permissions or edge cases, but for a simple rename this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the purpose and effect, the second gives the alternative tool. Every word earns its place, and critical information is 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 rename operation with two self-describing parameters and a non-destructive annotation, the description covers all essential context: the action, the namespace, the effect on messages, and the alternative for folders. No output schema is present, and none is 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 descriptions for 'name' and 'newName' fully document both parameters, including the automatic handling of the Labels/ prefix. The description adds no additional parameter-level detail beyond referencing the namespace, so a baseline score of 3 is appropriate 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 clearly states the action ('Rename'), the resource ('a Proton label'), and adds specificity by noting it's an IMAP folder under the Labels/ namespace. It explicitly distinguishes from folder renaming by referencing rename_folder, 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?
Provides explicit guidance on when to use this tool versus an alternative: 'For renaming a folder use rename_folder with a Folders/ prefix.' This directly addresses usage boundaries and steers users away from misusing the tool.
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 include destructiveHint: true, and the description adds context by noting threading headers are preserved and that PROTONMAIL_ALLOW_SEND is required. It clearly conveys the immediate sending behavior beyond what the annotation states.
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 every sentence adding value: purpose, relationship to sibling, when to use, behavior (threading), and a prerequisite. It is front-loaded with the primary action.
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 (13 params, destructive action, no output schema), the description covers the core purpose, usage context, key behavioral traits, and required permissions. It is sufficient for an agent to correctly select and 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% for all 13 parameters, so the schema already documents each parameter. The description does not add additional meaning beyond what the schema provides, placing it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a reply to all original recipients (sender + all To/CC addresses) of an existing email. It distinguishes itself from the sibling reply_to_email by explicitly noting it is identical to reply_to_email with replyAll enabled, making the scope 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?
It provides explicit usage guidance: 'Use when the conversation involves multiple parties and all should receive the reply.' This directly tells the agent when to choose this tool over alternatives like reply_to_email or forward_email.
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 destructiveHint=true, and the description aligns by emphasizing 'immediately send.' It adds valuable context not in annotations: the correct threading behavior via In-Reply-To/References headers and the PROTONMAIL_ALLOW_SEND requirement. It doesn't explicitly warn about irreversibility, but the annotation covers the destructive 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?
Four sentences total, front-loaded with the core action, then providing usage alternatives and a prerequisite. No filler or repetition of schema details.
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 high-complexity, destructive send tool with no output schema, the description covers core purpose, when to use vs alternatives, required permission, and threading behavior. It misses minor details like dryRun behavior, but these are sufficiently documented in the schema. The description is complete enough for an 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?
Schema coverage is 100%, so the schema already documents all 14 parameters with descriptions. The description adds no parameter-specific semantics beyond referencing emailId and the general send action. It does mention the auth requirement, which is not tied to a parameter, 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's function: 'Immediately send a reply to an existing email, threading it correctly via In-Reply-To and References headers.' It distinguishes itself from sibling tools by naming alternatives like create_reply_draft and reply_all_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use when you have an emailId and want to send the reply right away.' It also gives when-not-to-use alternatives: 'Prefer create_reply_draft to save the reply for review first, or create_thread_reply_draft when replying from a threadId. Use reply_all_email to reply to all original recipients.'
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 important behavioral trait: only works on messages currently in Trash, not on permanently deleted ones. No contradiction with annotations (destructiveHint: false). Adds 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 concise sentences that front-load the main action and usage guideline. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes the tool's purpose, usage context, and limitations. Given the simple parameters and absence of output schema, no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are clear, including the default for targetFolder. The description does not add additional meaning 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?
Clearly states 'Move an email from Trash back to INBOX or to a specified folder', specifying verb and resource. Distinguishes from sibling 'trash_email' and 'delete_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?
Explicitly recommends using this tool to undo a trash_email operation and states it does not work on permanently deleted messages. Would benefit from mentioning when to use alternatives like 'delete_email'.
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 context beyond the destructiveHint annotation by explaining the tool returns 'transport debug info and delivery status' and that it is a minimal diagnostic email. While the annotation flags destructive behavior, the description discloses the side-effectful action (sending an email) without contradicting the annotation.
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, front-loaded with a clear action and purpose, followed by usage guidance and return info. 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?
The description covers the tool's purpose, when to use it, alternatives, and return value. Given the simple 2-parameter schema and no output schema, this 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 coverage is 100%, with both parameters (to, customMessage) described in the schema. The description does not add additional semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Send' and identifies the resource ('a minimal diagnostic email') and purpose ('confirm Proton Bridge SMTP credentials and connectivity'). It also distinguishes from siblings by mentioning send_email and get_connection_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use before relying on send_email in a new environment' and 'Prefer get_connection_status for a connectivity check that does not actually send mail.' This clearly indicates when to use this tool and when to use an 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 set destructiveHint=false, and description adds that messages can be recovered via restore_email, providing useful behavioral context beyond the annotation.
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, front-loaded sentences with no wasted words. 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 simple single-parameter tool with a clear purpose and usage guidelines, the description is complete and 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% with adequate parameter description. The description does not add extra semantic detail beyond the schema, so 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 action 'Move a single email to the Trash folder' and distinguishes it from delete_email by noting recoverability. It also references batch_email_action for multiple 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?
Explicitly provides when to use this tool vs delete_email and recommends batch_email_action for multiple emails, giving clear 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?
The description adds valuable behavioral context: the tool verifies the server applied the flags and returns 'notApplied[]' for silently dropped flags. Annotations only provide destructiveHint=false, so this extra transparency about verification and partial-application behavior is meaningful, though more detail on side effects could be included.
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 (three sentences) and front-loaded with the core action and verification behavior. It then provides usage guidance and alternatives without unnecessary detail. 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?
For a tool with moderate complexity, the description covers purpose, usage context, alternatives, and return behavior (notApplied[]). No output schema exists, so the description's mention of the returned notApplied list fills the gap. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 already described in the input schema. The description adds minimal new parameter semantics beyond mentioning 'arbitrary IMAP flags' and giving an example, which aligns with schema examples. Baseline 3 is appropriate since the schema 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?
The description clearly states the tool's function: 'Add or remove arbitrary IMAP flags on a single message, then verify the server applied them.' It distinguishes itself from siblings by explicitly mentioning mark_email_read / star_email as alternatives for common flags and bulk_update_flags for multi-message updates.
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 usage guidance: 'Use for custom IMAP flags (e.g. \Answered) or when mark_email_read / star_email don't cover the flag you need' and 'Prefer bulk_update_flags to update flags across multiple messages at once.' This tells the agent when to choose this tool over 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?
Disclosures include operations in one IMAP pass, dryRun support, and max batch limit. The annotation destructiveHint: false is consistent. No contradictions noted, but could mention that moves are reversible or if permissions required.
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 with no redundancy. Key information is front-loaded: purpose, usage, and differentiation.
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 essential aspects: method of selection (IDs or criteria), dryRun, batch size limit. Missing details on return value or error handling, but acceptable without output schema.
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 XOR relationship between emailIds and match, and that folder is required when using match. This context 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 clearly states the action (move multiple emails), resource (emails in one IMAP pass), and explicitly differentiates from the sibling tool move_email for single-message moves.
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: when to use (bulk moves), when not to use (single-message use move_email), and how to use (XOR between emailIds and match criteria, dryRun preview, max batch size).
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 provide destructiveHint: false. The description adds valuable behavioral context: it discloses that the operation modifies flags, and importantly reveals the return behavior 'Returns notApplied[] per message for flags the server silently dropped.' This goes beyond the sparse annotation, though it does not mention potential side effects like runaway operations (covered in schema) or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each purposeful: purpose, usage, input constraints, and alternative. It is front-loaded with the main action and provides critical details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, nested match object, no output schema), the description covers essential context: batch operation, XOR input modes, return behavior, and when to prefer the single-message alternative. It does not address edge cases like empty flag arrays or conflicting flagsToAdd/Remove, but it provides a solid operational picture.
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 high (86%), so baseline is 3. The description adds key parameter semantics beyond the schema, notably the XOR relationship: 'Accepts emailIds[] OR match+folder (XOR).' It also clarifies flag format with an example. This adds meaning that is not obvious from individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add or remove IMAP flags on multiple messages simultaneously.' It specifies the resource (IMAP flags) and the scope (multiple messages), and distinguishes itself from sibling tools like update_message_flags by emphasizing batch operations and the XOR input mode.
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 gives explicit usage context: 'Use when the same flag change... should apply to several messages' and provides an explicit alternative: 'Prefer update_message_flags for a single message when you need per-flag server verification.' This clearly guides tool selection.
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 include readOnlyHint: true, and the description adds significant context: 'Reads from the local index (auto-refreshed if stale or empty), not live IMAP — reflects the last sync.' This explains data source and staleness, going beyond the annotation to clarify behavioral nuances. 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 (five sentences) and front-loaded with the core purpose. Each sentence adds value: output definition, use cases, alternatives, and data source/behavior. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 2 parameters (both documented), no output schema, and clear output description (top senders, busiest hours, volume by folder). The description explains what it returns and its data source, making it fairly complete. Minor gap: it does not specify sampling behavior details or formatting, but that is not critical for an analytics summary 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%—both 'days' and 'limit' have descriptions in the schema. The description does not explicitly explain these parameters, but since the schema already provides meaning, a baseline score of 3 is appropriate. No additional semantic value is added beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate sampled mailbox analytics including top senders, busiest hours of day, and volume breakdown by folder.' It specifies the resource (mailbox analytics) and the exact outputs, and distinguishes from sibling tools by naming alternatives (get_email_stats, get_volume_trends).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use for productivity insights and communication pattern analysis' and directs away from alternatives: 'Prefer get_email_stats for a fast aggregate count summary. Prefer get_volume_trends for per-day message volume history.' This clearly tells 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark the tool as readOnlyHint=true, so the description does not need to reiterate safety. It adds value by explaining the selection criteria (age and pending-on state) and the syncBefore parameter refreshes the index. 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 two concise sentences that front-load the purpose and usage guidance. Every sentence is necessary and informative, 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 tool has 4 optional parameters, no output schema, and annotations indicating a read-only operation, the description covers core functionality and usage context well. It lacks details on output format, but for a filter-and-list tool this is acceptable. The description is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds extra context for 'syncBefore' ('Refresh the local mailbox index from IMAP') and 'pendingOn' enum values, enhancing understanding beyond the schema. Baseline 3 plus additional value yields a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns threads overdue for follow-up based on age and pending-on state. It uses specific verbs and distinguishes itself from the sibling 'get_actionable_threads', 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: 'looking for outbound messages you sent that haven't received a reply, or to surface stale inbound threads.' Also provides a clear alternative: 'Prefer get_actionable_threads for threads where someone is currently waiting on you.' This gives excellent guidance on tool selection.
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 the safety profile is covered. The description adds context by stating it makes no IMAP connection and relies on a local index, which implies potential staleness. It also introduces inline field shortcuts, but does not detail behavior when the index is empty or result ordering, though this is a minor gap given the annotation coverage.
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 (about four sentences), front-loaded with the core purpose, and each sentence adds essential guidance. It avoids redundancy with schema and annotations, making every line valuable.
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 17 parameters and no output schema, the description does a good job explaining the tool's niche (offline index search versus live IMAP) and usage conditions. It does not describe return format or pagination beyond the limit parameter, but the schema covers parameters, and the key contextual distinction from siblings is thoroughly addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining field shortcut syntax directly (from:alice@example.com, to:bob, subject:invoice, label:Archive, domain:acme.com), which enriches understanding of how the query parameter can be used alongside structured filters, beyond what schema parameter descriptions individually provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search the local SQLite mailbox index without making any IMAP connection.' It specifies the resource (local SQLite index) and distinguishes from sibling search_emails by highlighting offline capability versus live IMAP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Prefer search_emails when you need live IMAP results or when the index is stale or empty. Prefer this over search_emails when the index is current. Use search_emails if messages were received after the last sync.' This clearly communicates when to use this tool versus the alternative.
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 destructiveHint=true, the description discloses the implementation via Proton Bridge SMTP, the conditional throw-and-return-link behavior, and the safety rationale for not auto-fetching URLs. This adds meaningful behavioral context that annotations alone do not 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 is three sentences, front-loaded with the primary action, followed by edge case behavior and a prerequisite. No redundant or vague wording; 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 tool with a simple schema and no output schema, the description covers the main behavior, edge case, and prerequisite. It does not specify the success return value, but this is a minor gap given the clarity of the action and the existence of related tools.
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 emailId described as from previous tool output and confirmed for confirmation. The description adds no additional parameter meaning beyond reinforcing that emailId comes from get_unsubscribe_info output, which is already in the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: executing the mailto: variant of a List-Unsubscribe header by sending a minimal unsubscribe email through Proton Bridge SMTP. It distinguishes from siblings like get_unsubscribe_info (which checks availability) and send_email (general send), and specifically mentions the https-only fallback behavior.
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 the tool (when header includes a mailto address) and when it throws (if only an https link), and instructs to call get_unsubscribe_info first. It also explains the server's policy of never auto-fetching URLs, guiding the agent to open https links manually instead.
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 the 'destructiveHint' annotation, the description adds that the deletion is permanent and irreversible, and clarifies it only affects local SQLite storage, not the IMAP folder. This gives full behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each serving a distinct purpose: stating the action, recommending usage, and clarifying limitations. 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?
The description covers all necessary aspects: what it does, when to use, what it doesn't do, and irreversibility. With a single parameter fully documented, no output schema needed, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, draftId, is fully described in the schema with examples of where it comes from. The description does not add further parameter details, but schema coverage is 100%, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete a locally saved draft from SQLite,' specifying the action, resource, and context. It distinguishes itself from sibling tools like delete_thread and trash_email by focusing on local drafts and noting it does not affect the IMAP folder.
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 advises when to use ('Use to discard a draft you no longer need') and when not to use ('Does NOT remove a matching draft from the Proton Drafts IMAP folder — that requires a separate mailbox action'), providing clear guidance.
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 the destructiveHint annotation, the description adds critical behavioral context: 'Permanently delete', 'Irreversible', and 'via IMAP expunge' reveal the actual deletion mechanism. This clearly signals that the action cannot be undone, going beyond the annotation's generic destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: the first sentence states the core purpose, followed by tightly worded usage guidelines and the final 'Irreversible' warning. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 params, no output schema), the description covers purpose, usage timing, alternatives, and irreversibility. Combined with the complete schema, the agent has all necessary context 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?
The input schema fully documents both parameters with detailed descriptions, including the composite format for emailId and the confirmation requirement for confirmed. The tool description adds no additional parameter-specific meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('delete'), resource ('a single email'), and method ('via IMAP expunge'). It distinguishes itself from sibling tools by explicitly naming alternatives like trash_email, bulk_delete, and delete_thread.
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 on when to use this tool: 'Use only when certain the message is no longer needed' and directly recommends alternatives: 'Prefer trash_email if recovery may be required', 'Prefer bulk_delete to delete multiple emails at once', and 'Prefer delete_thread to delete all messages in a conversation.'
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 the destructiveHint annotation, the description adds important behavioral context: the operation is irreversible, limited to IMAP, and requires an empty folder. It also explicitly forbids system folders. This directly enhances transparency and aligns with the destructiveHint true flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: three sentences, each adding necessary information. The main action is front-loaded, and there is no filler or repetition of schema details.
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 destructive folder deletion tool, the description covers all essential context: prerequisites (empty folder), restrictions (system folders), and consequences (irreversible). Combined with the schema's parameter descriptions and the destructiveHint annotation, the tool is fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both 'path' and 'confirmed'. The description does not add further detail about parameter semantics, so the baseline of 3 is appropriate given the 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 verb and resource: 'Delete an empty mailbox folder via IMAP'. It distinguishes from siblings like create_folder, rename_folder, and empty_folder by specifying the empty-folder requirement and the IMAP context.
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 states when to use the tool ('The folder must contain no messages') and when not to use it ('Do NOT delete system folders'). It also provides actionable prerequisites ('move or trash all messages first'), which serves as clear usage guidance.
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 the destructiveHint annotation, the description discloses that the operation is irreversible, that messages are not deleted, and that the label is an IMAP folder under Labels/. This adds critical behavioral context that annotations do not 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?
Three concise sentences, each providing essential information: what it does, the side effects on messages, and the alternative tool. No redundant wording, front-loaded with the primary action.
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 (2 params, no output schema), the description covers the key aspects: the operation, irreversibility, message preservation, and alternative for folders. It is complete for an agent to safely use and select this 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 input schema already covers both parameters with descriptions (name and confirmed), so the description does not need to add parameter details. The description mentions the Labels/ prefix handling, which is already in the schema. Baseline of 3 is appropriate at 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 clearly states the tool deletes a Proton label, specifying the exact resource and scope (Labels/ namespace). It also distinguishes itself from the sibling delete_folder by explicitly contrasting the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool versus the alternative: 'For deleting a folder use delete_folder with a Folders/ prefix.' It also clarifies that the label itself is deleted, not the messages, which helps the agent choose correctly.
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 only declare readOnlyHint=true. The description adds substantial behavioral context: supported MIME types, HTML stripping, calendar summarization, a 512KB raw-content limit, and clear failure for non-text formats. This goes well beyond what annotations provide and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by highly relevant details about size limits, format compatibility, and alternatives. Every sentence contributes meaningful information 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?
The tool has no output schema, but the description fully covers what it does, supported formats, limits, and failure modes. It also references sibling tools for fallback, making it self-sufficient for an 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?
Schema description coverage is 100%; both emailId and attachmentId are already described with formats and sources. The description adds no further parameter-specific details, so the baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Extract plain text from a text-like attachment' with a specific verb and resource. It further distinguishes itself from get_attachment_content by mentioning the base64 handling and size-limit differences, making its unique role clear.
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 when-to-use guidance: use for text-like attachments, when avoiding base64 encoding, and when the attachment exceeds the inline-base64 size limit. It also names alternatives (get_attachment_content or save_attachment) for non-text formats, and states the 512KB bound.
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 readOnlyHint=true, but the description adds critical context: the tool only fetches locally saved drafts, not from the Proton server. 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 adding essential information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only fetch tool with one parameter, the description fully covers purpose, usage context, and behavioral boundaries.
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 sole parameter draftId is described in the schema with 100% coverage; the description adds minimal extra value beyond listing sources, but overall it is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'full content of a single locally saved draft', distinguishing it from sibling tools like list_drafts (which discover IDs) and list_remote_drafts (server drafts).
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 (read/verify before sending/updating), recommends prior use of list_drafts, and directly contrasts with list_remote_drafts for server drafts.
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?
Even though readOnlyHint is already present, the description adds meaningful behavioral context: it mentions 'live IMAP' (network-based, fresh data), default sort order and reversal, and a security warning about prompt-injection in snippets. This goes well beyond the annotation.
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 the core action, then usage guidance, then alternatives. No wasted words; every sentence carries operational 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 7 parameters and rich sibling set, the description covers purpose, default behavior, pagination context, alternative tools, and a safety warning. It is fully sufficient for an agent to select and invoke this tool despite the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed parameter descriptions, including sortByUid and includeSnippet warnings. The describe text repeats some schema info (e.g., sortByUid asc/desc) but does not add new parameter semantics 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 starts with 'Fetch emails from a mailbox folder via live IMAP', using a specific verb and resource, and distinguishes itself from siblings like search_emails and search_indexed_emails by emphasizing 'live IMAP' and default sorting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'Use to browse or paginate recent messages in a specific folder', and provides named alternatives: 'Prefer search_emails to filter by sender, subject, or date. Prefer search_indexed_emails for fast repeated queries...' This is model guideline clarity.
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 the readOnlyHint annotation, the description discloses important behavioral traits: it reads from the local index rather than live IMAP, auto-refreshes if stale or empty, and may lag behind changes made in another client. It also explains the specific lag condition for unread counts, adding substantial 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 front-loaded with the core purpose, then gives usage guidance, then adds necessary caveats about data freshness. Every sentence earns its place; there is no redundant filler or repetition of schema 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?
For a read-only tool with two optional parameters and no output schema, the description is complete: it explains what is returned, when to use it, what alternatives exist, and the data-source caveats that affect interpretation. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters with 100% coverage: 'days' as 'Trailing days window' and 'limit' as 'Maximum messages to sample.' The description does not add parameter-level meaning beyond this, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return aggregate mailbox statistics: folder message counts, total unread counts, and a brief analytics sample.' It clearly distinguishes itself from sibling tools by explicitly naming get_email_analytics and get_volume_trends as richer alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to use this tool ('Use for a quick mailbox health overview') and explicitly directs users to alternatives: 'Prefer get_email_analytics for richer breakdowns... Prefer get_volume_trends for time-series daily volume data.' This is exemplary usage 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 already declare readOnlyHint=true, so the description doesn't need to reinforce that. It adds valuable behavioral context: returns message and unseen counts, from live IMAP session, and warns about noselect folders. Could mention if data is cached, but 'live' implies fresh.
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 with no extraneous information. Efficiently covers purpose, usage, and caveat.
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 no parameters and no output schema, the description fully explains the tool's return value, use cases, and relevant constraint (noselect folders). Sufficient for agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; schema coverage is 100% trivially. Description does not need to add param info. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return all mailbox folders with message counts and unseen counts from the live IMAP session.' It specifies the verb (return), resource (mailbox folders), and output details (counts). It also distinguishes from sibling tools like sync_folders and folder_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use to discover available folder names before targeting get_emails, move_email, or create_folder. Prefer sync_folders to force a fresh fetch when the folder list appears stale.' Provides clear when-to-use and alternative tool.
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 annotation readOnlyHint=true already communicates the read-only nature. The description adds useful behavioral context about what metadata is returned and the condition for using sync_emails first. It does not disclose potential error conditions or exact output format, but for a simple read-only metadata tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, tightly structured, and front-loaded with the key output. Every sentence adds value: what it returns, when to use it, and what to do in a specific condition. No wasted 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?
For a zero-parameter, read-only tool with no output schema, the description is complete. It covers the tool's function, provides usage context, and includes conditional logic for handling an empty or stale index. The context signals confirm its simplicity, and the description fully compensates for the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage by default). The description doesn't need to explain parameters, and the baseline for zero-parameter tools is 4. It adds value by describing the returned metadata fields, which is more relevant than parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning metadata about the local SQLite email index, listing specific fields (row count, last sync timestamp, schema version, per-folder coverage). It distinguishes itself from sibling tools like search_indexed_emails and sync_emails by positioning itself as a pre-query verification step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: use to verify index freshness before querying with search_indexed_emails or get_threads, and call sync_emails first if the index is empty or stale. This clearly articulates when to use it and how it relates to alternatives.
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; description adds that it uses local index (potential staleness) and includes message counts, with a limit cap. 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 front-loading purpose, usage, and alternative. No wasted 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?
For a simple read-only tool with one parameter and no output schema, the description fully covers purpose, behavior, and usage 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 covers 100% of the single parameter limit, including cap and alternative suggestion. Description doesn't add new parameter info 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?
Clearly states it returns normalized Proton folders/labels from local index with counts. Explicitly distinguishes from get_folders for live counts.
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?
Directs when to use: before filtering with search_indexed_emails or get_threads. Warns to prefer get_folders for live counts when index may be stale.
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 the description doesn't need to restate safety. However, it adds valuable context: the data comes from a 'local index' (implying cached or indexed state) and describes the return content in detail. This adds behavioral insight beyond the annotation.
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 states the action and scope, second provides usage guidance. No fluff, front-loaded, every sentence serves a 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?
Despite lacking an output schema, the description fully explains what is returned (all messages, participants, labels, full metadata) and gives clear usage context. For a fetch tool with read-only annotations, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters documented), so baseline is 3. The description adds subtle value by specifying that 'threadId' comes from 'get_threads' (source context) and that 'folders' can scope the search. This enriches 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 states 'Fetch the complete normalized thread record from the local index' with specific resource and scope, and distinguishes from sibling 'get_thread_brief' by noting the alternative returns a summarized view. This provides clear purpose and 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?
Explicit guidance: 'Use when you need all messages in a thread. Prefer get_thread_brief for a summarized quick view that avoids returning the full message list.' This gives clear when-to-use and when-not-to-use, with a named 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 indicate readOnlyHint=true, and the description adds useful behavioral context: grouping by subject/participants, reliance on 'the local mailbox index', and the limitation that only subject and participants are searched. There is no contradiction with annotations, and the added detail goes beyond the basic safety hint.
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-loaded with the primary purpose, and each sentence provides distinct, non-redundant information: the core function, the general usage context, and alternative tool recommendations. It is concise and well structured.
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 moderate complexity, read-only annotation, and the presence of siblings, the description covers purpose, field scope, usage alternatives, and prioritization guidance. No output schema exists, but the description sufficiently equips an agent to invoke the tool correctly without further clues.
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?
All parameters have schema descriptions, so the baseline is 3. The description adds meaningful semantic context by clarifying that body content is not searched, which supplements the query parameter description and helps agents avoid misusing the tool.
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'), a clear resource ('normalized email threads'), and explains the grouping behavior ('by subject and participants'). It effectively distinguishes the tool from siblings by explicitly naming search_indexed_emails, get_actionable_threads, and get_inbox_digest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use the tool ('Use to view mail as threads rather than individual messages'), when to use alternatives ('use search_indexed_emails to search body content'), and when to prefer two specific siblings for other needs (urgency, executive summary). This is explicit usage guidance.
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 the readOnlyHint annotation, the description adds key behavioral context: it 'does not take any action' and the server 'never auto-fetches unsubscribe URLs.' This tells the agent exactly what side effects to expect and prevents overreach. 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 two sentences, front-loaded with the primary action, and every clause earns its place. There is no fluff or repetition of schema details, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 tool with one required parameter and no output schema, the description fully covers the return value possibilities (mailto, https, or both), the non-mutating behavior, and usage scenarios. It gives the agent everything needed 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?
The input schema fully describes the only parameter, emailId, as a composite id from previous tool output. The description does not add extra semantic detail about the parameter, so it relies entirely on the schema. Per the rubric, with 100% schema coverage, a 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's function: reading the List-Unsubscribe header and reporting how to unsubscribe (mailto, https, or both). It uses a specific verb ('Read') and names the resource, and it distinguishes this from the sibling tool 'unsubscribe_sender' by explicitly noting it takes no action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: use before 'unsubscribe_sender' to see available options, or to pass an https link to the user/agent for manual opening. It also mentions the server never auto-fetches URLs, which clarifies when this tool is appropriate. This is a model of clear when-to-use advice.
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 the readOnlyHint annotation, the description discloses a critical behavior: unfilled placeholders remain literal and are listed in missingVariables. It also warns about the risk of sending literal {{placeholder}} text, which is valuable operational knowledge. This adds significant context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the main action front-loaded. Every sentence earns its place, providing both the core functionality and a critical warning 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 there is no output schema, the description effectively communicates what to expect (rendered subject/body plus missingVariables). It also references the downstream send_email tool, placing this tool in the broader workflow. Despite lacking output schema, the description provides enough information for an agent to use it 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 schema already covers both parameters fully, so the baseline is 3. The description adds meaning to the variables parameter by explaining what happens when a placeholder is not provided (it stays literal and appears in missingVariables). This enriches the semantics beyond the schema's simple 'Map of variable name to replacement value'.
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 'render' and names the resource 'saved template's subject and body'. It clearly explains the substitution behavior and distinguishes this from simply retrieving a template (e.g., get_template). The resulting output is tied to a concrete use case (preparing content for send_email), which further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: before passing rendered content to send_email. It warns about the consequence of unfilled placeholders, which guides the agent to check missingVariables. However, it does not explicitly name alternative tools or state when not to use it, so a small gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that sync trigger is immediate, returns status, and dependency on auto sync setting. No contradiction with destructiveHint=false. Could mention if call is blocking but still clear.
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 adding value: action, usage guidance, and alternative.
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 zero-parameter tool with no output schema, the description fully covers purpose, usage conditions, and behavior.
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?
No parameters; schema coverage is 100%. Description adds context about return of updated status beyond 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 'trigger' with resource 'configured background mailbox sync cycle outside its normal schedule', clearly distinguishing from siblings like sync_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?
Explicitly states when to use ('when index may be stale'), when not ('does nothing useful if auto sync disabled'), and recommends alternative (sync_emails).
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 provide readOnlyHint=true, and the description reinforces this by framing the operation as a health check rather than a mutation. Beyond the annotation, it adds valuable behavioral detail: connection failures include classified diagnoses (authentication_failed vs bridge_unreachable) with fixes, the tool reports version and entrypoint path, and it warns that other health fields can remain healthy even when an orphaned install shadows an upgrade. This is substantial added context beyond structured metadata.
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 front-loaded with the core purpose, then adds the key environmental warning and failure-classification detail, and ends with a direct routing instruction to the lighter sibling. Every sentence carries distinct information — coverage scope, extra version/path reporting, diagnostic output, intended use, and alternative tool — with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex diagnostic tool with no output schema, the description provides enough context to invoke it correctly: what it checks, optional behaviors, failure output characteristics, and when to prefer a different tool. It also explains why the version/path reporting matters, addressing an important operational scenario. Nothing essential is missing for an agent to select and call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters clearly. The description adds some high-level context by mentioning the optional IMAP IDLE probe and connection diagnosis, but it does not add parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate because the description isn't needed to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Run a comprehensive production health check') and enumerates the exact coverage areas: SMTP auth, IMAP auth, IMAP IDLE probe, SQLite index integrity, sync-failed drafts, runtime policy validation, and capabilities. It also explicitly distinguishes itself from get_connection_status by positioning this as the full diagnostic tool, so there is no ambiguity about its role relative to siblings.
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?
Usage guidance is explicit: 'Use to fully diagnose or validate the setup' and 'Prefer get_connection_status for a quick protocol-only reachability check.' It also gives a concrete trigger scenario — checking this tool first when behavior doesn't match the changelog because an old install can shadow an upgrade. This tells an agent exactly when to choose this tool and when to pick an alternative.
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 provides rich behavioral details beyond the destructiveHint annotation: content is snapshotted, the draft is not auto-marked sent/deleted, send timing depends on process lifetime, and cancellation is possible. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long, but every sentence carries essential caveats for safe usage. It is front-loaded with the core purpose and uses 'IMPORTANT' to highlight critical constraints, making it efficient despite its length.
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 thoroughly covers the tool's runtime behavior, limitations, cancellation, cleanup, and relationship to other tools. A minor gap is the lack of any mention of the return value or success/error indicators, which is notable since no output schema is provided.
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 to draftId by explaining content is snapshotted at schedule time, and to sendAt by explaining best-effort timing and startup fallback. However, it doesn't add detail for the 'confirmed' parameter 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 tool's function: 'Queue a saved draft to send at a future time instead of immediately.' It uses a specific verb+resource, distinguishes itself from send_draft (immediate send) and cancel_send (cancellation), and is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (to delay delivery) and critical when-not-to-use: 'this only fires while this MCP server process stays running' and 'not a reliable scheduler.' It also names alternatives ('Cancelable via cancel_send') and advises follow-up actions like checking list_drafts or get_email_stats after firing.
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 only provide destructiveHint: true, but the description goes well beyond that. It discloses the failure when PROTONMAIL_ALLOW_SEND is false, the queueing behavior with PROTONMAIL_SEND_DELAY_SECONDS, cancellation via cancel_send, the same-process caveat, and the confirmation requirement for destructive sends. This is rich, useful context not present in structured fields.
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 dense but every sentence earns its place: purpose, usage boundary, failure conditions, delayed-send behavior, and fallback behavior. It is front-loaded with the core action and remains compact given the complexity of the tool.
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 complex 17-parameter destructive send tool with only a destructiveHint annotation and no output schema, the description covers the essential behavior: what happens on success, failure modes, delay/cancellation, confirmation requirements, and relationship to sibling tools. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 17 parameters thoroughly. The description does not add additional parameter-level semantics beyond noting the delay override behavior, which is also described in the schema. Baseline 3 is appropriate because the schema carries the full burden.
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 states a specific action ('Compose and send a new outbound email through Proton Bridge SMTP') with a clear resource and mechanism. It also distinguishes itself from siblings by calling out create_draft and reply_to_email, 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 says when to use ('one-shot messages that need no review'), when not to, and names alternatives ('Prefer create_draft... or reply_to_email...'). Also provides operational guidance about failure conditions and delayed sends with cancel_send.
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?
With only destructiveHint:false in annotations, the description adds meaningful behavioral context: it is a 'force-push' (indicating an overwrite/forced action), it returns the remote UID, and it will be rejected when a specific env var is false. This goes well beyond the minimal annotation and discloses important conditions and outcomes.
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 tight sentences: the first states the action and return value, the second gives usage conditions and an exclusion. Every word earns its place, no fluff or repetition. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, this description is complete: it explains what it does, when to use it, a critical rejection condition, and the return value. The context is sufficient for an agent to decide and invoke correctly without ambiguity.
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 draftId parameter, and the schema already provides a precise description of where the ID comes from. The tool description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation: 'Force-push a locally saved draft to the Proton Drafts IMAP folder and return the remote UID.' It uses a precise verb and resource, and distinguishes itself from siblings like create_draft, update_draft, and list_remote_drafts by specifying the force-push and remote UID return. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use when a draft was created with syncToRemote:false or when the automatic sync failed.' It also provides a clear exclusion: 'Do NOT use this if PROTONMAIL_ALLOW_REMOTE_DRAFT_SYNC is false — the call will be rejected.' This gives concrete, actionable guidance with a conditional rejection, which is exactly what an agent needs.
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 the destructiveHint annotation, the description discloses a critical behavioral limitation: incremental sync never notices archived, trashed, or moved messages, so stale entries can persist indefinitely. It also explains exactly what full:true changes, giving the agent important operational knowledge not available from annotations 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?
The description is dense but well-structured: it front-loads the core purpose, then adds necessary caveats and usage guidance. Every sentence contributes meaningful information, and the length is justified by the tool's nuanced behavior.
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 sync tool with four optional parameters, no output schema, and important staleness caveats, the description covers the essential operational context: when to run it, what it does, what it misses, how to fix that with full:true, and which sibling to prefer for scheduled sync. This is complete for an agent to select and invoke it 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 100%, so the schema already documents all four parameters well. The description reinforces the meaning of full and folder but does not add substantial new parameter-level semantics beyond what the schema provides, so the 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 opens with a specific verb and resource: 'Incrementally sync email metadata from IMAP into the local SQLite index.' It clearly distinguishes this tool from siblings by explaining the checkpoint-based incremental mechanism and explicitly positioning it relative to search_indexed_emails, get_threads, and run_background_sync.
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 gives explicit usage context: use before search_indexed_emails or get_threads when the index may be stale. It also directs users to prefer run_background_sync for scheduled syncs and explains when to set full:true, providing clear alternatives and conditions.
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 well beyond the readOnlyHint annotation by disclosing blocking semantics, guaranteed return within timeout+grace, early-wake caveat, and correctness of detection even if not early. These are critical runtime behaviors not evident from 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?
Concise and front-loaded: first sentence states the core action and constraint. Subsequent sentences add necessary caveats without redundancy. No fluff, 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 the tool's simplicity (2 params, no output schema), the description fully explains purpose, usage constraints, and behavioral guarantees. Complete for an agent to invoke correctly without additional 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% and both parameters are clearly described in the input schema. The description does not add additional 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?
Clear action: opens an IMAP IDLE session and blocks until a mailbox change event or timeout. Specifies resource (mailbox) and operation (wait). Distinguishes from siblings by focusing on real-time detection without polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use case: 'Use to detect real-time inbox activity without polling.' Provides a clear exclusion: 'do not use in fire-and-forget pipelines.' Also explains timeout behavior, which helps decide when to call.
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 behavioral context beyond the destructiveHint annotation: details like 'delete (permanent expunge)', dryRun support, and continueOnError behavior, and does not contradict 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?
Concise at 4 sentences, front-loaded with purpose and usage, then actions, then alternatives. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch action tool without output schema, the description fully covers input semantics, supported actions, usage context, and sibling alternatives. No 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?
Schema coverage is 80% with descriptions on most parameters. The description adds semantics for the action enum (lists and explains each action) and clarifies emailIds format. Slightly redundant but helpful.
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 'Apply one action to a known list of email IDs' with specific verb and resource, and distinguishes from sibling tools like bulk_delete, apply_thread_action, and empty_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Use when you already have the IDs' and 'Prefer bulk_delete when selecting by search criteria', etc., providing clear when-to-use and 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavioral effect (evicts caches) and context (stale data). Annotations declare destructiveHint=false, and description aligns, adding detail about what is destroyed (in-memory caches but not index). 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 sentences: first states action and scope, second gives usage guidance and sibling differentiation. Concise and front-loaded with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and clear annotations, the description is fully complete. It covers purpose, usage, and what it does not do, which is sufficient for agent decision.
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?
No parameters in schema (0 params), so baseline is 4. Description does not need to add param info; it correctly implies no input required.
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 action (evict all in-memory caches) and specifies the cache types (folder list, message metadata, analytics data). Distinguishes from sibling tool 'clear_index' by noting it does not affect the persistent SQLite index.
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: when cached data appears stale after external mailbox changes (e.g., via Proton webmail). Provides explicit exclusion: 'Does NOT affect the persistent SQLite index — use clear_index for that.'
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 the destructiveHint annotation, the description discloses that the operation is irreversible, deletes all indexed metadata and search history, and specifically excludes in-memory caches. It also instructs the necessary follow-up action (sync_emails), providing full transparency about consequences.
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 four tightly written sentences, each earning its place: what, when, how to recover, and what it does not do. It is front-loaded with the core action and avoids any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive irreversible action with no output schema, the description fully addresses the agent's needs: what exactly is deleted, under what circumstances to invoke, the irreversibility, and the required rebuild step. The sibling clear_cache is explicitly differentiated, leaving no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter schema to elaborate on. The description nevertheless clarifies what the tool operates on (persistent SQLite index) and the irreversibility, which is sufficient for an agent to invoke without additional parameter context. Baseline 4 per rubric for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Delete the entire persistent SQLite mailbox index from disk.' It clearly distinguishes the tool from sibling clear_cache by stating the scope is the persistent index, not in-memory caches.
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 states when to use it ('reset a corrupted or schema-incompatible index') and provides alternatives: after clearing, call sync_emails to rebuild, and for in-memory caches use clear_cache. This is explicit when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though readOnlyHint=true already covers the read-only nature, the description reveals return contents (individual pass/fail per protocol), the server version and entrypoint path, and a subtle diagnostic warning about orphaned installs shadowing upgrades. This adds meaningful 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?
The description is dense but every clause earns its place: purpose, use cases, return values, version-check guidance, and an alternative tool. The most actionable information is 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 zero-parameter read-only diagnostic with no output schema, the description fully explains what it returns, why it matters, when to call it, and when not to. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing to document. Per the no-parameter baseline this is a 4; the description appropriately spends no space on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check whether Proton Bridge SMTP and IMAP are reachable'. It clearly differentiates this diagnostic from the sibling run_doctor tool by name, so an agent can distinguish it without opening schemas.
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 it: 'before sending or syncing, or when tools return connection errors.' It also names the alternative run_doctor and the condition for preferring that tool, leaving no ambiguity about selection.
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 adds valuable behavioral context beyond that: it discloses the batch failure semantics ('One failed id does not fail the whole batch — check each result's ok field') and the 25-item limit. This goes beyond the annotation's 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?
Four sentences, each with a clear purpose: what it does, when to use, failure behavior, and alternative. No filler or repetition. The description is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and only readOnlyHint annotation, the description carries the burden of explaining the return envelope ('ok field'), usage context, and limitations. It covers use cases, exclusions, and error behavior, making it sufficient for an 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so baseline is 3. The description adds meaning by clarifying that emailIds are 'composite' and come from prior search/email results, which is not in the schema. It also reinforces the max 25 constraint. However, it does not add detail for preferHtml or maxBodyLength beyond their 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 uses a specific verb ('Fetch') and resource ('full content for multiple emails by composite id'), clearly distinguishing it from siblings like get_email_by_id (single) and search tools (search vs fetch by id). The phrase 'in one call (max 25)' adds precise 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 states when to use: 'Use to read a batch of specific messages from a prior get_emails/search_emails/search_indexed_emails result' and explicitly recommends an alternative: 'Prefer get_email_by_id for a single message.' This is clear, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description enumerates the specific runtime state fields returned, adding behavioral details beyond the readOnlyHint annotation. It discloses that the tool is a read operation returning configuration and sync status, with no destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first lists the returned information, the second gives usage guidance. Every sentence is essential and there is 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?
Despite no output schema, the description lists the categories of state returned, providing enough context for an agent to understand the output. No additional detail is needed for this simple zero-parameter 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?
The tool has no parameters, so the description cannot add parameter semantics. In this case a baseline of 4 is appropriate; no param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and clearly identifies the resource 'server's current runtime state'. It enumerates the types of state information included, and distinguishes from the sibling tool get_connection_status.
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 ('understand how the server is configured and whether sync is actively running') and when to prefer an alternative ('Prefer get_connection_status for protocol reachability only'), providing clear decision guidance.
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 the destructiveHint annotation, the description discloses that sending marks the draft as sent but does not delete it, that it refuses to send when a scheduled send is pending to avoid duplicate delivery, and that it requires PROTONMAIL_ALLOW_SEND. This gives the agent a realistic model of side effects and failure conditions.
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 front-loaded with the core action and workflow placement, then adds only high-value behavioral and prerequisite details. Every sentence earns its place, including the rationale for refusing on pending scheduled sends, which prevents an agent from making a duplicate-delivery mistake.
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 destructive send operation with three parameters and no output schema, the description covers purpose, workflow context, side effects, prerequisites, and a critical conflict case. Combined with the fully documented input schema, an agent has what it needs to invoke this 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 the baseline is 3. The description adds meaning beyond the schema by clarifying that draftId refers to a local draft (as opposed to remote drafts in sibling tools) and by explaining the high-level workflow role of the draft. It does not need to restate dryRun/confirmed since those are already well documented 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 opens with a specific verb and resource: 'Send a previously saved local draft through Proton Bridge SMTP.' It clearly distinguishes this from related sending tools by scoping it to local drafts and a draft-review-send workflow, and the sibling list makes that differentiation useful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool: 'Use as the final step in a draft-review-send workflow after create_draft and optional update_draft.' It also gives an exclusion condition by refusing when a pending scheduled send exists and tells the agent to cancel that first, which is actionable routing guidance.
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 it forces a refresh and returns updated list; annotations only provide readOnlyHint which is consistent with server-side read.
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, no wasted 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?
For a zero-parameter tool with no output schema, the description fully explains behavior and usage 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?
No parameters; schema coverage is 100%; baseline 4 applies as no additional parameter info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Refresh' and resource 'folder list', and distinguishes from sibling get_folders by emphasizing it forces a refresh.
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 to use when folders changed externally and get_folders is stale, and to prefer get_folders for a read-only view.
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 the destructiveHint annotation, the description discloses critical behaviors: the XOR relationship between emailIds and match, the irreversible nature of permanent:true versus moving to Trash, the availability of dryRun for preview, and the safety mechanism of maxBatchSize to prevent runaway operations. 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 compact and well-structured, leading with the core purpose, then explaining key parameters, and finally providing decision guidance. Every sentence adds value and there is no redundant or filler 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?
For a complex tool with 7 parameters, a nested match object, and no output schema, the description covers all essential usage patterns, safety considerations, and sibling alternatives. It gives the agent enough context to invoke the tool correctly and safely.
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?
While the schema covers 86% of parameters, the description adds crucial semantic meaning: the XOR constraint, that folder is required with match, the purpose of dryRun as a preview, and the safety role of maxBatchSize. These details significantly enhance understanding beyond the schema's own 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 verb ('Delete'), the resource ('emails'), and the two modes of operation (explicit ID list or search criteria). It distinguishes itself from siblings by explicitly recommending empty_folder, delete_email, and batch_email_action for alternative scenarios.
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 usage context: 'Use when you have specific IDs to delete or want to filter by sender, subject, or date range.' It further provides clear alternatives with 'Prefer' statements, making it obvious when to choose this tool over related ones.
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 destructiveHint annotation, description adds 'Irreversible', 'Permanently delete', condition 'Only available when PROTONMAIL_ALLOW_EMPTY_FOLDER=true', and explains two-step process with confirmed parameter.
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?
Four concise sentences, front-loaded with main action. Every sentence adds value: purpose, usage, availability, and parameter guidance. No 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 2 parameters, destructive nature, and conditional availability, description fully covers purpose, guidelines, behavioral traits, and parameter usage. No need for output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds valuable context: folder path examples and explanation of confirmed parameter preview pattern, exceeding 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?
Clearly states 'Permanently delete ALL messages in a folder at once' with specific verb and resource. Mentions alternatives like bulk_delete for subset removal, distinguishing from siblings.
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 only when the goal is to clear an entire folder' and 'Prefer bulk_delete when removing a subset', providing clear when-to-use and when-not-to-use guidance with an alternative.
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:

[![proton-mail-bridge-client MCP server](https://glama.ai/mcp/servers/googlarz/proton-mail-bridge-client/badges/card.svg)](https://glama.ai/mcp/servers/googlarz/proton-mail-bridge-client)

Score Badge

Copy to your README.md:

[![proton-mail-bridge-client MCP server](https://glama.ai/mcp/servers/googlarz/proton-mail-bridge-client/badges/score.svg)](https://glama.ai/mcp/servers/googlarz/proton-mail-bridge-client)

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/googlarz/proton-mail-bridge-client'

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