inoreader-mcp

Batch edit subscriptions

batch_edit_subscriptions

Idempotent

Assign multiple feeds to folders in one batch to organize subscriptions quickly. Use it to group many streams at once instead of editing each feed individually.

Instructions

Deprecated: use categorize_feeds instead (more reliable, folder-centric input). Add multiple feeds to folders. Base cost is 1 Zone 2 request per assignment and 1-3 Zone 1 verification reads; reconciliation may add 1 Zone 2 per shortfall. Preflight requires worst-case headroom; read retries cost extra. Reports only assignments confirmed present on the server. 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": {
      "edits": "<edits>"
    },
    "name": "batch_edit_subscriptions"
  }
}

Input Schema

Name	Required	Description	Default
`edits`	Yes	Array of edits to apply

Output Schema

Name	Required	Description	Default
`failed`	Yes
`rounds`	Yes
`intended`	Yes
`verified`	Yes
`unverified`	Yes
`verification`	Yes
`not_attempted`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.1Nov 3, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only say it is a non-read-only, idempotent, non-destructive open-world write. The description goes well beyond that by disclosing the cost model (1 Zone 2 per assignment, 1-3 Zone 1 verification reads, reconciliation surcharges), retry accounting (up to 4 safe-read attempts, each counted), and partial-success semantics ("Reports only assignments confirmed present on the server"). That is exactly the behavioral context an agent needs for a costly batch 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 most decision-relevant fact (deprecation and the replacement tool) is front-loaded, and nearly every clause carries operational information rather than filler. It is dense and telegraphic, though, so some cost and retry detail could have been deferred entirely to the referenced inoreader://usage resource.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description still supplies the remaining essentials: cost and budget behavior, preflight requirements, confirmation-based reporting, retry safety, and a pointer to inoreader://usage for limits and examples. Nothing an agent needs to call this correctly is absent.

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 with 100% schema description coverage, including nested stream_id and add_to_folder fields, so the schema already carries parameter meaning. The description only implies the array-of-assignments shape via "multiple feeds to folders" and adds no constraints such as the 1000-item cap or duplicate handling. 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?

"Add multiple feeds to folders" is a specific verb plus resource, and the description immediately names categorize_feeds as the preferred replacement with a reason (folder-centric input). An agent can distinguish this from siblings like manage_subscription or reassign_feeds. It loses a point only because the deprecation framing partially replaces rather than fully contrasts the purpose.

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 an explicit exclusion ("Deprecated: use categorize_feeds instead") plus operational preconditions: preflight must have worst-case headroom, cached status/cooldown must be honored, and uncertain writes must not be blindly replayed. What is missing is any statement of when this tool would still legitimately be used, so the positive case is left implicit.

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