FeedKeeper Cloud

Paginate items chronologically with cursors

list_items

Read-onlyIdempotent

Lists articles chronologically with bidirectional cursor-based pagination. Use this tool for comprehensive browsing or historical paging through both read and unread articles. Pass nextCursor as 'before' to page backwards into older history, or newestCursor as 'after' to stream newly added items. Do NOT use for quick digests (use get_digest) or unread-only triage (use get_new_items).

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": "list_items"
  }
}

Input Schema

Name	Required	Description
`after`	No	Cursor to fetch newer items (pass newestCursor from a previous page)
`limit`	No	Number of items to fetch per page (1 to 100, default: 20)
`since`	No	Filter for items published at or after this ISO date or date-time
`until`	No	Filter for items published at or before this ISO date or date-time
`before`	No	Cursor to fetch older items (pass nextCursor from a previous page)
`feedId`	No	Optional feed ID filter
`folderId`	No	Optional folder ID filter
`unreadOnly`	No	When true, only lists unread articles; default is false (all articles)
`bookmarkedOnly`	No	When true, only lists bookmarked articles

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, so the safety profile is covered and the description's job is to add beyond it. It does add ordering semantics, bidirectional paging direction, and the asymmetry that 'after' streams newly added items, which the annotations do not convey. It stops short of describing termination of paging or what a page returns, leaving a small gap.

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, zero waste: capability and pagination model first, concrete usage second, exclusions last. The most decision-relevant scoping is front-loaded and easy to scan.

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 nine-parameter read tool with no output schema, the description covers intent, directionality of cursors, and sibling routing, which is most of what an agent needs. It omits practical details such as paging termination, default page size, and cursor field names in the response, but those are secondary given full schema coverage.

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

Parameters3/5

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

Schema coverage is 100%, so every parameter is already documented, including the cursor provenance hints. The description restates the before/after direction mapping but adds no format, limit, or interaction detail (e.g. how cursor params combine with since/until) beyond the schema. Baseline 3 is appropriate.

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 verb and resource (lists articles) plus ordering (chronologically) and mechanism (bidirectional cursor-based pagination). It explicitly names the sibling tools it is not (get_digest, get_new_items), so it is distinguishable without opening any 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?

Gives positive when-to-use cases (comprehensive browsing, historical paging, both read and unread) and explicit exclusions routing to named alternatives: quick digests to get_digest and unread-only triage to get_new_items. No inference required.

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

All FeedKeeper Cloud tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?