sluicer

Overview Schema Source Related Servers Discussions Admin

Read a feed

read_feed

Read-onlyIdempotent

Reads RSS, Atom, or JSON Feed items from a URL or feed text, returning structured data with titles, links, dates, and content.

Instructions

Read a feed's items: RSS, Atom or JSON Feed.

url_or_text: an http(s) URL of a feed -- or of a page that declares one, which is followed to it -- or the feed itself. limit: the most items answered, 1 to 500; items_total says how many the feed holds.

Returns {"ok", "url", "format", "title", "link", "description", "items", "items_total"}, each item {"title", "link", "id", "published", "updated", "summary", "content", "authors", "categories", "enclosures", "normalised"}, dates in normalised as ISO 8601. What is not a feed, and declares none, is bad_input. Items that would make the answer weigh over 75,000 bytes are left out, counted in items_left_out; fetch_page reads the whole feed in slices.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	the most items answered, 1 to 500; items_total says how many the feed holds.
`url_or_text`	Yes	an http(s) URL of a feed -- or of a page that declares one, which is followed to it -- or the feed itself.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`url`	No
`link`	No
`error`	No
`fetch`	No
`items`	No
`title`	No
`format`	No
`updated`	No
`language`	No
`description`	No
`items_total`	No
`items_left_out`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.9.0Sep 26, 2026

changedOutput schema / $defs / ErrorDetail / description

Previous value: -"Why a tool could not answer.\n\n``retryable`` is true only for ``fetch_failed``, and on a crawled page for\n``rate_limited``: the same call may work later. The others need something\nto change first -- an install, an input, or the caller's mind about a site\nthat said no."New value: +"Why a tool could not answer.\n\n``retryable`` is true only for ``fetch_failed``, and on a crawled page for\n``rate_limited``: the same call may work later. Not every ``fetch_failed``\nis: a redirect loop, or an encoding this install cannot read, would be\nmet again. The others need something to change first -- an install, an\ninput, or the caller's mind about a site that said no."

changedOutput schema / $defs / ErrorDetail / properties / code / enum

Previous value: -[
-  "missing_extra",
-  "refused_by_robots",
-  "refused_address",
-  "fetch_failed",
-  "too_large",
-  "bad_input",
-  "tdm_reserved"
-]New value: +[
+  "missing_extra",
+  "refused_by_robots",
+  "refused_by_site",
+  "payment_required",
+  "refused_address",
+  "fetch_failed",
+  "too_large",
+  "bad_input",
+  "tdm_reserved"
+]

addedOutput schema / properties / items_left_out

Added value: +{
+  "title": "Items Left Out",
+  "type": "integer"
+}

Changed2 schema fields changedv0.7.0Sep 24, 2026

addedInput schema / properties / limit / description

Added value: +"the most items answered, 1 to 500; items_total says how many the feed holds."

addedInput schema / properties / url_or_text / description

Added value: +"an http(s) URL of a feed -- or of a page that declares one, which is followed to it -- or the feed itself."

First observedv0.1.0Sep 24, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already mark the tool readOnly, idempotent, and non-destructive, and the description adds substantial behavior beyond those: what happens for non-feed input (bad_input), the 75,000-byte response cap, items_left_out counting, ISO 8601 normalisation, and the distinction from fetch_page. No contradiction with annotations.

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

Conciseness3/5

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

The summary sentence is front-loaded and useful, but the description repeats the schema's parameter descriptions and enumerates return fields even though an output schema exists. It is readable and compact enough, yet not every sentence earns its place.

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?

The description covers accepted URL/text forms, response format, error behavior, truncation, and a relevant sibling alternative. One minor gap is that the returned object list omits items_left_out even though the prose says items left out are counted in it; this is a small internal inconsistency rather than a missing major behavior.

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 description coverage is 100%, and the description's parameter sentences are nearly verbatim duplicates of the schema text. The byte-size truncation behavior adds useful context around limit, but it does not add meaningfully finer parameter-level detail beyond what the schema already provides.

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 the specific action and resource: "Read a feed's items" and names the supported formats (RSS, Atom, JSON Feed). It also distinguishes itself from the sibling fetch_page by noting that fetch_page reads the whole feed in slices, so an agent can tell this tool focuses on bounded feed-item reading.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for accepted inputs: an http(s) URL of a feed, a page that declares a feed, or the feed text itself. It also hints at the alternative fetch_page for reading the whole feed without byte-based truncation, though it stops short of an explicit 'use this instead when...' rule.

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

Deploy Server