inoreader-mcp

Get saved web pages

get_saved_web_pages

Read-onlyIdempotent

List saved web pages and filter them for cleanup candidates, including pages neither starred nor tagged 'Keep'. Count matching pages or return compact details for review.

Instructions

List saved web pages (manually saved URLs, not from RSS feeds). Supports filtering to find cleanup candidates. Pages can be protected from cleanup by starring or tagging with 'Keep' (via manage_tags add_tag='Keep'). Use filter 'removable' to find pages that are neither starred nor kept -- candidates for review, not authorization to remove. Both count_only and listing apply the filter server-side via the Inoreader API. Set count_only=true to count one filtered IDs page (up to 10000 IDs, with continuation and total_is_exact; not necessarily a collection total) without content (1 Z1 request). Costs 1 Z1 request per page otherwise. Base costs exclude safe-read retries (up to 4 attempts, each counted); honor cached status/cooldown. Never blindly replay uncertain writes. See inoreader://usage for limits, URI examples and prompts.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_saved_web_pages"
  }
}

Input Schema

Name	Required	Description
`count`	No	Number of pages to fetch (1-100, default 100)
`filter`	No	Filter pages (default: all). 'removable' returns pages that are neither starred nor tagged 'Keep' -- the best filter for cleanup. 'unstarred' excludes starred only. The filter is applied server-side and respected by count_only.
`compact`	No	Return only id, title, source, is_starred, is_kept (default false).
`count_only`	No	Count one filtered IDs page, not page details (default false). Check total_is_exact and continuation; at most 10000 IDs per call.
`continuation`	No	Continuation token for pagination

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.1Nov 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description goes further with cost disclosure (1 Z1 request per page, count_only costs 1 Z1 request), retry semantics (up to 4 safe-read attempts, each counted), cooldown/cached-status handling, and the warning never to blindly replay uncertain writes. It stops short of describing the return payload shape, but with no output schema that is a smaller gap for a list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and scoping come first, then filters, then cost/retry mechanics, which is a sensible front-loaded order. It is dense and slightly repetitive in restating that the filter is server-side and respected by count_only (already in the schema's filter description), but almost every sentence carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter, optional-only list tool with no output schema, the description covers the missing pieces an agent needs: cost model, pagination/continuation caveats on counting, filter semantics, retry and cooldown behavior, and a pointer to further docs. Nothing needed to call it correctly appears absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the filter is applied server-side for both listing and count_only, and count_only is clarified as counting one filtered IDs page (up to 10000 IDs, with continuation and total_is_exact) that is 'not necessarily a collection total'. That resolves an ambiguity an agent would otherwise misread as a total count.

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 opens with a specific verb and resource, 'List saved web pages', and immediately scopes it with '(manually saved URLs, not from RSS feeds)', which effectively distinguishes it from the RSS-oriented sibling get_saved_items without the agent needing either schema.

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?

It states concrete when-to-use paths: filter='removable' for finding cleanup candidates, count_only=true for cheap counting, and manage_tags add_tag='Keep' to protect a page. It also adds a guardrail that 'removable' is 'candidates for review, not authorization to remove', and points to inoreader://usage for prompts and limits.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.