mcp-proton-mail

Overview Schema Source Related Servers Discussions Admin

List allowed From addresses

list_from_addresses

Read-onlyIdempotent

Lists the accepted From addresses and default address so you can choose a valid from_address before drafting, replying, or forwarding; reads no mail and changes nothing.

Instructions

List the From addresses that create_draft, forward_message and compose_reply accept in from_address; reads no mail and changes nothing.

Use it before passing from_address, or when the user asks which address mail goes out from. Saving a draft from an allowed address needs no approval.

default is the account's own address, used when a draft names none. allowed lists every address from_address accepts, as the operator configured them; default_allowed says whether default is among them. Any other address refuses, even an alias of this account.

Returns default, allowed, default_allowed, send_enabled (whether any tool can send) and note.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description reinforces this with "reads no mail and changes nothing." Beyond that, it also supplies real behavioral context: non-listed addresses are refused even when they are aliases, 'default' is used when a draft names no address, and saving from an allowed address needs no approval. It repeats the output fields that the output schema already documents, which keeps it from being fully additive.

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?

It front-loads the scope and the no-side-effects guarantee, then gives the precondition, then the return shape — a logical order for an agent. Each sentence earns its place, and the return-value sentence is only slightly redundant with the output schema.

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 lookup with a full output schema and annotations, the description covers everything needed: when to call it, what it returns, how defaults resolve, and what happens with disallowed addresses. Nothing an agent needs in order 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero input parameters, so parameter semantics carry no burden and the baseline is 4. The description's discussion of from_address concerns the parameters of the sibling tools, not this call's inputs.

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?

It gives a specific verb and resource ("List the From addresses") and immediately ties the resource to the exact siblings that consume it ("create_draft, forward_message and compose_reply accept in from_address"), so an agent can identify the tool's role without opening any 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?

It explicitly states when to call it ("Use it before passing from_address, or when the user asks which address mail goes out from") and adds a permission/approval caveat for the draft case, which is a clear precondition rather than an implied one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.