FeedKeeper RSS/Atom reader and remote MCP Server

Refresh feed poll

refresh_feed

Triggers an immediate poll of a subscribed feed and returns its health status, new item count, and any error or backoff deferral for on-demand update checks.

Instructions

Requests an immediate poll of a subscribed feed from its origin URL and returns its updated health status, number of new items found, and error state. Respects origin HTTP cache headers and backoff pauses. Returns { success: boolean, newItems: number, error: string | null, deferred: boolean, retryAt: string | null, feed: object }.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "feedId": "<feedId>"
    },
    "name": "refresh_feed"
  }
}

Input Schema

Name	Required	Description	Default
`feedId`	Yes	The numeric ID of the subscribed feed to refresh

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.36.4Nov 9, 2026

changedInput schema / properties / feedId / description

Previous value: -"The ID of the feed to refresh"New value: +"The numeric ID of the subscribed feed to refresh"

First observedv0.36.3Nov 9, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations supplied, the description does substantial work: it discloses that origin HTTP cache headers are respected, that backoff pauses can suppress a poll, and that a call may be 'deferred' with a retryAt timestamp rather than executed. That deferred/retry contract is exactly the kind of behavior an agent cannot get from the schema. It stops short of stating whether the call mutates stored feed state (last-polled, health) or any rate-limit/auth constraints.

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?

Two sentences, front-loaded with the action and its scope. The second sentence enumerates the return shape, which earns its place precisely because no output schema is declared, and the cache/backoff caveat is packed into the first sentence without padding.

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 one-parameter tool with no annotations and no output schema, the description covers the action, the caching/backoff constraints, the deferred outcome, and the full return shape. The remaining gap is failure/edge semantics — what an invalid feedId or persistent origin error does to the subscription.

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?

There is a single parameter (feedId) with 100% schema description coverage, so the schema already fully documents it and the baseline of 3 applies. The description adds no additional semantic detail such as what happens for an unsubscribed or invalid feedId.

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 action ('requests an immediate poll') on a specific resource ('a subscribed feed') and names the source of truth ('from its origin URL'), which separates it from cache-reading siblings such as get_feed, list_items, and get_new_items. The verb+resource+scope combination is unambiguous.

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

Usage Guidelines3/5

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

Usage is only implied: the agent must infer that this is the tool to reach for when it needs fresh-from-origin data rather than stored items. There is no explicit when-to-use statement, no mention of a sibling alternative (e.g. get_new_items for already-polled data), and no guidance on when not to call it (e.g. repeated calls, already-deferred feeds).

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