inoreader-mcp

Categorize feeds

categorize_feeds

Idempotent

Assign multiple RSS feeds to folders in one bulk operation using a folder-to-stream-ID map, then verify assignments and retry any that fail.

Instructions

Assign feeds to folders in bulk. Pass a map of {folder_name: [stream_id, ...]}. Typical workflow: call get_uncategorized_feeds first, decide categories, then call this tool. 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. Reads the subscription list back afterwards and retries anything that did not land, so the counts reflect what is actually on the server; sets isError when fewer changes were confirmed than requested. 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": {
      "assignments": "<assignments>"
    },
    "name": "categorize_feeds"
  }
}

Input Schema

Name	Required	Description	Default
`assignments`	Yes	Map of folder name to array of stream IDs to assign (max 1000 assignments)

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?

Well beyond the annotations, it discloses the cost model (Zone 2 per assignment, 1-3 Zone 1 verification reads, extra Zone 2 for reconciliation), the preflight headroom requirement, and read-retry accounting. Critically it explains post-write behavior: the tool reads the subscription list back, retries misses, and sets isError when fewer changes were confirmed than requested. The only mild tension is 'never blindly replay uncertain writes' alongside idempotentHint=true, but that reads as a cost/uncertainty warning rather than a contradiction.

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?

Front-loaded with the action and the input shape, then workflow, then cost and error semantics in a logical order. It is dense with cost clauses ('Base cost is... Base costs exclude safe-read retries...') that are somewhat repetitive, but each sentence contributes operational information rather than filler.

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 bulk mutation tool with an output schema already covering return values, the description supplies the missing pieces: prerequisite workflow, budget/preflight constraints, verification-and-retry behavior, and partial-failure signaling via isError. An agent has everything needed to decide to call it and to interpret a partial result.

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 the 'assignments' map and its nesting are already fully documented. The description restates the map shape ('Pass a map of {folder_name: [stream_id, ...]}') but adds no semantics the schema lacks, and omits the 1000-assignment ceiling that the schema carries. Baseline 3 applies when the schema does the heavy lifting.

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 concrete verb and resource ('Assign feeds to folders in bulk') and immediately shows the input shape '{folder_name: [stream_id, ...]}', so the operation is unmistakable. It does not, however, distinguish itself from close siblings such as reassign_feeds or batch_edit_subscriptions, leaving the agent to infer which bulk-manipulation tool is correct.

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?

Gives an explicit sequencing rule: 'call get_uncategorized_feeds first, decide categories, then call this tool', which is exactly the kind of when-to-use guidance that helps selection. It also points to inoreader://usage for limits and prompts, but offers no exclusion clause telling the agent when NOT to use this versus reassign_feeds.

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