FeedKeeper RSS/Atom reader and remote MCP Server

Remove a muted keyword filter

unmute_keyword

Removes a muted keyword filter by its numeric ID so existing and future RSS/Atom articles matching that keyword become visible again.

Instructions

Removes an existing muted keyword filter by its numeric keywordId. Future and existing articles matching this keyword will once again be visible. Returns { ok: true } on success.

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": {
      "keywordId": "<keywordId>"
    },
    "name": "unmute_keyword"
  }
}

Input Schema

Name	Required	Description	Default
`keywordId`	Yes	The numeric ID of the muted keyword rule to remove

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.36.4Nov 9, 2026
- addedInput schema / properties / keywordId / description
```
Added value: +"The numeric ID of the muted keyword rule to remove"
```
First observedv0.36.3Nov 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full burden, and it does disclose the tool's actual effect: both future and existing matching articles become visible again, and the return shape is { ok: true }. It does not cover failure behavior for an unknown keywordId, idempotency on repeat calls, or any authorization requirements, which are the remaining gaps.

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, each doing distinct work: identity and parameter, the concrete user-visible effect, and the return value. The effect is front-loaded right after the verb, with no filler or redundant restatement of the title.

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 one-parameter mutation tool with no annotations and no output schema, the description covers the essentials: what it removes, how the identifier is supplied, what becomes visible, and what success returns. The only omissions are error/idempotency semantics, which are lower stakes for this simple operation.

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 the single parameter is already documented as the numeric ID of the muted keyword rule. The description's phrase 'by its numeric keywordId' merely restates the schema, adding no format, range, or sourcing detail beyond it; 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?

The description names a specific verb ('Removes') and resource ('an existing muted keyword filter') and identifies the key used ('by its numeric keywordId'), so an agent can tell it apart from add_muted_keyword or list_muted_keywords on the verb alone. It stops short of explicitly contrasting itself with those siblings, which keeps it at 4 rather than 5.

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?

The implied usage is clear — call this to undo a mute — but there is no explicit when/when-not guidance, no mention of how to obtain the keywordId (e.g. via list_muted_keywords), and no statement about prerequisites such as the keyword existing. Usage must be inferred from the tool's effect.

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