Skip to main content
Glama

feed_manage

Manage RSS/Atom subscriptions by listing, subscribing, unsubscribing, pausing, or resuming feeds so you can control sources and polling behavior.

Instructions

管理 RSS/Atom 订阅:list、subscribe、unsubscribe、pause、resume。

URL 必须是 HTTP/HTTPS RSS 或 Atom 地址。删除和暂停使用精确名称或 source_id。 订阅后用 poll_feeds 采集,不会自动推送消息。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNo
nameNo
noteNo
actionYes
sourceNo
poll_interval_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose meaningful behavior: the URL protocol restriction, that delete/pause need an exact name or source_id, and that subscribed feeds are not auto-pushed (poll_feeds required). It omits permission/auth needs, what delete destroys, and reversibility of pause.

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-loads the action list, then layers constraints as short lines. No filler sentences; each line carries an operational fact. Slightly terse for the number of parameters, but well-structured.

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?

Given no annotations, no output schema, and 6 undocumented parameters, the description covers the action vocabulary, the identification semantics for delete/pause, and the poll workflow, but leaves the meaning of 'note'/'poll_interval_seconds' and what 'list' returns unexplained. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 6 parameters, so the description must compensate. It explains url, name/source, and the action values, but says nothing about 'note' or 'poll_interval_seconds', leaving two parameters completely undocumented in both schema and text.

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+resource (manage RSS/Atom subscriptions) and enumerates the concrete actions (list, subscribe, unsubscribe, pause, resume), so the agent knows exactly what it operates on. It does not explicitly disambiguate from feed_query or feed_status, though the poll_feeds reference partially differentiates it.

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?

Provides operational constraints ('URL must be HTTP/HTTPS RSS or Atom', 'delete and pause use exact name or source_id') and routes to the sibling poll_feeds for collection. However, it never says when to use feed_manage versus feed_query or feed_status, so use-case selection is left to inference.

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