Provides tools for managing RSS/Atom feeds, including adding and removing feeds, semantic search with recency boost, listing recent articles, surfacing trending terms, generating markdown digests, and monitoring feed health.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@web-mcp What's trending across my feeds today?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Semantic search over RSS/Atom feeds for AI agents — a single-file MCP server. No API key, no cloud, just the feeds you choose.
Point it at a handful of RSS/Atom feeds and give an agent tools to search them by meaning (TF-IDF + recency boost), see what's trending, generate a digest, and monitor feed health — all running locally against feeds you control.
Add/remove/list feeds — RSS 2.0 and Atom
Ranked search — TF-IDF cosine similarity with a recency boost, pure stdlib (no embeddings, no network calls beyond fetching the feeds themselves)
Trending topics — most frequent terms across recent articles
Source health — flags feeds that are erroring, silent, or stale
Markdown digests — grouped-by-feed summary of recent articles
Background refresh — feeds are refreshed on a timer automatically
Related MCP server: mcp-rss-feed-searcher
Requires Python 3.10+.
On the package name: the project is
web-mcp, but the PyPI distribution isfeed-mcp— PyPI rejectsweb-mcpas too similar to an unrelated existingwebmcppackage. So youpip install feed-mcp, and it installs both aweb-mcpand afeed-mcpcommand; they're the same program, use whichever you prefer.
Installs the MCP server and the bundled skills and agents in one step:
pip install feed-mcpThen, inside Claude Code:
/plugin marketplace add ManiaSacha/web-mcp
/plugin install web-mcp@maniasacha-web-mcpThe plugin registers the web MCP server automatically and prompts you for a starting feed list. If the install summary says Run /reload-plugins to activate., run that.
The
pip installstep is required: the plugin's MCP server invokes theweb-mcpcommand, which pip puts on your PATH.
pip install feed-mcp
claude mcp add web -- web-mcp --feeds https://hnrss.org/frontpageFor Claude Desktop, add this to claude_desktop_config.json:
{
"mcpServers": {
"web": {
"command": "web-mcp",
"args": ["--feeds", "https://hnrss.org/frontpage,https://github.blog/feed/"]
}
}
}git clone https://github.com/ManiaSacha/web-mcp.git
cd web-mcp
./install.sh # Windows: .\install.ps1The install scripts check your Python version, install the package, and print the exact next command for your setup.
Run the server directly to check it works:
web-mcp --feeds https://hnrss.org/frontpage,https://github.blog/feed/It speaks MCP over stdio, so it will sit silently waiting for a client — that's correct behavior, not a hang. Press Ctrl+C to exit.
Once connected, ask your agent things like:
"What's trending across my feeds today?"
"Search my feeds for anything about Postgres performance."
"Give me a digest of the last 24 hours."
"Are any of my feeds broken?"
Component | Name | Purpose |
MCP server |
| The 9 tools below |
Skill |
| Add, audit, and prune feeds |
Skill |
| Turn raw tool output into a synthesized brief |
Agent |
| Scopes features against the single-file philosophy |
Agent |
| Audits the SSRF/fetch surface |
Agent |
| Branching, commits, and review handoff |
Tool | Description |
| Add an RSS/Atom feed and index its current articles |
| Remove a feed and its indexed articles |
| List configured feeds with article counts |
| Recency-boosted ranked search |
| Most recent articles across all feeds |
| Trending terms in the last N hours |
| Markdown digest grouped by feed |
| Which feeds are healthy, late, or erroring |
| Force-refresh all feeds immediately |
add_feed(url) makes the server fetch a URL that may have reached your agent from a web page rather than from you, so that path is treated as untrusted:
Scheme allowlist — only http:// and https://. file://, ftp://, gopher://, and data: are refused.
Public addresses only — a URL is rejected unless every address it resolves to is publicly routable. Loopback, private, link-local (including the 169.254.169.254 cloud metadata endpoint), multicast, and reserved addresses are blocked, as are their IPv4-mapped IPv6 forms.
Connect-time IP pinning — the address that was validated is the one actually dialed, so DNS cannot answer differently between the check and the connection (rebinding). TLS still validates certificates against the hostname.
Per-hop redirect validation — redirects are followed manually and re-validated at every hop, so a public URL cannot bounce the fetch to an internal host. Capped at 5 hops.
Resource bounds — 5 MB per feed body, an explicit socket timeout, and a clamp on every tool's limit.
Two things this does not do: it has no authentication (it's meant to run locally over stdio — don't expose it on a network), and it does not vet feed content. Indexed article text is written by whoever controls the feed, so treat it as data, never as instructions.
Full detail, including the limits that remain, is in docs/SECURITY-MODEL.md. To report a vulnerability, see SECURITY.md.
pip install -e ".[dev]"
pytest # 53 tests, no network access
ruff check . # lint
python scripts/validate_plugin.py # manifests, frontmatter, version syncCI runs all three on Python 3.10–3.13 (Linux, plus macOS and Windows on 3.12), and additionally installs the built wheel to confirm the console scripts work.
See CONTRIBUTING.md for the workflow and CHANGELOG.md for release history.
MIT
Add an RSS/Atom feed and fetch its current articles.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It discloses that the operation adds a feed and fetches its articles, indicating a state-changing action. It does not detail edge-case behaviors such as duplicate feeds, validation failures, or what happens if the fetch fails, but it is transparent about the core operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the primary verb and object. Every word contributes meaningful information, with no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description is mostly complete: it states the operation, the target resource, and the immediate fetch behavior. It could additionally mention that the feed becomes part of the user's feed list or that fetching may be synchronous, but the existing description covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'url' with no description, and schema description coverage is 0%. The description adds that the URL should point to an RSS/Atom feed, which is helpful context beyond the bare parameter name, but it does not elaborate on URL format, protocol expectations, or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Add an RSS/Atom feed and fetch its current articles.' It clearly distinguishes from siblings like remove_feed, list_feeds, and refresh by indicating this tool creates a new feed subscription and performs an initial fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a user wants to add a new feed, and it contrasts implicitly with remove_feed and refresh. However, it does not explicitly state when not to use it, mention alternatives, or clarify that refresh is the appropriate tool for updating an existing feed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a markdown digest grouping recent articles and trending topics.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It indicates the tool generates a digest and nothing else, but it does not disclose potential side effects, dependencies on feeds, rate limits, or how content is selected. Some behavior is clear, but much is left unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that leads with the action and output format. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and only two optional parameters with defaults, an agent can invoke this tool with no arguments reasonably safely. However, the description omits how hours and limit interact, what 'trending topics' means, and whether the digest depends on configured feeds, leaving room for misinterpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain 'hours' or 'limit'. The parameter names and defaults are somewhat self-explanatory, and 'recent articles' hints at hours, but the description adds no explicit parameter semantics to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Generate') and resource ('markdown digest grouping recent articles and trending topics'), making the tool's core function obvious. It does not explicitly compare itself with siblings like recent or trending, but the grouping and digest format distinguish it enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you want a consolidated markdown digest of recent articles and trending topics. It does not provide explicit when-to-use versus alternatives or mention exclusions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured feeds with article counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'List' clearly signals a read-only operation, and the phrase 'with article counts' discloses key behavior about the returned data. It does not mention auth, caching, or ordering, but these are minor for a zero-parameter listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. The verb and resource are front-loaded, and every word contributes meaning ('configured feeds', 'article counts').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is sufficient: it names the resource and the key expected output field. It could add ordering or live-vs-cached count details, but these are not required for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is already fully complete. The description adds no parameter detail, and none is needed; this matches the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states an explicit verb ('List') and resource ('configured feeds') and adds a useful output detail ('with article counts'). This clearly distinguishes it from siblings that operate on article content (search, recent, trending, digest) or mutate feeds (add_feed, remove_feed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when the agent needs to see configured feeds and their article counts. However, it does not explicitly discuss when not to use it or point to alternatives such as source_health for feed status or refresh for live counts, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most recent articles across all feeds.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the behavioral disclosure burden. It only says 'across all feeds' and does not mention ordering, freshness window, pagination, or any limitations. The description adds little beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler or redundant statements. It is easy to scan and gets the core idea across quickly. The brevity comes at the cost of behavioral detail, but it is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but with no annotations and no sibling differentiation, the description is not fully complete. An agent has little guidance for choosing this over 'trending' or 'digest,' and no information about default sorting or response shape. The output schema helps fill some gaps, but the description remains under-specified for confident selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not explain the 'limit' parameter at all. The schema provides the type and default, and the parameter name is fairly self-explanatory, but the description itself adds no parameter-level meaning. It partially compensates by being about a simple single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns the most recent articles and scopes it 'across all feeds,' which is clear enough to convey the basic purpose. It lacks an explicit verb like 'list' or 'get,' but the intent is unambiguous. It does not explicitly differentiate from sibling tools like search, trending, or digest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is an implied use case: fetch the newest articles from all feeds. However, the description provides no explicit 'when to use this vs. other tools' guidance, and it does not mention alternatives such as trending or digest. The usage context is minimal and largely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force-refresh all feeds now.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that the refresh is forced and immediate, not a scheduled or passive update. It does not detail side-effects like network load or rate limiting, but for a zero-parameter command this level of disclosure is generally sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that leads with the action and immediately states scope. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, an existing output schema, and no overlapping siblings, this description supplies all the context an agent needs to select and invoke the tool correctly. Anything more would be unnecessary for such a simple command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema confirms zero parameters, so there is nothing to document. The description adds no parameter-level detail, but none is needed; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Force-refresh') and resource ('all feeds'), clearly identifying a manual refresh action. It is distinct from all sibling tools, which handle feed management, search, and digests, so an agent can easily understand what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended context is clear: use this when you want to force an immediate refresh of all feeds. No sibling tool overlaps with this action, and no exclusion is necessary. It stops short of explicitly stating when not to use it or citing alternatives, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a feed and all of its indexed articles.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it explicitly discloses that the feed and all its indexed articles are removed, which is the key destructive side effect. It stops short of stating irreversibility or permission requirements, but the main behavioral risk is clearly surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler: the subject, action, and destructive scope are all in few words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with an output schema present, the description is nearly sufficient: it defines the action and the critical cascade. It could add a note about irreversibility or URL semantics, but output formatting is already covered by the output schema and the tool complexity is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate: it never explains that the feed is identified by URL, what URL formats are accepted, or that the parameter is required. The schema only provides the parameter name and type, so the description adds no parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' with the resource 'feed' and adds the cascading effect on indexed articles, so an agent can unambiguously tell this from siblings like add_feed or list_feeds. It states a clear action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The operation itself is self-evident: use it when a feed should no linger be present. However, the description gives no explicit when-to-use/when-not-to-use guidance, no alternatives, and no prerequisites or warnings beyond the action, so usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recency-boosted ranked search across indexed feeds.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| max_days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral disclosure burden. It reveals one useful trait, recency-boosted ranking, but says nothing about search scope limits, time-window behavior, query semantics, or whether the operation is read-only. The agent gets only a partial picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and its most distinguishing trait ('recency-boosted') is front-loaded. It is not a complete specification, but as far as length and ordering go it is well formed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no annotations, this description is thin. It leaves unclear what 'indexed feeds' means, how max_days works, and when search should be preferred over recent, trending, or digest. The output schema covers return shape, but invocation context is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain query, limit, or max_days beyond what the parameter names already suggest. 'Recency-boosted' only loosely hints at max_days, and the agent must infer how limit and max_days shape results. The description does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a search operation over indexed feeds and adds a meaningful ranking trait ('recency-boosted'). This makes its purpose distinct from sibling list tools like recent or trending, though the differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing implies use when an agent needs to search previously indexed feed content, but it never says when to choose this over recent, trending, or digest. No alternatives or exclusion conditions are named, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check which feeds are healthy, late, or producing errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. The read-only verb 'Check' and the enumerated status categories communicate expected behavior and outcome shape. It does not elaborate on underlying mechanics (e.g., network requests), but for a zero-parameter status query this is not a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Every phrase adds semantic value, and no redundant details are included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is maximally simple: no params, no required inputs, and an output schema exists. The description is sufficient for an agent to correctly select and invoke the tool without missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema already fully covers invocation inputs. Baseline 4 applies because there is no parameter information for the description to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') with a clear resource ('feeds') and defines the exact health outcomes ('healthy, late, or producing errors'). This distinguishes it from siblings like list_feeds (plain listing) and refresh (manual trigger) without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: call this when the agent needs feed health status rather than feed content or management. It does not explicitly name when not to use it or alternative tools, but the single-purpose phrasing leaves little ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Topics trending across your feeds in the last N hours.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure, yet it only states that topics are 'trending across your feeds in the last N hours.' It does not disclose whether the operation is read-only, how trending is computed, whether results are sorted, what happens with empty feeds, or what the returned topics look like beyond what the output schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loads the core concept with no filler words. However, it is under-specified rather than tightly specified—brevity here comes at the cost of missing behavioral and parameter information, so the sentence does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value documentation is covered elsewhere, and the tool is low-complexity with two optional params. But at 0% schema parameter coverage and no annotations, the description still fails to differentiate from siblings like 'recent' and 'digest', explain 'limit', or define the trending criteria—leaving notable gaps for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially clarifies that 'hours' controls the look-back window via 'in the last N hours', but it says nothing about the 'limit' parameter, leaving its behavior (maximum number of topics returned) undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('trending'), resource ('topics across your feeds'), and time window ('last N hours'). It is distinct enough from siblings like search and refresh to convey the core function, though it does not define what 'trending' means (e.g., ranked by engagement, velocity, or mentions) or how it differs from 'recent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings such as 'recent' or 'digest'. The description implies it is for surfacing currently popular topics, but it never states exclusion criteria (e.g., 'use recent for chronological listing' or 'use digest for summaries'), leaving tool selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.1add_feeddigestlist_feedsrecentrefreshremove_feedsearchsource_healthtrendingEach tool targets a clearly distinct operation: feed lifecycle management, retrieval, aggregation, health monitoring, and refresh. There is no meaningful overlap between search, recent, trending, and digest—they serve different user intents.
The naming is readable but mixes conventions: some tools use verb_noun (add_feed, remove_feed, list_feeds), while others are bare verbs or nouns (search, recent, trending, digest). Also, add_feed/remove_feed use singular while list_feeds uses plural, creating minor inconsistency.
Nine tools is well-scoped for an RSS/feed aggregator. Each tool earns its place covering management, querying, aggregation, health, and refresh without unnecessary redundancy.
The tool surface covers the core feed lifecycle (add, remove, list, refresh), retrieval (search, recent), insight (trending, digest), and maintenance (source_health). Minor gaps exist like per-feed article listing or feed URL editing, but these are not critical for the intended use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read, search and track your RSS feeds: semantic search, story clustering, watches, OPML import.
Reddit MCP server: search posts, subreddit feeds, comments & user profiles as JSON. No API key.
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
MCP server for searching Airweave collections with natural language queries.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ManiaSacha/web-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
