Skip to main content
Glama
Sign In
ToolSnap MCP

ToolSnap MCP

by ToolSnap-app
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Parse RSS or Atom feed

rss_parse
Read-only

Fetch RSS 2.0 or Atom feeds and get clean JSON with feed metadata and items, stripping HTML and capping item counts. Use it to read news or blog feeds without parsing XML.

Instructions

Free, read-only. Fetch an RSS 2.0 or Atom feed and return JSON: feed title, link, description, lastBuildDate, itemCount, truncated, and items[] with title, link, pubDate, guid, description (HTML stripped), author, categories, enclosure. Items past maxItems are dropped and truncated=true. A URL that is not a feed returns type 'unknown' and no items. Not JSON Feed. Errors on non-2xx, 10 s timeout or private hosts.

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": {
      "url": "<url>"
    },
    "name": "rss_parse"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesFeed URL, http(s). Private hosts refused.
maxItemsNoDefault 20, max 200. itemCount still reports the full total.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.5
    • changedInput schema / properties / maxItems / description
      Previous value: -"Max 200."New value: +"Default 20, max 200. itemCount still reports the full total."
    • changedInput schema / properties / url / description
      Previous value: -"Feed URL."New value: +"Feed URL, http(s). Private hosts refused."
  2. Changed2 schema fields changedv0.1.1
    • changedInput schema / properties / maxItems / description
      Previous value: -"Max feed items to return (default 20, max 200)."New value: +"Max 200."
    • changedInput schema / properties / url / description
      Previous value: -"RSS or Atom feed URL (http:// or https://)."New value: +"Feed URL."
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint annotation: discloses truncation semantics ('Items past maxItems are dropped and truncated=true'), HTML stripping in descriptions, error conditions (non-2xx, 10 s timeout, private hosts refused), and the non-feed case. Cost ('Free') and safety profile are both stated.

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-loaded with capability and exclusion, and every clause carries a distinct fact. The telegraphic, fact-stacked style (comma-separated field lists, error list in one sentence) is efficient but dense enough to be slightly harder to scan than a cleanly segmented version.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description fully compensates by enumerating the response envelope and item fields, plus the truncation flag. With only two parameters and full schema coverage, nothing an agent needs to call this correctly is missing.

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?

Schema coverage is 100%, so baseline is 3; the description adds meaning by explaining that dropping items past maxItems sets truncated=true while itemCount still reflects the full total, clarifying the interaction between the two parameters. URL constraints (private hosts refused) are also reinforced in prose, though no format examples are given.

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?

States a specific verb+resource ('Fetch an RSS 2.0 or Atom feed and return JSON') and immediately enumerates the returned fields. It explicitly excludes JSON Feed and implicitly differentiates itself from siblings like sitemap_parse and fetch_metadata by naming its format scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly positions when the tool applies (RSS 2.0 / Atom URLs) and adds an exclusion ('Not JSON Feed') plus a fallback behavior for non-feed URLs ('returns type unknown and no items'). It does not name an alternative sibling to use for JSON Feed or generic HTML, so it stops short of full routing guidance.

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

Deploy Server

Other Tools