Proton Safe MCP

by fbossiere

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: v1.0.2
Disambiguation4/5
Each tool targets a distinct action: mailbox status, folders, message listing/search/reading, attachment staging steps, and draft preparation/commit. The sequential attachment upload tools and the similar list/search message tools have slight boundary overlap, but the descriptions resolve their roles clearly enough.
Naming Consistency4/5
Tool names are consistently lowercase snake_case with an imperative verb + object pattern, such as list_messages, prepare_draft, and commit_approved_draft. The exception is mailbox_status, which is noun-oriented rather than verb-first, and the attachment upload verbs begin/upload/finish are repetitive but still distinct.
Tool Count5/5
11 tools is well-scoped for a safe Proton Bridge email interface: read-side operations, attachment upload lifecycle, and draft commit are all represented without significant redundancy. No tool feels superfluous, and the count fits the typical 3-15 range.
Completeness4/5
The domain of safe read and draft creation is covered end-to-end: status, folders, message search/read, attachment staging, and approved draft commit. Missing message send/delete and attachment download operations appear intentional for safety rather than true gaps, though their absence means the full email lifecycle is not covered.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false, the agent already knows this mutates state, but the description does not disclose what this call actually creates, whether it returns an upload identifier, or that chunk upload and finish steps must follow. Saying 'Start' and 'client-neutral' adds only minimal behavioral context without covering side effects or lifecycle expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The first sentence states the purpose, and the second provides a high-value safety/usage constraint. 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?
This tool is clearly part of a multi-step upload flow alongside upload_attachment_chunk, finish_attachment_upload, and discard_attachment, but the description gives no sense of that sequence or what the caller must do after this step. An output schema exists, so return values are partially covered, but the workflow context is missing.
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 carry parameter meaning. It only clarifies filename ('never a local path'); content_type, size_bytes, and sha256_hex receive no explanation. This leaves three required parameters underdocumented.
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 specific action ('Start') on a specific resource ('attachment upload') and adds a scoping qualifier ('client-neutral'). It is clear enough to separate this from upload_attachment_chunk and finish_attachment_upload by the 'Start' verb, though it does not explicitly name those alternatives.
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?
'Start a client-neutral attachment upload' implies this is the initial step, and 'Pass a filename, never a local path' is a useful input rule. However, it does not explicitly state when to use this versus sibling upload tools, nor what prerequisites or follow-up calls are required.
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 adds valuable side-effect context: after success, attachment tokens are destroyed and cannot be reused. However, the annotations declare destructiveHint=false, while the description says tokens 'are destroyed'. This is a direct contradiction, so per the rubric the score must be 1.
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 filler. The main action is front-loaded, followed by a non-goal and a critical side effect. 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 single-parameter tool with an output schema, the description covers the required precondition, the non-sending guarantee, and token destruction side effects. Some ambiguity remains about the source or role of draft_id, but the overall context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions draft_id or explains where it comes from or how it relates to the approval flow. The parameter name and 32-hex pattern are mildly self-explanatory, but the description adds no parameter-level guidance.
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 gives a specific verb and resource ('Create a Proton draft') plus a key precondition ('only after matching out-of-band local approval'). It also clarifies what it does NOT do ('never sends email'). It is clear, though it does not explicitly differentiate from sibling prepare_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when this tool should be used: only after out-of-band local approval. It also prevents misuse by stating that it never sends email. However, it names no explicit alternative or exclusion 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds concrete behavioral value by guaranteeing the operation does not mark messages as read and that only metadata is listed. It does not cover auth or rate limits, but the annotations cover the main 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?
The description is a single efficient sentence with no wasted words. The main purpose and key side-effect guarantee are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with optional, reasonably self-explanatory parameters and a read-only annotation, the description plus schema is mostly adequate. However, missing sibling routing and any parameter clarification leave moderate gaps for an agent deciding how to use the tool correctly.
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 provides no parameter information. limit, folder, and unread_only must be inferred solely from names, types, and defaults; the description adds no meaning beyond the input 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 uses a specific verb and resource ('List message metadata') and explicitly distinguishes itself from read_message by noting it does not mark messages as read. However, it does not name or differentiate from search_messages, so sibling differentiation is incomplete.
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 no guidance on when to use this tool versus search_messages, read_message, or other siblings. The phrase 'without marking messages as read' is a behavioral note, not a routing rule or explicit 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?
The description adds behavioral detail beyond annotations by mentioning verification and a short-lived token, which is useful. However, it does not disclose side effects such as whether the upload becomes immutable, whether calling this twice fails, or what happens to the upload on token expiry. With no idempotentHint and no explicit side-effect warning, important behavioral transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It front-loads the core action and clearly communicates the intended result.
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?
While an output schema exists, the description lacks essential contextual guidance: when in the upload lifecycle to call this, what the opaque token should be used for, and what prerequisites must be met. For a multi-step upload flow with six related sibling tools, this is 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?
The schema has 0% description coverage for parameters, so the description must compensate. It never mentions upload_id, how it is used, or why it must match the given pattern. The only parameter is left to be inferred from the tool name and context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: verify attachment size and SHA-256, then return a short-lived opaque token. This precisely identifies the finalization step and distinguishes it from sibling upload operations like begin_attachment_upload or upload_attachment_chunk.
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 guidance on when to call this tool relative to the upload flow. It does not mention prerequisites such as 'after all chunks have been uploaded' or that it should precede prepare_draft or commit_approved_draft. The agent must infer usage from the tool name and sibling 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?
The description adds the strict-ordering behavioral constraint, which is not conveyed by the annotations. However, it does not disclose what happens on out-of-order chunks, whether the operation is reversible, or any other side effects beyond the append itself. The annotations already signal mutation and non-idempotency, so the description's incremental value is limited.
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, front-loaded with the action verb and the key ordering constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the input schema, annotations, and presence of an output schema, gives an agent enough to select and invoke the tool correctly. The main missing context is the explicit relationship to begin_attachment_upload and finish_attachment_upload, but that is strongly implied by the tool's name and sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the semantic burden and largely succeeds: 'attachment upload' maps to upload_id, 'index order' maps to chunk_index, and 'base64 chunk' maps to data_base64. It compensates for the bare typed schema by tying each parameter to the operation's real-world meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Append'), a clear resource ('base64 chunk to an attachment upload'), and an important constraint ('strictly in index order'). This clearly differentiates it from sibling tools like begin_attachment_upload, finish_attachment_upload, and discard_attachment.
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 'next base64 chunk' and 'strictly in index order' strongly imply the tool is used between beginning and finishing an upload. However, it does not explicitly say when to use it versus the sibling tools, nor does it state prerequisites such as requiring an active upload created by begin_attachment_upload.
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 meaningful behavioral context beyond the annotations: 'Permanently remove' signals irreversibility, and 'before it is used' clarifies the only valid time window. This aligns with and enriches the destructiveHint=true annotation rather than merely repeating 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?
One tight sentence communicates the action, the target, and the timing with zero filler. The critical information is front-loaded, and no words are wasted.
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 destructive tool, the description plus annotations cover the purpose, irreversibility, and timing adequately. An output schema exists, so return-value documentation is not needed; the main gap is that the source of attachment_token is not explained.
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?
With 0% schema description coverage, the description carries the burden of explaining the parameter, but it never mentions attachment_token explicitly. The token's provenance, format, or relationship to the staged attachment is left entirely to inference from the parameter name and sibling 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 uses a specific verb ('Permanently remove') and a specific resource ('one staged attachment'), and clearly distinguishes this from sibling upload/commit tools. The phrase 'before it is used' adds the lifecycle position, making it unmistakable what this tool is for.
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 states that this tool applies to a staged attachment and must be used 'before it is used,' giving clear contextual timing. It does not explicitly name alternative tools for other stages, but the lifecycle wording makes the appropriate use case evident.
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, idempotentHint=true, and destructiveHint=false. The description adds a specific behavioral guarantee, "without marking messages as read," which goes beyond the generic annotation and is directly relevant to user expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core verb, resource, and a key behavioral trait. Every word 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values do not need describing, and annotations cover the safety profile. However, the folder parameter's meaning is not explained—whether search is scoped to a single folder or searches all folders—which leaves some ambiguity for correct invocation.
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, but it provides no information about the query, limit, or folder parameters. The phrase "message text" hints at what query targets, but folder scope and limit semantics are entirely absent, leaving the agent to rely only on schema 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 uses a specific verb and resource: "Search message text" clearly identifies the operation and target. It also differentiates from siblings by explicitly noting it does not mark messages as read, distinguishing it from read_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—searching message content when read side-effects are undesirable—but does not explicitly name alternatives or state when not to use it. This is clear context without exclusions, so it does not quite reach 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'locally running Proton Bridge' dependency, which is useful context beyond annotations, but it does not add much behavioral detail beyond that. A 3 is appropriate 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 a single, compact sentence that conveys the essential resource and scope without any filler or redundancy. It is appropriately sized for a zero-parameter, read-only list operation.
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 trivial zero-parameter listing tool with rich annotations and an output schema available, the description is complete. It states the source ('locally running Proton Bridge') and the resource ('folders'), and no additional call details are needed.
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 burden for the description to carry. The description correctly identifies what the returned folder list refers to, and the 100% schema coverage is trivial since the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 ('List') and a clear resource ('folders exposed by the locally running Proton Bridge'). It is immediately distinguishable from sibling tools like list_messages, search_messages, and read_message, which operate on messages rather than folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the context clear: this tool lists folders available from the locally running Proton Bridge, so it should be used when the agent needs the folder collection before filtering or reading messages. It does not explicitly name alternatives, but no sibling tool targets folders, so the usage context is sufficient.
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 annotations, the description discloses key behavioral details: the action stages a proposal rather than creating a final draft, the proposal expires, and it requires approval via local CLI before commit_approved_draft. This adds meaningful context about side effects and the lifecycle of the prepared draft, which annotations alone 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?
The description is two sentences with no filler. The core action and key constraint are front-loaded, and the follow-up requirement is stated efficiently. Every clause 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?
The description covers the essential workflow, approval requirement, expiration, and security constraint. Given the output schema exists and sibling tools reveal the attachment workflow, the description is mostly complete for an agent to invoke the tool correctly, though adding a brief reference to how attachment tokens are produced would make it fully self-contained.
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, but it only vaguely references 'recipients and attachment tokens' without explaining individual parameters like cc, bcc, subject, body_text, or how to obtain attachment_tokens. The parameter names and schema types offer some basic clues, but the description provides little additional semantic meaning for each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: 'Prepare, but do not create, a Proton draft.' It names the specific resource (Proton draft) and distinguishes the action from creation, which also differentiates it from the sibling tool commit_approved_draft. The scope is precise and understandable without needing 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage conditions: recipients and attachment tokens must come from the user's request, not from email content, and the draft proposal requires CLI approval before commit_approved_draft. This tells an agent when and how to use the tool, and implicitly when not to use it, by referencing the required follow-up workflow.
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 annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds critical behavioral context: the body is attacker-controlled data, HTML and attachment bytes are not returned, and output is bounded. This materially informs safe invocation and interpretation of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The security warning is front-loaded, and every sentence adds distinct value: what the tool returns, how to treat the data, and what is excluded.
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, idempotent tool with a detailed input schema and an output schema, the description covers the important non-obvious context: safety of the body content and exclusion of HTML/attachments. Nothing an agent needs to call it correctly is missing.
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 should compensate for parameter meaning, but it does not mention uid, folder, or max_chars at all. While the schema itself documents constraints and defaults, the description adds no semantic guidance for choosing or filling these 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 states a specific verb ('Read'), a precise resource ('one email'), and a concrete output form ('bounded plain text'). It also distinguishes itself from siblings like list_messages and search_messages by focusing on reading a single message body rather than listing or searching.
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 this tool is for reading an individual message body, while siblings like list_messages and search_messages handle discovery. It does not explicitly name alternative tools or state when not to use it, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description only needs to add context. It adds that the check targets the local Proton Bridge and returns INBOX counts, which goes beyond the annotations. It does not describe failure behavior when the Bridge is unavailable, but the annotations lower the burden.
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. Every word contributes meaning: the target ('local Proton Bridge connection'), the action ('Check'), and the return value ('INBOX counts').
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 status tool with a defined output schema and rich annotations, the description is complete enough. An agent knows what the tool does, what it returns at a high level, and that it is safe to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is no parameter semantics for the description to clarify. Per the baseline for zero-parameter tools, this is appropriately handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 action ('Check the local Proton Bridge connection') and a concrete output ('return INBOX counts'), making its purpose immediately clear. It also distinguishes itself from the sibling message and attachment tools, which operate on mailbox content rather than 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for verifying Proton Bridge connectivity and getting INBOX count information, providing solid context for when to use it. It does not explicitly name alternatives or exclusion conditions, but no sibling tool serves the same status-check role, so the usage context is sufficient.
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-safe-mcp MCP server](https://glama.ai/mcp/servers/fbossiere/proton-safe-mcp/badges/card.svg)](https://glama.ai/mcp/servers/fbossiere/proton-safe-mcp)

Score Badge

Copy to your README.md:

[![proton-safe-mcp MCP server](https://glama.ai/mcp/servers/fbossiere/proton-safe-mcp/badges/score.svg)](https://glama.ai/mcp/servers/fbossiere/proton-safe-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/fbossiere/proton-safe-mcp'

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