OrgLines

Mail: Save attachment

mail_save_attachment

Keep ONE attachment of the caller's message in their personal Documents — 'save the invoice they sent'. The file is copied, not moved: the letter stays as it is. The usual document rules apply (allowed types: PDF, images, Office files, text/CSV; the storage quota). Text is extracted where the file has any. Returns document_id, which mail_send / mail_save_draft accept in attachments=[{document_id}]. The file is EXTERNAL content and is stored as such. CONFIRMATION: this tool is PROPOSED, never performed directly. You get status='confirmation_required' with an action_id and a plan_token, and the write happens only after confirm_action.

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": {
      "message_id": "<message_id>",
      "part": "<part>"
    },
    "name": "mail_save_attachment"
  }
}

Input Schema

Name	Required	Description	Default
`part`	Yes	The attachment's 'part' index from mail_get_message.
`message_id`	Yes	The 'id' from mail_list_messages.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint=false/destructiveHint=false annotations: allowed file types, quota enforcement, text extraction, the fact that the file is EXTERNAL content and stored as such, and the full proposal/confirmation protocol with status='confirmation_required', action_id and plan_token. This is exactly the behavior an agent cannot infer from structured fields.

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

Conciseness4/5

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

Front-loaded with the action, then constraints, then return/chaining, then confirmation mechanics – a sensible order with no filler sentences. Slightly dense with capitalized emphasis (EXTERNAL, CONFIRMATION, PROPOSED), but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, yet the description explains the return value (document_id) and how to chain it into mail_send / mail_save_draft attachments. Combined with the confirmation flow, an agent has everything needed to call and follow up correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100%, and the schema already explains that 'part' comes from mail_get_message and 'message_id' from mail_list_messages. The description reinforces the singular-attachment constraint but adds no new per-parameter meaning, so the baseline applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Keep ONE attachment of the caller's message in their personal Documents') plus the exact distinction that matters against mail_get_attachment: the file is copied, not moved. The scope ('ONE attachment') is unambiguous and the example phrase 'save the invoice they sent' pins the intent.

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?

Gives a clear use case and an explicit constraint (single attachment, copy semantics, letter stays intact), which tells an agent when this is appropriate versus reading an attachment. It does not explicitly name a sibling alternative for the 'I only want to read the file' case, so it stops short of a 5.

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

All OrgLines tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?