FeedKeeper RSS/Atom reader and remote MCP Server

Rename a feed folder

rename_folder

Changes the display name of an existing feed category folder for the current user, returning the updated folder record or an error if the ID is missing or name is taken.

Instructions

Renames an existing feed category folder for the current user. Requires write scope. Returns the updated folder record { id, name, position }. Returns error if folderId is not found or name is already taken.

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": {
      "folderId": "<folderId>",
      "name": "<name>"
    },
    "name": "rename_folder"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	The new unique display name for the folder (1 to 100 characters)
`folderId`	Yes	The numeric ID of the folder to rename

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.36.4Nov 9, 2026
- addedInput schema / properties / folderId / description
```
Added value: +"The numeric ID of the folder to rename"
```
- addedInput schema / properties / name / description
```
Added value: +"The new unique display name for the folder (1 to 100 characters)"
```
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, the description carries the full burden and does well: it discloses the required write scope, the exact response shape { id, name, position }, and two concrete failure modes (folderId not found, name already taken). It does not mention whether feeds inside the folder are affected or whether the call is idempotent, which keeps it short of a 5.

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?

Four short sentences, front-loaded with purpose, then prerequisites, return value and errors in descending order of importance. Every sentence adds information and nothing is repeated from the schema.

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 two-parameter mutation with no annotations and no output schema, the description supplies the mutation semantics, permission requirement, return shape, and error cases, which is nearly everything an agent needs. Only side effects on the folder's contents or on feed listings are left unstated.

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 in full, including the uniqueness and length constraints on name. The description only reinforces those constraints via the "name is already taken" error, adding little meaning beyond the schema; 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?

States a specific verb and resource ("Renames an existing feed category folder") and scopes it to the current user, so it is clearly distinct from create_folder, delete_folder, and move_feed_to_folder. It does not explicitly name those siblings, but the operation itself is unambiguous.

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 word "existing" plus the error conditions imply the folder must already be present and the new name must be free, which is useful precondition context. However, it never states when to prefer this over alternatives (e.g. move_feed_to_folder or create_folder) or when not to call it.

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