Skip to main content
Glama
Sign In
Proton Suite Agent

Proton Suite Agent

by Soluciones-Alexendros
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Forward an email

proton_forward_email

Forwards an existing Proton Mail message to new recipients, optionally including original attachments, so agents can redirect email without recreating it.

Instructions

Forwards an existing message to new recipients. Optionally includes original attachments.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "uid": "<uid>",
      "to": "<to>"
    },
    "name": "proton_forward_email"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYes
uidYes
htmlNo
textNo
mailboxNoINBOX
include_attachmentsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.7.4
    • changedInput schema / properties / to / items / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  2. First observedv0.8.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the agent knows this is a non-idempotent outbound write. The description adds the default-on attachment copying behavior, which is useful, but it omits that this dispatches real email to external recipients and says nothing about how the original body is combined with the new html/text.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, and the core action is front-loaded. It is terse to the point of leaving gaps, but no sentence is wasted.

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 six-parameter, non-idempotent mutation with no output schema and no parameter documentation, the description is thin. Key behaviors an agent needs — body handling, mailbox selection, what the response returns — are all unaddressed.

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% across six parameters, so the description must compensate. It only implicitly clarifies 'to' and 'include_attachments'; it says nothing about uid, mailbox, or — most importantly — whether the html/text parameters replace or supplement the original message body.

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 ('Forwards an existing message') plus the optional attachments behavior, which is more than a restatement of the title. It does not, however, differentiate from nearby siblings like proton_reply_email or proton_send_email, which an agent might reasonably confuse with forwarding.

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 forward versus reply or send a new message, despite both siblings being present in the toolset. No prerequisites (e.g., that the uid must reference an existing message in the mailbox) are stated.

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

Deploy Server

Other Tools