protonmail-mcp

by dadamonis

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools target distinct actions, but several boundaries blur: list_labels overlaps with list_mailboxes since labels appear as folders, create_mailbox can create labels when passed a Labels/ path, and remove_label vs delete_label could easily be confused. The descriptions help, but an agent still faces real misselection risk.
Naming Consistency4/5
The vast majority of tools follow a clear verb_noun snake_case pattern: list_emails, send_email, create_label, download_attachment. Exceptions like bridge_status and ping break the pattern slightly, but there is no chaotic mixing of styles.
Tool Count3/5
23 tools is on the heavy side for a single server and falls in the borderline range where each tool must clearly earn its place. Most tools are individually justified for a full email client, but the set feels larger than ideal and could be trimmed by merging health-check or label-related operations.
Completeness4/5
The tool surface covers the core email lifecycle well: list, get, search, send, reply, forward, draft, move, delete, mark, thread, attachments, folders, and labels. Notable gaps include no way to attach files when sending or replying, and no label rename/update operation, but agents can work around most of these gaps.
Average 3.6/5 across 23 of 23 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under LGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the quoting behavior and does not disclose whether the email is sent immediately, whether a sent copy is created, how attachments are handled, or what side effects occur.
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, front-loaded sentence with no filler. It is concise, though brevity comes at the cost of needed operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no schema descriptions, no annotations, and many sibling tools, a one-sentence description is insufficient for an agent to invoke the tool correctly with confidence. The output schema may explain return values, but pre-call behavior and accounting for defaults remain unexplained.
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 0% for 5 parameters, and the description does not compensate by explaining what uid, to, body, account, or mailbox mean or how they interact. The agent gains no parameter meaning beyond the bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Forward an email') and a distinguishing detail ('with the original content quoted'). However, it does not explicitly differentiate forwarding from closely related sibling tools like reply_email or send_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use forwarding versus replying, sending, or saving a draft. There are no stated exclusions, prerequisites, or alternative selection criteria, leaving the agent to infer the appropriate context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the action implied by the name. It does not mention whether the original email is removed from the source folder, whether the operation is reversible, what permissions are needed, or how destination failures are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no redundant phrasing. While it is brief, it is not padded and delivers the core action directly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, the description is too sparse. Even though an output schema reportedly exists, the description lacks essential context about prerequisites, behavior on failure, source mailbox handling, and parameter relationships.
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 0%, and the description mentions no parameter details. The agent must infer the meaning and usage of uid, account, mailbox, and destination solely from their names, with no compensation for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and resource ('email to another folder'), clearly indicating a folder-relocation operation. It is unambiguous about the core action, though it does not explicitly differentiate from siblings like add_label or mark_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use move_email versus alternatives such as delete_email, add_label, or the send/reply/forward tools. There are no prerequisites, exclusions, or context clues about when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action 'create' and the placement 'a folder under Labels/', which is a behavioral detail. However, it does not disclose any side effects, error conditions, or permission requirements. It is minimal but adequate for a simple create operation, but not rich enough to cover all behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It states the operation and a structural detail in an efficient manner. No superfluous information or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple creation with two parameters and an output schema exists, the description is still incomplete. It lacks usage guidance and parameter semantics, and does not explain the account parameter or potential duplicate-handling behavior. An agent could call it incorrectly if it assumes defaults or naming conventions not covered here. The description is insufficient for a non-trivial tool with no annotation support.
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 0%, so the description must compensate by explaining the parameters. It does not mention the 'name' parameter, the optional 'account' parameter, or their formats/meanings. The agent is left to guess what values to provide, which is a significant gap given zero parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'create' and resource 'ProtonMail label', and even clarifies that it creates a folder under Labels/. This is a clear, unambiguous statement of purpose. However, it does not explicitly differentiate from sibling tools like add_label, which could be ambiguous, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like add_label or create_mailbox. There is no mention of prerequisites, conditions, or when this tool is preferred. It simply states what it does, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does provide one useful side effect: deleting a label removes the Labels/<name> folder. However, it does not mention whether the operation is irreversible, whether messages with the label are affected, or any permission or error conditions, leaving relevant destructive-operation context undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Both the core action and a valuable clarifying side effect are included; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, this description is too thin. It omits usage guidance, distinction from remove_label, and the effect on existing messages/emails that carry the label. The presence of an output schema covers return values, but the operational context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that `name` is the label name corresponding to the Labels/<name> folder, but gives no explanation of the `account` parameter, its default, or how it selects the account. Thus only partial compensation is achieved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies the action (Delete) and the resource (ProtonMail label), and adds a concrete detail (removes the Labels/<name> folder). It does not explicitly differentiate from the sibling remove_label, which could be a distinct operation, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when this tool should be used versus alternatives like remove_label or add_label, nor any stated conditions or exclusions. The description only states the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful behavioral nuance by stating that bare names default to the Folders/ namespace and that explicit paths control placement. However, it does not clarify whether Labels/ paths create labels, what happens on duplicates, or any permission/error behavior, and the phrase "Create a folder" mildly conflicts with the Labels path.
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 efficient sentences with no filler. The core action is front-loaded, and the second sentence delivers the key namespace placement rule compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values need not be described. The description covers the main name semantics and default namespace, but it leaves the account parameter undocumented and fails to clarify the Folders/Labels relationship, which matters given the create_label sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It partially does so for name by explaining bare names versus explicit Folders/... or Labels/... paths, but it completely omits the account parameter, leaving the agent with only the schema default to guess its meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: "Create a folder." It adds meaningful namespace detail (Folders/ vs Labels/) that helps distinguish it from label-related siblings, but it does not fully resolve how Labels/... paths relate to create_label, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful guidance on how to format the name parameter, explaining the default Folders/ namespace and explicit path override. However, it never says when to prefer this tool over create_label or when not to use it, which is a significant gap given the Labels/... path support and sibling tool create_label.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies mutation but does not disclose behavior around null values, idempotency, server synchronization, or what happens if both read and flagged are null.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It efficiently communicates the core action despite being terse in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no annotations, the description is incomplete. It does not explain how the target email is identified, how the boolean/null parameters interact, or what side effects are expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'read' and 'flagged' via 'read/unread' and 'flagged/unflagged', but it does not explain 'uid', 'account', or 'mailbox', leaving the targeting semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 concrete verb ('mark') and identifies the resource ('an email') plus the exact state changes ('read/unread and/or flagged/unflagged'). This clearly separates it from siblings like get_email, move_email, or add_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as add_label/remove_label for labels or move_email for folder moves. It also does not mention prerequisites like the email existing in the specified mailbox.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Search' inherently indicates a read-only operation and the description names the search scope, but it does not mention behavior beyond that, such as search semantics, result ordering, pagination, or access 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 a single front-loaded sentence with no filler or redundant information. Every word contributes to stating the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus the schema is sufficient for a very basic invocation, especially with sensible defaults on limit, account, and mailbox. However, the mismatch between 'folder' and 'mailbox', the lack of alternative routing, and the absence of parameter explanations leave the agent without enough context for confident, nuanced use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for unexplained parameters. Only 'query' is loosely described as a 'keyword', while 'limit', 'account', and 'mailbox' are not explained, and 'folder' does not align with any schema property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Search'), a resource ('a folder'), and the searchable fields ('subject, sender, and body'), which is clear and distinct from sibling tools like list_emails. However, 'folder' does not map exactly to the schema's 'mailbox' parameter, adding slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives such as list_emails or get_email. The keyword-search intent is implied, but the description does not state exclusions or name alternatives, leaving tool selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It does mention one permanent side effect (filing into Sent), but it does not state that sending is irreversible, delivers externally to recipients, may be subject to account/rate limits, or what happens on failure. For an external side-effectful action this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the core action is front-loaded and the Sent-filing detail is useful extra context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema supplies required/optional fields and defaults, and an output schema exists, so return value documentation isn't the description's responsibility. Still, with zero annotations and no guidance about alternatives or the 'account' parameter, the overall definition is only minimally complete for an action with real-world delivery consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no parameter-level meaning beyond 'new email.' The property names (to, cc, bcc, subject, body, html, account) are mostly self-explanatory, but ambiguous ones such as html and account are left undocumented, and the description does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a new email') and the resource route ('through Bridge'), plus a distinctive side effect ('Bridge files it into Sent'). It implies a new message rather than a reply, forward, or draft, though it does not explicitly name the sibling tools it contrasts with.
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 word 'new' implies that send_email is for creating an outbound message, as opposed to reply_email, forward_email, or save_draft. However, the description never states these alternatives or gives explicit conditions for choosing this tool, leaving the routing largely to inference.
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 discloses two valuable behaviors: base64 output encoding and a 5 MB hard cap, which is genuinely useful context. However, with zero annotations the description carries the full burden, and it fails to say what happens at the cap (error vs truncation) or for a missing attachment — exactly the behavioral detail an agent needs for error handling.
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, front-loaded sentence where the verb and resource lead, with the encoding format and size limit following as compact parenthetical context. Every word earns its place with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and 0% parameter documentation, the description is too thin. The output schema covers return structure, but required parameter semantics and cap-failure behavior remain undocumented, leaving an agent with real uncertainty about how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate but does not. Neither required parameter is explained: uid is ambiguous (email UID vs attachment ID) and the relationship between uid and filename as the attachment selector is left to guesswork. Parameter names and defaults carry the only meaning, which is insufficient at 0% 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 states a specific verb ('Download'), a singular resource ('one attachment'), and a format detail (base64), making the tool's job unmistakable. This cleanly separates it from all email- and mailbox-level siblings like get_email or list_emails, since no other sibling handles attachment content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied — call this when you need an attachment's raw content, likely after fetching an email — but nothing explicitly states when to prefer it over get_email or that uid/filename must first be obtained from an email fetch. There is no exclusion guidance or prerequisite 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?
The description reveals the non-obvious behavior that adding a label means copying the email into a Labels/<name> folder, which is valuable context beyond the tool name. However, with no annotations, it does not disclose prerequisites such as the label needing to exist, potential side effects, 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?
The description is one tight sentence that front-loads the action and then adds an important parenthetical clarification. There is no filler or redundant restating of the tool name.
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 captures the core operation and the Bridge-specific representation, but it leaves parameter semantics unexplained and does not guide the agent toward related tools for label creation or removal. Given the schema provides defaults for account and mailbox, the tool is usable, but the description alone is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only clarifies that 'label' maps to a folder name in Bridge, but it does not explain 'uid', 'account', or 'mailbox'. Required parameters are otherwise undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 clear verb and resource: 'Add a ProtonMail label to an email.' It also clarifies the underlying mechanism, 'copies it into the Labels/<name> folder,' which distinguishes this from create_label and remove_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by saying it adds a label to an email, and it gives useful context about how Bridge represents labels. However, it does not explicitly name alternatives like create_label for creating a label or remove_label for removing one, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides useful behavioral detail by stating that text is preferred and listing the return fields, but it does not disclose that mark_seen can change message state or how include_html affects the body. With no annotations available, the description carries the burden, and it covers the main read behavior while leaving the side-effect potential implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with a colon-separated payload list. Every phrase earns its place, and there is no filler, repetition, or unnecessary expansion.
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 output schema helps cover return-value information, and the core purpose is clear. Still, the definition is thin for a tool with five parameters, zero schema descriptions, no annotations, and many closely related siblings, leaving side effects and routing decisions incompletely specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for the five parameters. It implies that uid identifies the email and that body text is preferred, but it does not explain account, mailbox, mark_seen, or include_html beyond what their names and defaults already suggest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 — 'Read one email in full' — and enumerates the exact content returned: body, headers, threading ids, and attachment metadata. This clearly distinguishes it from siblings like list_emails and search_emails, which operate over many messages, and from download_attachment, which returns attachment bytes rather than metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: when the agent needs the full content of a single email rather than a list or search result. However, the description never explicitly states when not to use this tool or when to prefer a sibling such as get_thread or download_attachment, so the guidance is present only by inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'List' implies a read-only operation, and the description adds useful structural context that labels are IMAP folders under Labels/. It does not disclose details like account filtering or response behavior, but it offers enough for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The main purpose is front-loaded, and the second sentence adds a valuable routing note without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the description covers its core purpose plus a useful link to list_emails. However, the account parameter is left unexplained, and with 0% schema coverage this is a small but real completeness gap.
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 0%, and the description does not mention the 'account' parameter at all. The schema only provides the title 'Account' and a default of 'default', so the description adds no meaning beyond the structured schema. This is a clear 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 starts with a specific verb and resource: 'List ProtonMail labels.' It also distinguishes labels from related concepts by noting they are IMAP folders under Labels/, and names the sibling list_emails for viewing tagged mail. This clearly separates it from list_mailboxes and list_emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use list_emails with mailbox="Labels/<name>" to see tagged mail, which is a concrete routing instruction. It does not explicitly state when not to use list_labels or contrast it with list_mailboxes, but the provided guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does communicate the core effect (saving to Drafts, not sending), but it omits other useful behavioral details such as whether an existing draft is overwritten, what the response contains, or whether account selection affects 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?
A single sentence that front-loads the primary action, states the destination, and includes the key exclusion ('without sending'). Every phrase earns its place 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with 6 parameters and no annotations, the description is somewhat thin. It omits guidance on the 'html' flag, the 'account' parameter, and how drafts are handled or returned. However, an output schema is present, so some return-value expectations may be covered elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any parameter semantics. While parameter names like 'to', 'subject', and 'body' are self-explanatory, the description adds no value for less obvious parameters such as 'html' or 'account'. The description fails to compensate for the absent 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 names a specific action ('Save an email as a draft'), a target location ('Drafts folder'), and an explicit boundary ('without sending'). This clearly distinguishes the tool from siblings like send_email and forward_email, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without sending' implies the tool should be used when a draft is wanted rather than an immediate send, but it does not explicitly state when to choose this tool over alternatives or mention any prerequisites. Usage is implied, not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully mentions that reconstruction relies on Message-ID / References headers and is scoped to a given folder, but it does not disclose assumptions such as what happens when headers are missing or whether messages outside the folder are excluded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action, explains the mechanism, and scopes the operation. Every word contributes meaning 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 read-oriented thread reconstruction tool with an output schema present, the description provides the core functional context an agent needs: what is retrieved, how, and within what scope. Some additional caveats about header-based threading limitations would improve it, but it is not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate by explaining parameters. It hints at 'an email' (likely the uid) and 'within the given folder' (likely mailbox), but it never explicitly names or explains uid, account, or mailbox semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reconstruct') and resource ('conversation thread around an email'), and distinguishes itself clearly from siblings like get_email or list_emails. The mechanism (Message-ID / References headers) adds precision about what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need the thread around an email rather than the email itself. However, it does not explicitly state when not to use it or name any alternative tools, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does well by disclosing that return is organized into Labels/ and Folders/ groups and includes message/unread counts, which is beyond what the name alone conveys. The read-only nature is reasonably implied by 'List.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the core action front-loaded and the second sentence adding only the non-obvious folder-vs-label grouping behavior. There is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has only one optional parameter, and has an output schema, so the description does not need to detail return fields. It covers the key behavioral nuance about label/folder grouping, and only the account parameter semantics and alternative-tool routing are left under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the 'account' parameter. The schema provides only a name and default value, which leaves ambiguity about what 'account' refers to and how to select a non-default account.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: 'List folders with message and unread counts.' It also distinguishes itself from label-specific tools by explaining how ProtonMail labels appear under Labels/ and custom folders under Folders/, making its 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings like list_labels or list_accounts. The description implies it is for folder-level listing but does not state exclusions or alternatives, so the agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the success behavior ('returns "pong" if the server is running') and implicitly frames this as a non-mutating check. However, it does not describe what happens when the server is not running, error behavior, or timeout semantics, which are relevant for a liveness probe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the purpose front-loaded ('Liveness check') followed immediately by the expected return value. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter liveness probe with an output schema, the core contract is covered: what the tool does and what success looks like. The main gaps are failure behavior and differentiation from sibling health-status tools, but these are relatively minor for such a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema confirms an empty properties object. There is nothing for the description to add about parameter meaning or formats. The baseline of 4 applies here because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific purpose: a liveness check that returns 'pong' when the server is running. The verb and expected result are unambiguous. However, it does not differentiate this tool from sibling tools such as check_health or bridge_status, which could have overlapping roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Liveness check' implies the tool should be used to verify whether the server is running. But there is no explicit when-to-use guidance, no exclusion criteria, and no mention of alternatives like check_health or bridge_status. An agent would have to infer the appropriate context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context by specifying that the operation deletes the email's copy from the Labels/<name> folder and identifies the email by Message-ID. However, it does not mention idempotency, error behavior if the label is missing, permissions required, or effects on other messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action and adds the critical behavioral detail in a parenthetical. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no schema descriptions, and four parameters, the description is somewhat sparse. It covers the core operation and the meaning of the two required parameters, but omits guidance on the optional account/mailbox parameters and any error or edge-case behavior. The presence of an output schema means return values do not need to be 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?
The schema provides no parameter descriptions (0% coverage), so the description must compensate. It clarifies that 'uid' is a Message-ID and 'label' is a label name, which adds value. However, 'account' and 'mailbox' remain completely unexplained, leaving two of the four parameters semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Remove', the resource 'ProtonMail label from an email', and the mechanism 'deletes its copy from the Labels/<name> folder'. This distinguishes it from sibling tools like add_label and delete_label, making the tool's purpose immediately identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a label needs to be removed from an email. It does not explicitly contrast with alternatives such as delete_label or create_label, nor does it state when not to use it. Usage context is clear enough, but exclusions and alternative routing are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden; it does reveal the important threading behavior and its conversational effect. However, it does not state whether the reply is sent immediately, what side effects occur (e.g., a sent copy), or what permissions are 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?
A single sentence with no filler; the threading detail is relevant and front-loaded. Every clause contributes something the agent needs to know.
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 core purpose is complete and an output schema is present, so return-value explanation is not required. Yet optional parameters with defaults (quote, reply_all, account, mailbox) are not explained and there are no annotations, leaving real gaps for selecting and invoking correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level meaning. It does not clarify the role of uid/body, the quote default, reply_all behavior, or account/mailbox selection, leaving the agent to infer these from names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact operation ('Reply to an email') and adds the distinctive threading requirement (In-Reply-To/References) and the ProtonMail context, making it easy to distinguish from sibling tools like send_email and forward_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the right context—replying to an existing email while preserving the thread—but it never explicitly names alternatives or states when not to use it (e.g., for a new message use send_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?
There are no annotations, so the description carries the safety burden. It does this well by disclosing that deletion is non-destructive by default (moves to Trash) and that permanent=true switches to a destructive path. It also surfaces a real operational limitation. It does not explicitly warn that permanent deletion is irreversible, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences with the action front-loaded. Every clause earns its place by adding a behavioral fact: what it does, how permanent changes it, and where it is refused.
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 4-parameter mutation tool with an output schema, the description covers the essential context: target resource, default vs permanent behavior, and a critical unsupported folder. It lacks an explicit irreversibility warning and a cross-reference to move_email, but those are not necessary for correct 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 0%, so the description must compensate. It explains the non-obvious parameter 'permanent' by tying it to the Trash behavior. The uid, account, and mailbox parameters are not described, though their names and schema defaults make them reasonably inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 an email') and immediately clarifies the core semantics: Trash by default, permanent deletion only when permanent=true. It also states a concrete boundary ('Refused on the virtual All Mail folder'), which distinguishes the tool from generic delete or move 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?
The description gives a clear use case ('Delete an email') and explains the default vs permanent behavior. It also provides an explicit when-not by stating that the operation is refused on All Mail. It does not explicitly mention alternatives like move_email, but the selection context is clear enough for an agent.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It adds a meaningful and reassuring behavioral guarantee: 'never includes credentials', which helps an agent understand safety and privacy boundaries. It does not mention other behavioral aspects, but for a simple read-only listing operation this is a strong and sufficient disclosure.
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, focused sentence that front-loads the tool's purpose and adds one critical safety note. Every word earns its place; there is no redundancy or unnecessary detail.
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 listing tool with an output schema already defined, the description is complete. It tells the agent what will be listed and explicitly rules out credential exposure. Sibling tools for emails, mailboxes, and labels are clearly distinct, and no additional preconditions or return-format explanations are necessary given the 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, so there is no parameter semantics to explain; the baseline of 4 applies. The description's credential note refers to output behavior rather than parameters, which is appropriate and does not leave any input ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List configured ProtonMail accounts'. The qualifier 'never includes credentials' proactively distinguishes this from potential account-related tools and adds important scope clarity. It clearly separates this tool from sibling tools focused on mailboxes, emails, labels, and actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to list configured accounts. However, it provides no explicit guidance about when not to use it or which sibling tool might be an alternative for account-related information, such as bridge_status. The usage context is understandable but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure, and it does well: it reveals newest-first ordering, pagination, date format (ISO YYYY-MM-DD), filter categories, and label-specific mailbox behavior. It does not mention edge cases like pagination limits or ordering ties, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The most important facts are front-loaded (what the tool does, ordering, filters, date format), and the edge-case label syntax is efficiently appended.
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?
An output schema exists, so the return shape is covered elsewhere. Given no annotations and eight parameters at 0% schema coverage, the description covers ordering, filters, pagination, date format, and label behavior. It falls slightly short only by omitting the account parameter and giving no detail on how offset interacts with pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does for most parameters: since/before get date format, from_addr and unread_only are implied by 'sender/unread filters,' limit/offset by 'pagination,' and mailbox by the folder/label explanation. The account parameter is not addressed, which is a minor gap among eight 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: 'List emails in a folder,' and immediately adds ordering, pagination, and filter scope. This clearly distinguishes it from siblings like get_email, search_emails, and get_thread without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: listing emails in a folder with optional filters, and it specifies the special mailbox syntax for ProtonMail labels. It does not explicitly state when to prefer search_emails or other alternatives, but the usage context is strong enough for an agent to choose correctly in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. 'Report on' implies a read-only diagnostic action, and the listed items (installed, running, ports, certificate, configured accounts) make the scope transparent. It does not explicitly say 'does not modify state', but the reporting verb strongly implies a safe inspection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, then lists the report's contents. Every phrase adds useful information and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter status-reporting tool with an output schema present, the description is sufficiently complete. It specifies the subject matter and the aspects reported, and the output schema is available to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers all input concerns. The baseline for zero-parameter tools is 4; the description does not need to add parameter semantics beyond what is already self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 ('Report on') with a specific resource ('local ProtonMail Bridge') and enumerates exactly what the report covers: installed, running, ports, certificate, and configured accounts. This clearly distinguishes it from sibling tools like ping, check_health, and list_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is clear: retrieve status information about the local ProtonMail Bridge. However, it does not explicitly contrast itself with sibling tools such as check_health or ping, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully discloses that latency is included and that the tool returns guidance instead of failing when Bridge is down. It does not explicitly state that the operation is read-only, but for a connectivity check this is a relatively minor omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. The core action and scope are front-loaded, and the Bridge-down behavior is stated without extra verbiage.
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 one-parameter diagnostic tool with an output schema, the description is complete enough for an agent to invoke it correctly. It covers scope, protocol coverage, latency, and failure behavior, leaving no critical 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?
Schema description coverage is 0%, so the description must compensate. It does: 'one account or all of them' clarifies that omitting the optional account parameter checks all accounts while providing a string checks one. It does not specify the expected account format, but the parameter is simple and optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: check IMAP and SMTP connectivity with latency. It clearly defines scope ('one account or all of them') and differentiates itself from the sibling bridge_status by focusing on protocol connectivity while still addressing Bridge-down behavior.
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 context for when to use this tool is clear: it is for checking IMAP/SMTP connectivity, with an explicit one-account-or-all scope. It does not explicitly name alternatives or state when not to use it, but the Bridge-down behavior implicitly distinguishes it from a simple bridge status check.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dadamonis/protonmail-mcp'

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