Paperless MCP

Paperless-NGX document management over MCP: search, tag, upload, and read documents; manage tags, correspondents, document types, and custom fields.

Documentation | Config wizard | PyPI | Docker

Features

• Document search & retrieval: full-text and filtered list queries against Paperless-NGX, plus access to extracted OCR text, metadata, and thumbnails.
• Tag, correspondent, document-type, custom-field management: full CRUD and bulk-edit for every classification dimension Paperless exposes.
• Document lifecycle supports uploads, field changes, notes, audit history, and AI-suggested tags/correspondents/types.
• Operational introspection covers saved views, storage paths, share links, background tasks (with wait_for_task), statistics, and remote Paperless-NGX version.
• MCP tools: 50 LLM-visible tools with Lucide icons and read-only gating; see src/paperless_mcp/tools/.
• MCP resources: 20 URIs exposing documents and domain collections; see src/paperless_mcp/resources/.
• Read-only mode: flip PAPERLESS_MCP_READ_ONLY=true to disable every mutating tool at startup.

What you can do with it

With this server mounted in an MCP client (Claude, etc.), you can:

• "Find last quarter's invoices from ACME." Composes search_documents with a correspondent filter, then streams matches via paperless://documents/{id}/content.
• "Tag these three documents as 'reviewed' and move them to the Accounting correspondent." Uses bulk_edit_documents in a single call.
• "Upload this PDF and wait until OCR finishes." Composes upload_document + wait_for_task so the assistant only reports back once the document is indexed.
• "What changed on document 4213 in the last week?" Reads paperless://documents/4213/history and summarises the audit trail.

Installation

From PyPI

pip install pvliesdonk-paperless-mcp

If you add optional extras via the PROJECT-EXTRAS-START / PROJECT-EXTRAS-END sentinels in pyproject.toml, document them below:

• pip install pvliesdonk-paperless-mcp[docs]: installs mkdocs-material and mkdocstrings[python] for building the documentation site locally (uv run mkdocs serve).

From source

git clone https://github.com/pvliesdonk/paperless-mcp.git
cd paperless-mcp
uv sync --all-extras --all-groups

Docker

docker pull ghcr.io/pvliesdonk/paperless-mcp:latest

To run the newest merged code instead of the newest release, use the rolling edge tag. It is rebuilt on every merge to main and carries no version identity. See Image tags for the full tag list.

docker pull ghcr.io/pvliesdonk/paperless-mcp:edge

A compose.yml ships at the repo root as a starting point. Copy .env.example to .env, edit, and docker compose up -d.

To attach a remote Python debugger (development only; the protocol is unauthenticated), see Remote debugging.

Linux packages (.deb / .rpm)

Download .deb or .rpm packages from the GitHub Releases page. Both install a hardened systemd unit; env configuration is sourced from /etc/paperless-mcp/env (copy from the shipped /etc/paperless-mcp/env.example).

Claude Desktop (.mcpb bundle)

Download the .mcpb bundle from the GitHub Releases page and double-click to install, or run:

mcpb install paperless-mcp-<version>.mcpb

Claude Desktop prompts for required env vars via a GUI wizard, with no manual JSON editing needed.

For manual Claude Desktop configuration and setup options, see Claude Desktop deployment.

Release channels

Artifacts ship on three channels. Each row lists exactly what that channel publishes.

Pre-releases reach PyPI so that a candidate's .mcpb bundle installs: the bundle points at PyPI rather than carrying the code. Ordinary installers never see them, because a PEP 440 resolver skips pre-releases unless the requirement pins one or you pass --pre. Ask for a candidate by name with pip install pvliesdonk-paperless-mcp==X.Y.ZrcN. PyPI spells it in the PEP 440 canonical form, while tags use SemVer. Rolling pointers are ordering-aware, so a patch release cut from an old release/X.Y branch never moves latest-style tags back to older content, and a candidate for an already-released version never moves rc. See Release process for the full model.

Quick start

paperless-mcp serve                                # stdio transport
paperless-mcp serve --transport http --port 8000   # streamable HTTP

For library usage (embedding the domain logic without the MCP transport), import from the paperless_mcp package directly. See the project's domain modules under src/paperless_mcp/ for entry points.

Server info

The server registers a built-in get_server_info tool (via fastmcp_pvl_core.register_server_info_tool) so operators can confirm the deployed version with a single MCP call. The default response carries server_name, server_version, and core_version. Servers that talk to a remote upstream wire upstream version reporting inside the DOMAIN-UPSTREAM-START / DOMAIN-UPSTREAM-END sentinel in src/paperless_mcp/server.py; see CLAUDE.md for the wiring pattern.

Configuration

All settings come from environment variables with the PAPERLESS_MCP_ prefix.

Required

Optional (with defaults)

See the Transport & Auth section below for the inherited transport, auth, and logging variables.

Transport & Auth

The following variables are inherited unchanged from fastmcp-server-template:

Tools

Documents

get_document, list_documents, search_documents, and update_document include a web_url field pointing to the document in the Paperless UI, such as https://paperless.example.com/documents/42/. Set PAPERLESS_MCP_PAPERLESS_PUBLIC_URL if the public URL differs from the API URL; otherwise the API URL is used.

Paginated tools return next/previous as bare page=N markers (never full URLs). Callers pass page=N explicitly when walking pages. None means no further page.

Tags

Correspondents

Document Types

Custom Fields

Observability

Resources

Shared template variables

Inherited from fastmcp-pvl-core across all services built on the template:

Domain-specific variables go below under Domain configuration.

Authentication

Callers authenticate via a bearer token or OIDC (mutually exclusive). See the Authentication guide for setup, mapped multi-subject tokens, OIDC, and troubleshooting.

Post-scaffold checklist

After copier copy and gh repo create --push:

1. Fill in the DOMAIN blocks (every section marked with a DOMAIN sentinel comment) in this README and in CLAUDE.md. The GENERATED-ENV-TABLE-* regions are not DOMAIN blocks; the config generator owns them and rewrites them on every run.
2. Configure GitHub secrets (see below).
3. Install dev + docs tooling: uv sync --all-extras --all-groups.
4. Install pre-commit hooks: uv run pre-commit install.
5. Run the gate locally: uv run pytest -x -q && uv run ruff check --fix . && uv run ruff format . && uv run mypy src/ tests/.
6. Push the first commit. CI should be green.

GitHub secrets

CI workflows reference three repository secrets. Configure them via Settings → Secrets and variables → Actions or with gh secret set:

gh secret set RELEASE_TOKEN
gh secret set CODECOV_TOKEN
gh secret set CLAUDE_CODE_OAUTH_TOKEN

Dependency updates are handled by Renovate (renovate.yml), which reuses RELEASE_TOKEN. It maintains uv.lock and auto-merges patch/minor bumps once the CI Success check is green; bootstrap.yml enables auto-merge and applies the repository rulesets (.github/rulesets/) on first push. See Repository Protection for the per-branch posture and bypass model. GitHub Actions are updated in the copier template and arrive via copier update, not per-repo.

GITHUB_TOKEN is auto-provided; no action needed.

Local development

The PR gate (matches CI):

uv run pytest -x -q                                  # tests
uv run ruff check --fix . && uv run ruff format .    # lint + format
uv run mypy src/ tests/                              # type-check

Pre-commit runs a subset of the gate on each commit; see .pre-commit-config.yaml for details, or CLAUDE.md for the full Hard PR Acceptance Gates.

Troubleshooting

Moving a scaffolded project

uv sync creates .venv/bin/* scripts with absolute shebangs pointing at the venv Python. If you move the repo after scaffolding (mv /old/path /new/path), uv run pytest fails with ModuleNotFoundError: No module named 'fastmcp' because the stale shebang resolves to a different interpreter than the venv's site-packages.

Fix:

rm -rf .venv
uv sync --all-extras --all-groups

uv run python -m pytest also works as a one-shot workaround (bypasses the stale entry-script shim).

uv.lock refresh after copier update

When copier update introduces new dependencies (such as a new extra added to pyproject.toml.jinja), the CI install step runs uv sync --locked, which fails against a stale lockfile. Run uv lock locally and commit the refreshed uv.lock alongside accepting the copier-update PR.

CI installs with --locked (and the review workflow with --frozen) so no job ever rewrites uv.lock in its own workspace: a job that re-locks hides the drift it just repaired, and a dirty workspace breaks any later git checkout in the same job. Lockfile drift then shows up as a red install step with a clear message, not as a silent mutation.

Links

• Documentation
• llms.txt
• FastMCP
• fastmcp-pvl-core

Domain configuration

Domain environment variables use the PAPERLESS_MCP_ prefix:

Domain-config fields are composed inside src/paperless_mcp/config.py between the CONFIG-FIELDS-START / CONFIG-FIELDS-END sentinels; env reads go through fastmcp_pvl_core.env(_ENV_PREFIX, "SUFFIX", default) so naming stays consistent, and field invariants go in __post_init__ between the CONFIG-VALIDATE-START / CONFIG-VALIDATE-END sentinels. Each field's metadata help and tags generate the table above directly, so keep them accurate and complete.

Key design decisions

• Read-only gating at startup, not per-call. PAPERLESS_MCP_READ_ONLY=true skips registration of every mutating tool so they simply are not part of the advertised tool surface. Clients cannot invoke a write that will be refused.
• HTTP layer retries idempotent reads only. PAPERLESS_MCP_HTTP_RETRIES applies to GETs on 5xx/network errors; writes never retry automatically, to avoid double-applying bulk edits or uploads.
• Tool icons come from Lucide. Every tool carries a Lucide icon hint so MCP clients that render icons (Claude Desktop) get a coherent visual surface. See src/paperless_mcp/tools/_icons.py.
• Models accept unknown upstream fields. Pydantic models use lenient validation for list-endpoint responses so newer Paperless-NGX versions do not break the client (the Document.some_future_paperless_field test pins this behaviour).
• No prompts ship in v1. prompts.py is intentionally empty; prompts land as concrete user-workflow patterns emerge in practice.