Skip to main content
Glama
Sign In
inoreader-mcp

inoreader-mcp

by justmytwospence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Suggest feed cleanup

suggest_feed_cleanup
Read-onlyIdempotent

Proposes normalized titles for feeds without a folder by stripping vendor boilerplate and trailing RSS/feed/site-name suffixes; apply approved proposals via manage_subscription action='edit'.

Instructions

Propose cleaned-up titles for feeds that have no folder assignment. Pure string normalization -- strips vendor boilerplate ("Blog on X", "X's Blog", trailing "RSS"/"Feed", and a trailing site-name suffix). Deterministic: no LLM judgment, same input always yields the same output. Makes NO changes -- apply a proposal with manage_subscription action='edit'. Costs 1 Zone 1 request. 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

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "suggest_feed_cleanup"
  }
}

Input Schema

NameRequiredDescriptionDefault
include_unchangedNoInclude feeds whose title already needs no change (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.1

TDQS

A4.2/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: determinism ('no LLM judgment, same input always yields the same output'), the no-side-effect guarantee restated concretely, request cost accounting (1 Zone 1 request, safe-read retries counted), cached status/cooldown handling, and a caution against replaying uncertain writes. Annotations cover the read-only/idempotent profile, and the description layers cost and retry semantics on top.

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 purpose and scope, then behavior, then cost, then the pointer to usage docs — a sensible ordering with no filler. The retry/cooldown and 'never replay uncertain writes' sentences are generic cross-tool boilerplate that a per-tool description does not strictly need, which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Everything needed to call it safely is present: scope, determinism, cost, and how to apply results. But with no output schema, the description never characterizes the returned proposal structure (e.g., original vs. suggested title, how many feeds come back), leaving the agent to discover response shape empirically.

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% and there is only one optional parameter, so the schema already explains include_unchanged. The description adds nothing about that parameter; instead it describes the default filtering behavior ('feeds that have no folder assignment') implicitly, so baseline 3 applies.

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 ('Propose cleaned-up titles for feeds') plus a precise scope ('feeds that have no folder assignment'), then defines the transformation as pure, deterministic string normalization with named patterns (vendor boilerplate, trailing RSS/Feed, site-name suffix). An agent can distinguish this from siblings like manage_subscription or get_uncategorized_feeds without opening any schema.

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?

Explicitly routes the follow-up action to a sibling ('apply a proposal with manage_subscription action='edit'') and constrains the input set to feeds with no folder. It does not state outright when *not* to use it (e.g., feeds already correctly titled, which is only implied by include_unchanged), so it stops short of full when/when-not coverage.

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