FeedKeeper RSS/Atom reader and remote MCP Server

Subscribe to a feed

subscribe_feed

Subscribes the current user to an RSS/Atom feed or website URL, auto-discovering the feed link. Re-subscribing returns the existing subscription record.

Instructions

Subscribes the current user to an RSS/Atom feed URL or website URL (auto-discovering the feed link if a website URL is provided). Requires write scope. Idempotent: subscribing to an already subscribed feed returns the existing subscription. Returns the subscription record.

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": {
      "url": "<url>"
    },
    "name": "subscribe_feed"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	The RSS/Atom feed URL or website URL to subscribe to
`label`	No	Optional custom display name for this feed subscription
`folderId`	No	Optional folder/category ID to place the new subscription in

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.36.4Nov 9, 2026

changedInput schema / properties / folderId / description

Previous value: -"Optional folder/category ID"New value: +"Optional folder/category ID to place the new subscription in"

changedInput schema / properties / label / description

Previous value: -"Optional display name for this feed"New value: +"Optional custom display name for this feed subscription"

changedInput schema / properties / url / description

Previous value: -"The feed URL or website URL"New value: +"The RSS/Atom feed URL or website URL to subscribe to"

First observedv0.36.3Nov 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the write-scope authorization requirement, idempotent behavior on duplicate subscriptions, auto-discovery of feed links from website URLs, and that the subscription record is returned. It omits failure behavior when a URL is not a valid feed and any rate-limit or error semantics.

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 short sentences, front-loaded with the core action, then auth, then idempotency and return value. No redundant or filler wording.

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 simple three-parameter mutation with no output schema and no annotations, the description covers the essentials an agent needs: what it creates, the permission requirement, duplicate-subscription semantics, and the return value. Nothing critical is left to inference.

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%, so all three parameters are already documented in the schema. The description reiterates the dual URL interpretation but adds no meaning for label or folderId, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Subscribes the current user to an RSS/Atom feed URL or website URL") and clarifies the auto-discovery fallback for website URLs, which implicitly separates it from discover_feeds. It stops short of naming or contrasting with any sibling tool explicitly.

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 implied by the action itself and the "Requires write scope" prerequisite is stated, but there is no explicit when-to-use/when-not guidance or routing advice (e.g., when to call discover_feeds first versus relying on auto-discovery, or how this relates to import_opml).

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