Skip to main content
Glama

create_workflow_action

Create a discrete Paperless-NGX workflow action (assignment, email, webhook, or trash) to serve as a reusable automation step. Use it when configuring workflows for document processing.

Instructions

Create ONE standalone workflow action. On its own an action does nothing, and Paperless deletes actions that belong to no workflow whenever any workflow is updated. To build an automation, use create_workflow with the actions inline; to change an action inside a workflow, use update_workflow (or update_workflow_action with the action id from get_workflow).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesAction type: 1=assignment, 2=removal, 3=email, 4=webhook, 5=password removal (needs passwords), 6=move to trash, 7=remote OCR (its workflow must have a type-1 consumption-started trigger), 8=apply AI suggestions (needs ai_suggestion_fields; its workflow must have a trigger other than type 1)
emailNoType 3: email configuration
webhookNoType 4: webhook configuration
passwordsNoType 5 (required): PDF passwords to try, in order. The unlocked file is stored as a new version of the document. Tools return them masked ("**********"); send a masked list back unchanged to keep the stored passwords.
assign_tagsNo
remove_tagsNo
assign_ownerNo
assign_titleNoType 1: Jinja2 title template
remove_ownersNo
remove_all_tagsNo
ai_create_missingNoType 8: create suggested tags/correspondents/document types/storage paths that don't exist yet
assign_view_usersNo
remove_all_ownersNo
remove_view_usersNo
assign_view_groupsNo
remove_view_groupsNo
assign_change_usersNo
assign_storage_pathNo
remove_change_usersNo
ai_suggestion_fieldsNoType 8 (required): which AI suggestions to apply. Needs AI enabled in Paperless.
assign_change_groupsNo
assign_correspondentNo
assign_custom_fieldsNoType 1: custom field IDs to add
assign_document_typeNo
remove_change_groupsNo
remove_custom_fieldsNo
remove_storage_pathsNo
ai_overwrite_existingNoType 8: apply suggestions even when the document already has a value
remove_correspondentsNo
remove_document_typesNo
remove_all_permissionsNo
remove_all_custom_fieldsNo
remove_all_storage_pathsNo
remove_all_correspondentsNo
remove_all_document_typesNo
assign_custom_fields_valuesNoType 1: values for assign_custom_fields keyed by custom field ID, e.g. {"7": "2026-01-01"}. The value for the custom field. For monetary fields, use currency code prefix format (e.g., USD10.00, GBP123.45, EUR9.99) — NOT trailing symbol format (e.g., 10.00$). For documentlink fields, use a single document ID (e.g., 123) or an array of document IDs (e.g., [123, 456]).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.2.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, the description reveals a critical side effect: Paperless deletes unassigned actions whenever any workflow is updated. It also clarifies that a standalone action is inert, giving an agent the exact risk model before invoking a non-read-only tool.

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 the warning front-loaded before the routing advice. Every sentence earns its place and none repeats schema or annotation 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?

For a 36-parameter, side-effect-prone creation tool with no annotations and no output schema, the description covers behavior, risk, and sibling routing well. It is missing only a note on what the tool returns (e.g., the created action id), which an agent would need without an output schema.

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 description text itself adds no parameter guidance, and with only 28% schema coverage it does not compensate for the roughly 26 parameters lacking schema descriptions. The strong type-code mapping lives in the schema, not in the tool description, so this dimension falls short despite the rich conditional objects.

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 action ('Create ONE standalone workflow action') and immediately clarifies what it is not: a standalone action does nothing on its own. This differentiates it from create_workflow, so an agent can select it correctly.

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?

Explicitly names the alternatives and the conditions that select them: use create_workflow with inline actions for automation, and update_workflow/update_workflow_action for modifying an existing action. The 'standalone' framing plus exclusion of the obvious sibling leaves no ambiguity.

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