Provides tools for searching, retrieving, updating documents, and managing tags, correspondents, and document types in Paperless-ngx.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@paperless-mcp search for documents with tag 'urgent'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server exposing Paperless-ngx document management via its REST API.
A Model Context Protocol (MCP) server that wraps the Paperless-ngx REST API, enabling Claude and other AI models to:
Search and retrieve documents
Get full document content and metadata
Update document metadata (title, correspondent, document type, tags)
List available tags, correspondents, and document types
Check Paperless-ngx system status
Related MCP server: KnowledgeMCP
npm installSet these environment variables before starting:
PAPERLESS_URL — required, e.g. http://paperless.local:8000
PAPERLESS_TOKEN — required, API token from Paperless-ngx (obtained via /api/token/)
PAPERLESS_TIMEOUT_MS — optional, default 15000 ms
# Login to Paperless-ngx and go to Settings > Profile > REST API Tokens
# Or obtain programmatically:
curl -X POST http://paperless.local:8000/api/token/ \
-H "Content-Type: application/json" \
-d '{"username":"your-user","password":"your-pass"}'# Start the MCP server (reads from stdin, writes to stdout)
PAPERLESS_URL="http://paperless.local:8000" \
PAPERLESS_TOKEN="your-token" \
node dist/index.jsOr use the bin alias:
npm run build
PAPERLESS_URL="..." PAPERLESS_TOKEN="..." \
./node_modules/.bin/paperless-mcpnpm run dev # Watch mode with tsx
npm run build # Compile TypeScript
npm run typecheck # Type-check without emitting
npm run lint # ESLint (mikey-pro)
npm run format # Prettier
npm test # VitestAll checks must pass before committing:
npm run typecheck && npm run lint && npm test && npm run buildThe MCP server registers 8 tools:
paperless_health — System status (database, task count)
search_documents — Full-text search with pagination
get_document — Fetch full document (including content)
update_document — Update title, correspondent, type, tags
list_tags — All available tags
list_correspondents — All available correspondents
list_document_types — All available document types
src/
index.ts — Entrypoint, stdio server setup
server.ts — Tool registration (8 tools)
paperless.ts — Paperless-ngx API client + types
paperless.test.ts — Comprehensive test suite (26 tests).gitea/workflows/ci.yml — Gitea Actions: lint, typecheck, test, build
.gitea/workflows/mirror.yml — Auto-mirror to GitHub on every push
MIT
Get the full content and metadata of a single Paperless-ngx document by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Document ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavior. It correctly indicates a read-only operation ('get'), but it does not mention potential errors (e.g., 404 if ID not found), authorization requirements, or rate limits. The phrase 'full content and metadata' is somewhat vague but adequate for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of extraneous words. Every word contributes to defining the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool with no output schema or annotations, the description adequately covers purpose and return type (full content and metadata). It does not describe the output structure but given the low complexity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter 'id' is fully described in the schema). The description adds no additional meaning beyond 'by ID', which echoes the schema. Baseline 3 is appropriate as the schema already handles semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'document', and the qualifier 'by ID', differentiating it from sibling tools like search_documents (which searches across documents) and update_document (which modifies). It specifies 'full content and metadata', giving a precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific document ID and need its complete data, but it does not explicitly state when this tool should be used over alternatives, nor does it mention restrictions or prerequisites beyond having an ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all correspondents defined in Paperless-ngx with their IDs and document counts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the tool lists all correspondents with IDs and counts, but does not mention read-only nature, authentication needs, or any side effects. For a read operation, transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is efficiently front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description provides sufficient context for a simple list-all operation. It does not mention pagination or limits, but for a tool with no inputs, it is likely unpaginated. The information is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100% for zero params). The description adds meaning by specifying that the output includes IDs and document counts, which is not evident from the empty schema. According to the baseline for zero parameters, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'correspondents', and specifies that IDs and document counts are included. It distinguishes the tool from siblings like 'list_document_types' and 'list_tags' by naming the specific resource, but does not contrast them directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_tags' or 'list_document_types'. It lacks explicit context for usage, such as prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all document types defined in Paperless-ngx with their IDs and document counts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states what is returned, but does not disclose safety (read-only), authentication requirements, or any side effects. For a simple list tool, this minimally meets transparency but lacks important context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no verbosity, directly states purpose. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description adequately explains what the tool returns. Could potentially mention if the list is paginated or sorted, but not critical for a simple list-all operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; description adds meaning by specifying the output includes IDs and document counts. Schema coverage is 100% vacuously, so description fulfills the need for parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists all document types with IDs and counts. Distinguishes from siblings (e.g., list_correspondents, list_tags) by naming the specific entity 'document types'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The task is simple listing, so context is implied but not stated. Could mention that this is for retrieving metadata only, not for filtering or searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tags defined in Paperless-ngx with their IDs and document counts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses that the tool returns IDs and document counts. It does not explicitly state that it is read-only or mention any side effects, though listing tools are generally safe. The description adds value over no description but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with 13 words, conveying the essential information without any waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description is fairly complete: it states the action, scope, and return content (IDs and document counts). It could mention ordering or pagination, but that is not critical for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description does not need to add parameter meaning. The baseline for no parameters is 4, and the description correctly omits param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'all tags' in Paperless-ngx, specifying return fields (IDs and document counts), distinguishing it from sibling tools that operate on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like list_correspondents or search_documents, but the context implies it for listing all tags. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Paperless-ngx status (database status and available tasks — connectivity check)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool retrieves status (database and tasks) and implies a connectivity check, but does not elaborate on whether it is read-only or any side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical clarification, front-loading the key action 'Get Paperless-ngx status'. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and a simple health check, the description is mostly complete. It could elaborate on what specific tasks are checked, but it is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. Description does not need to add parameter info; schema coverage is effectively 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Get' and the resource 'Paperless-ngx status', specifying it checks database status and available tasks for connectivity. This clearly distinguishes it from sibling tools that focus on documents, correspondents, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking system health, but does not explicitly state when to use this tool versus alternatives like get_document or list_correspondents. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Paperless-ngx documents by full-text query, returns summaries with IDs
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for paginated results (default: 1) | |
| query | Yes | Full-text search query string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially carries the behavioral burden. It states 'returns summaries with IDs', indicating a read operation, but does not disclose pagination behavior (despite the page parameter in schema), rate limits, or outcomes like empty result handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, no redundant words, and directly states the purpose and output. It is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 2 parameters and no output schema, the description is somewhat complete but lacks details on pagination, error conditions, or result format beyond 'summaries with IDs'. It is adequate but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters described. The description adds minimal value beyond schema, only hinting at output (summaries with IDs). Baseline 3 is appropriate as schema already documents parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search', the resource 'Paperless-ngx documents', the method 'full-text query', and the output 'returns summaries with IDs'. This distinguishes it from sibling tools like get_document (single document retrieval) and list_* tools (listing entities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for full-text search but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_document for specific document, list_* for enumerations). No 'when not to use' or prerequisite conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update metadata fields (title, correspondent, document type, tags, created date) on a Paperless-ngx document
| Name | Required | Description | Default |
|---|---|---|---|
| correspondent | No | Correspondent ID to assign, or null to clear | |
| created | No | Document creation date in ISO 8601 format (e.g. 2024-01-15T00:00:00Z) | |
| document_type | No | Document type ID to assign, or null to clear | |
| id | Yes | Document ID to update | |
| tags | No | Array of tag IDs to assign (replaces existing tags) | |
| title | No | New document title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'update', indicating mutation, but does not state whether the update is partial or full, if changes are reversible, required permissions, error behavior, or idempotency. The schema adds some detail (tags replace, fields nullable) but the description does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 14 words that is front-loaded and to the point. Every part is relevant, but it could be slightly expanded to include key behavioral notes without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return behavior, partial update semantics, validation rules, or error conditions, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description lists the updatable fields but adds no additional meaning beyond what the schema provides. It does not explain relationships between parameters or constraints beyond the field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates specific metadata fields (title, correspondent, document type, tags, created date) on a Paperless-ngx document. It uses a verb ('Update') and resource ('document metadata'), and distinguishes it from sibling tools like get_document (read) and list_correspondents (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It does not mention prerequisites, when not to use, or compare with sibling tools. The description implies usage for updating metadata but lacks explicit contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_documentlist_correspondentslist_document_typeslist_tagspaperless_healthsearch_documentsupdate_documentScored across 7 tools
Each tool has a clear and distinct purpose: retrieving a single document, searching documents, updating documents, listing correspondents/types/tags, and checking health. No overlap or ambiguity.
Tool names consistently follow a verb_noun pattern in snake_case (e.g., get_document, list_tags, search_documents). Even 'paperless_health' follows the pattern with a noun_noun structure, maintaining readability.
With 7 tools, the set is well-scoped for a Paperless-ngx MCP server. It covers core operations without being overwhelming or too sparse.
The tool set is missing crucial operations: no create_document or delete_document, and no ability to create, update, or delete correspondents, document types, or tags. This leaves significant gaps in document lifecycle management.
DocBase MCP server for AI agents
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
