Skip to main content
Glama
Sign In
inoreader-mcp

inoreader-mcp

by justmytwospence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Replace a feed subscription

replace_feed
Destructive

Replaces a subscription with a new feed URL while keeping its title and folders, then unsubscribes the old feed after the new one is confirmed.

Instructions

Replace a subscription with a different feed URL, keeping its title and folders: subscribe to the new feed, put it in the same folders under the same title, confirm that landed, and only then unsubscribe the old one. If the new feed is already subscribed, its folders are topped up and the old one is removed. Read state of the old feed is not carried over. Use with find_feed_replacement. Costs 2-3 Zone 2 requests and 3 Zone 1 requests. Base costs exclude safe-read retries (up to 4 attempts, each counted); honor cached status/cooldown. Never blindly replay uncertain writes. See inoreader://usage for limits, URI examples and prompts.

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": {
      "stream_id": "<stream_id>",
      "new_feed_url": "<new_feed_url>"
    },
    "name": "replace_feed"
  }
}

Input Schema

NameRequiredDescriptionDefault
stream_idYesStream ID of the subscription to replace
new_feed_urlYesFeed URL to subscribe to instead

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already flag destructive, non-idempotent, open-world behavior, and the description adds substantial context beyond that: the ordered subscribe-confirm-unsubscribe sequence, folder top-up semantics when the target already exists, loss of read state, and request-cost accounting. Retry and cooldown cautions ("Never blindly replay uncertain writes", "honor cached status/cooldown") directly address the risk of a non-idempotent write.

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 operational ordering is front-loaded in the first sentence, with edge cases and cost notes following. The cost/retry paragraph is dense but each clause carries distinct operational information; the pointer to inoreader://usage keeps boilerplate out of the main text.

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 destructive, non-idempotent mutation with no output schema and only two parameters, the description covers sequencing, partial-failure avoidance, and cost. It stops short of stating what the tool returns or what state exists if the confirmation step fails between subscribing and unsubscribing.

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 both parameters are already documented as the old subscription ID and the replacement URL. The description adds only indirect meaning, clarifying that title and folders are inherited from the old subscription rather than supplied as arguments; the baseline 3 applies when the schema carries the parameter detail.

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 ("Replace a subscription with a different feed URL") plus the key preservation scope (title and folders). This is clearly differentiated from siblings like manage_subscription and batch_edit_subscriptions because it describes a swap rather than an edit or bulk change.

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?

"Use with find_feed_replacement" gives explicit pairing guidance, and the already-subscribed case explains expected behavior in that scenario. It does not explicitly rule out alternatives such as manage_subscription or batch_edit_subscriptions, so routing against those siblings is left to inference.

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

Deploy Server

Other Tools