Skip to main content
Glama
Panda Federation Tools

Panda Federation Tools

RSS & Atom Feed Monitor: Only New Items

rss_feed_monitor
Read-only

Monitor multiple RSS, Atom, JSON Feed, or website URLs and return only new items since the last run, with optional keyword filtering for digests.

Instructions

Watch many RSS 2.0, Atom or JSON Feed URLs, or plain website and blog URLs (the feed is found automatically), and return one row per item with title, link, published date, age, author, plain-text summary, categories, enclosure and matched keywords. With onlyNew (default true) the Actor remembers returned items per stateKey in a named key-value store in your account, so scheduled runs return and bill only items that are new since the last run. Unlike website_change_monitor (diffs a whole page) and federal_register_monitor (US rulemaking only), this follows any site's feed. Use when you need a daily digest of competitor blogs, news, regulator or vendor feeds, filtered by keywords. Do not use for pages without a feed (use website_change_monitor), for full article text or for private or internal addresses (blocked and never billed). Parameters: feeds (up to 500); keywords and excludeKeywords match title, summary and categories; maxAgeHours skips old items; onlyNew and stateKey control the memory (use a different stateKey per watch list); maxItemsPerFeed (default 50); summaryChars (default 500); maxResults caps billed items. Items already seen, failed feeds and empty runs are free; per-feed health is in FEED_STATUS. Returns per item: agentSummary, feedTitle, feedUrl, siteUrl, title, link, published, ageHours, author, summary, categories, enclosureUrl, matchedKeywords, itemKey; plus RSS_XLSX/CSV.

Behavior: read-only; runs the Apify Actor pandadad0214/rss-feed-monitor (https://apify.com/pandadad0214/rss-feed-monitor) on your own Apify account. Price: $0.0005 per feed item returned. Runs that find nothing are not charged per result, and spending is capped per call by run_max_charge_usd (default $0.50). run_max_items (default 50) limits items returned and fills maxResults when you leave it unset, so it also limits what is billed; setting maxResults higher can bill more than is returned. Most calls finish in 5-15 s for a few inputs; large inputs or crawls can take minutes, so raise run_timeout_secs (max 300) or shrink the input after a timeout error. Returns JSON {actor, count, items}; long text output is trimmed to whole items, with all items in structuredContent.

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

Input Schema

NameRequiredDescriptionDefault
feedsNoFeeds or websites. RSS, Atom or JSON Feed URLs, or plain website/blog URLs (the feed is found automatically). Up to 500 per run.
onlyNewNoOnly new items since last run. Default on. Remembers returned items (per state key) in a named key-value store, so scheduled runs return and charge only new items.
keywordsNoKeywords (any). Keep items whose title, summary or categories contain any of these words (case-insensitive). Empty = keep all.
stateKeyNoState key. Separate memory for different watch lists, e.g. competitors or regulators. Default: default.
maxResultsNoMaximum results. You pay per item returned, so this also caps the cost. Default 500.
maxAgeHoursNoMaximum age (hours). Skip items older than this. 0 or empty = any age. Undated items are kept.
summaryCharsNoSummary length (characters). Plain-text summary length per item. Default 500.
run_max_itemsNoOptional. Most results to return from this call (default from PANDA_MAX_ITEMS, 50). Also limits how many results the Actor produces and charges for, unless you set its own max field.
excludeKeywordsNoExclude keywords. Drop items containing any of these words.
maxItemsPerFeedNoMax items per feed. Newest N items considered per feed. Default 50.
run_timeout_secsNoOptional. Seconds to wait for results (default from PANDA_TIMEOUT_SECS, 120; max 300).
run_max_charge_usdNoOptional. Hard spending cap for this call in USD (default from PANDA_MAX_CHARGE_USD, 0.50).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-destructive; the description adds substantive behavior beyond that: per-stateKey memory in a key-value store, which items are free (seen, failed, empty runs), per-item pricing ($0.0005), a hard run_max_charge_usd cap, typical 5-15s latency with a 300s timeout ceiling, and FEED_STATUS health reporting. The 'onlyNew' memory model is consistent with idempotentHint=false and the read-only framing matches readOnlyHint=true.

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 sibling routing are front-loaded, and nearly every clause carries operational value. The second half is a dense run-on of parameter and billing details with limited formatting, which makes it harder to scan than it needs to be, but little is genuinely redundant.

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?

There is no output schema, and the description compensates by enumerating the returned per-item fields (agentSummary, itemKey, matchedKeywords, etc.) and the RSS_XLSX/CSV side outputs. For a paid, stateful, potentially long-running Actor call, cost caps, timeouts and memory semantics are all covered.

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?

At 100% schema coverage the baseline is 3, but the description adds cross-parameter semantics the schema does not convey: run_max_items fills maxResults when unset and also governs billing, and 'setting maxResults higher can bill more than is returned'. It also advises one stateKey per watch list. Note that maxResults is stated as default 500 in the schema while the description implies 50 via run_max_items, a small inconsistency worth flagging.

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 concrete verb and resource ('Watch many RSS 2.0, Atom or JSON Feed URLs... and return one row per item') plus the exact row shape. It also explicitly differentiates from siblings by naming website_change_monitor and federal_register_monitor and describing how this differs ('follows any site's feed').

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 guidance ('Use when you need a daily digest of competitor blogs, news, regulator or vendor feeds, filtered by keywords') and explicit exclusions with alternatives ('Do not use for pages without a feed (use website_change_monitor), for full article text or for private or internal addresses'). The only minor gap is not naming a tool for the full-article-text case, but the routing decision is unambiguous.

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