list_saved_viewsList saved views in Paperless-NGX with optional pagination. Get an overview of your saved filter configurations to reuse or manage them.
List saved views.
Visibility flags are null when payload v10 omits those preferences.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No |
| Name | Required | Description | Default |
|---|---|---|---|
| next | No | ||
| count | Yes | ||
| results | No | ||
| previous | No |
Changes observed during successful MCP inspections.
v2.1.0Output schema / properties / results / items / properties / show_in_sidebar / anyOfAdded value: +[
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / results / items / properties / show_in_sidebar / defaultPrevious value: -falseNew value: +nullOutput schema / properties / results / items / properties / show_in_sidebar / typeRemoved value: -"boolean"Output schema / properties / results / items / properties / show_on_dashboard / anyOfAdded value: +[
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / results / items / properties / show_on_dashboard / defaultPrevious value: -falseNew value: +nullOutput schema / properties / results / items / properties / show_on_dashboard / typeRemoved value: -"boolean"v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds one useful behavioral detail: visibility flags can be null when payload v10 omits them. It does not mention pagination behavior, ordering, or empty-result handling, so it only partially fleshes out the behavior.
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 compact at two sentences. The first sentence restates the tool name without new information, but the second sentence adds a meaningful edge case. There is no filler, and the important note is placed clearly.
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?
This is a simple paginated list endpoint with an output schema and read-only annotations, so the description does not need to explain return values or safety. The visibility-flags note covers a relevant quirk. The main omission is any statement about how pagination parameters affect results, but those are largely inferable from the schema.
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?
The description adds no explanation for the page or page_size parameters, and schema description coverage is 0%. However, the schema itself includes meaningful defaults, minimums, and maximums that make the pagination parameters reasonably self-explanatory. Still, the description does not compensate for the lack of property descriptions.
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 states a specific verb and resource: 'List saved views.' This is unambiguous and clearly distinct from the sibling get_saved_view, which retrieves a single item. It is nearly identical to the title, and a more explicit scope statement would earn a 5, but the intent is plain.
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 is given about when to use list_saved_views versus get_saved_view or other list alternatives. The agent is left to infer from the name alone. There are no stated prerequisites, exclusions, or scenarios mentioning the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.