rss-mcp

by jeffgbradley2

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
There is overlap between tech feeds (get_tech_feed, get_arstechnica_feed) and science feeds (get_science_feed, get_physics_feed), which could cause misselection. fetch_rss is distinct as a generic fetcher, but the specific feeds have blurred boundaries.
Naming Consistency4/5
Most tools use a get_<descriptor>_feed pattern, but fetch_rss deviates with a different verb and no '_feed' suffix. This is a minor inconsistency in an otherwise predictable naming scheme.
Tool Count5/5
Six tools is well-scoped for an RSS server. The generic fetch_rss plus specific curated feeds provides a balanced set without unnecessary bloat.
Completeness5/5
fetch_rss can retrieve any RSS feed, providing full coverage. The specific feed tools are convenience wrappers, so there are no obvious gaps in the server's functionality.
Average 2.7/5 across 6 of 6 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior, but it provides none. It doesn't indicate whether the tool returns a list, requires network access, or has any side effects. The statement 'Local and national news' is purely descriptive and adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely brief, it omits essential information, making it under-specified rather than concise. It is a short phrase without any structuring or explanatory content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations or output schema, so the description is the only source of context. It fails to explain what the news feed contains, how it is returned, or how it relates to the sibling tools. A simple statement of scope is insufficient for a minimally viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and the description need not explain parameter usage. Baseline 4 is appropriate, although the description does not add parameter-specific semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Local and national news' is a vague noun phrase that does not clearly state an action or resource. It fails to specify that the tool retrieves or lists news feeds, and does not differentiate from siblings beyond topic. The name implies a feed, but the description is a tautology of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus the sibling feeds (fetch_rss, get_tech_feed, etc.), nor any context for selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the source ('Hacker News') and does not mention read-only nature, return format, or any side effects. This is essentially no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and free of fluff, but it is a sentence fragment that lacks a clear action. It is concise but not well-structured as a complete tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a single vague phrase, the description provides only minimal context. It does not clarify what the feed contains, how it behaves, or how it relates to sibling feeds, making it inadequate for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter semantics. Per the rubric, a 0-param tool receives a baseline of 4 since there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (tech news from Hacker News) but lacks a specific verb like 'fetches' or 'lists.' It distinguishes from science and physics feeds but not clearly from get_news_feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools exist but are never mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states content ('Tech news from Ars Technica') but does not indicate that the tool performs a read-only operation, returns a feed, or any other behavioral traits. The description is a noun phrase, not a statement of behavior.
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?
The description is extremely brief and front-loaded, using only four words. It contains no fluff and is easily scannable. However, its brevity borders on under-specification, though it does convey more than a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and zero parameters, so the description is the sole source of context. It fails to explicitly state what the tool does (e.g., 'Fetches the latest Ars Technica news feed'), leaving the agent to infer from the name. Given the sibling tools, the description is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the baseline for 0 params is 4. The description need not add parameter semantics since there are none; the schema fully covers the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tech news from Ars Technica' provides a resource (Ars Technica) and content type (tech news), but lacks a clear verb specifying the action. It is not a tautology because it adds context, but it fails to explicitly state that the tool fetches or returns a feed, making it ambiguous compared to sibling tools like fetch_rss or get_tech_feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With sibling tools such as get_tech_feed and get_news_feed, there is no distinction or conditional advice, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states the content source ('Science news from Nature') and gives no information about return format, pagination, network behavior, or any side effects. This is insufficient.
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?
A single, front-loaded phrase with no redundancy. Every word earns its place, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter feed tool, the description is too terse. It omits what the returned feed contains (e.g., a list of articles, metadata, format) and any behavioral nuances. The tool name and siblings imply a feed, but the description does not complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter burden. The baseline score of 4 applies because there are no parameter semantics to explain.
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 identifies the specific resource: science news from Nature. This distinguishes it from sibling feeds by both topic and source, though the verb is implied by the tool name rather than stated in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not state when to choose this feed over the other get_*_feed sibling tools, nor any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return fields and the filter behavior, but it references a 'filter_out_topics' parameter that does not exist in the schema, which is misleading. There are no annotations to support the safety profile, and the description does not address potential errors or formatting.
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?
The description is two sentences and front-loaded with the core purpose. However, the second sentence introduces inaccurate parameter information, which undermines its value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no annotations or output schema, the description should explain parameters and edge cases. It fails to describe 'limit', references a non-existent parameter, and lacks alternatives or error handling, leaving an agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (url, limit), but the description only mentions a phantom 'filter_out_topics' parameter and provides no meaning for 'limit' or 'url'. This does not help an agent understand the actual parameters.
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?
The description clearly states the tool fetches any RSS feed by URL, which is a specific verb+resource. It distinguishes itself from specialized feed tools like get_tech_feed by emphasizing 'any RSS feed'.
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 description implies a general-purpose use case ('any RSS feed') but does not explicitly mention when to use this over siblings. No exclusions or alternatives are named, so guidance is merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing tool behavior. It only states the content source and topic, but fails to mention whether the output is a feed, its format, any pagination, or other behavioral traits. This is minimal disclosure.
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?
The description is a single, concise phrase that directly states the tool's subject and source. Every word contributes value, and it is appropriately front-loaded. No unnecessary information is included.
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?
For a simple parametless tool, the description is adequate but not complete. It names the source and topic but does not describe the return format, whether it is an RSS feed, or what the output structure looks like. Since there is no output schema, a brief mention of the expected feed content would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The empty input schema aligns with the description, and no parameter semantics are needed. The description correctly implies that the tool takes no input.
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 'Physics and science news from Phys.org' clearly identifies the tool as providing news content from a specific source and subject area. Though no explicit verb like 'get' is present, the tool name supplies that context, making the purpose apparent. It distinguishes from siblings by naming Phys.org as the source, though overlap with get_science_feed remains possible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_science_feed or get_tech_feed. The only implied usage is that this tool is for physics-related news from Phys.org, but there are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![rss-mcp MCP server](https://glama.ai/mcp/servers/jeffgbradley2/rss-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jeffgbradley2/rss-mcp)

Score Badge

Copy to your README.md:

[![rss-mcp MCP server](https://glama.ai/mcp/servers/jeffgbradley2/rss-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jeffgbradley2/rss-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jeffgbradley2/rss-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server