Skip to main content
Glama

create_mail_rule

Set up automated mail processing in Paperless-ngx by defining which incoming emails and attachments to import, then assigning tags, correspondents, document types, and actions to the resulting documents.

Instructions

Create a mail rule on a mail account: which folder and mails to consider, which attachments to import, and what to assign to the resulting documents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
orderNoRules run in ascending order
ownerNo
actionNoWhat happens to processed mail: 1=delete, 2=move to action_parameter folder, 3=mark as read (default), 4=flag, 5=tag with action_parameter
folderNoIMAP folder (default INBOX); subfolders use the server's delimiter, e.g. INBOX.Invoices
accountYesMail account ID
enabledNo
filter_toNo
pdf_layoutNoMail-to-PDF layout: 0=system default, 1=text then HTML, 2=HTML then text, 3=HTML only, 4=text only
assign_tagsNo
filter_bodyNo
filter_fromNo
maximum_ageNoOnly mails younger than this many days (default 30)
filter_subjectNo
attachment_typeNo1=attachments only (default), 2=all files including inline
stop_processingNoSkip later rules once this rule queued a document
action_parameterNo
assign_title_fromNo1=mail subject (default), 2=attachment filename, 3=don't assign
consumption_scopeNo1=attachments only (default), 2=whole mail as .eml, 3=.eml plus attachments as separate documents
assign_correspondentNo
assign_document_typeNo
assign_owner_from_ruleNo
assign_correspondent_fromNo1=don't assign (default), 2=sender mail address, 3=sender name (falls back to address), 4=the correspondent in assign_correspondent. ⚠️ 2 and 3 CREATE a new correspondent for every distinct sender string — the usual cause of duplicate correspondents. Prefer 4, or 1 plus matching rules on existing correspondents.
filter_attachment_filename_excludeNoSkip attachments whose whole filename matches
filter_attachment_filename_includeNoOnly attachments whose whole filename matches, e.g. *.pdf

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.2.0

TDQS

B3.1/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows it mutates but is not destructive. The description adds no behavioral context beyond 'Create', such as side effects, permissions, or how rules interact with existing mail processing. This falls short of the burden when annotations are minimal.

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, front-loaded with the core action and resource, and communicates the essential function without waste. It is appropriately concise for a tool with a rich schema that carries parameter-level 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?

This tool has 25 parameters, no output schema, and only a two-parameter minimal requirement. A one-line description is not enough for an agent to know how to construct a valid request, what the response looks like, or what important constraints exist. The schema covers some parameters but the description does not fill the gaps for the rest.

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 52% schema description coverage, the schema already documents many parameters. However, the description's summary ('which folder and mails to consider, which attachments to import, and what to assign') doesn't map to specific parameter names or add meaning beyond what parameter names like folder, filter_from, attachment_type, and assign_* already imply. It fails to compensate for the undocumented 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 uses a specific verb ('Create') and resource ('mail rule'), and states what the rule controls (folder, mails, attachments, assignments). It clearly distinguishes from siblings like update_mail_rule or delete_mail_rule by the create verb and the high-level behavior described.

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 use this tool versus update_mail_rule, delete_mail_rule, or process_mail_account. The description does not mention conditions, prerequisites, or alternatives, leaving the agent to infer usage 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.

Deploy Server

Other Tools