Skip to main content
Glama

Create RSS Feed

create_rss_feed
Destructive

Connect an RSS or Atom feed so each new item becomes a post on the target accounts. The feed is fetched and every item already in it is recorded, so only items that appear later are posted; postLatestItem also posts the newest one on the first check. The feed is then checked every checkIntervalMinutes and posts as the member who saved it, as a draft, a scheduled post or straight away (postMode). With postMode SCHEDULE or PUBLISH, posts go out on the user's accounts without further confirmation, so confirm the feed, the accounts, the mode and the text with the user first. Try preview_rss_feed first to show what the posts will say. Fails with 400 for invalid settings, a URL that is not a feed, a feed already connected or the 20-feed workspace limit, and 503 when the feed cannot be reached. Needs posts.draft, plus the permission of the post mode.

Input Schema

NameRequiredDescriptionDefault
urlYesPublic http(s) URL of an RSS or Atom feed
nameNoName of the feed (max 120 characters). Defaults to the feed's title
targetsYesAccounts every new item is posted to, 1 to 20. Feeds post to FACEBOOK, INSTAGRAM, THREADS, TWITTER, BLUESKY, LINKEDIN, MASTODON, TELEGRAM and GOOGLE_BUSINESS
postModeYesDRAFT creates a draft and needs posts.draft; SCHEDULE schedules the post publishDelayMinutes after the item is found and needs posts.schedule; PUBLISH publishes it right away and needs posts.publish
templateNoPost text with {title}, {link}, {description}, {author} and {feed} (max 2000 characters, default "{title}\n\n{link}"). The description, then the title, is shortened to fit each platform; the link is never cut
contentModeYesTEMPLATE fills template; AI writes one caption per platform from the article, appends the link, spends 1 AI credit per platform per item and needs ai.generate
workspaceIdNoWorkspace to act in: an id from list_workspaces. Omit to act in the workspace list_workspaces marks current. Use the same workspaceId for every call about the same workspace, since ids from one workspace (accounts, posts, uploads) do not exist in another
includeImageNoAttach the item's image, or the article's preview image (default true)
aiInstructionsNoExtra instructions for AI captions (max 1000 characters)
postLatestItemNoAlso post the newest item on the first check (default false)
excludeKeywordsNoSkip items whose title or summary contains one of these (up to 50)
includeKeywordsNoPost only items whose title or summary contains one of these (up to 50)
maxPostsPerCheckNoNew items posted per check, 1 to 10 (default 3). New items are posted oldest first; the rest wait for the next check
twitterKeepLinksNoKeep links in X posts clickable (default false). Lifetime-deal plans only; each X post with a link then costs more credits. Without it, links on X go out as plain text
publishDelayMinutesNoMinutes between finding an item and its post going out, 5 to 10080. Required when postMode is SCHEDULE
checkIntervalMinutesNoMinutes between checks: 15, 30, 60 (default), 180, 360, 720 or 1440

Output Schema

NameRequiredDescriptionDefault
resultNoThe new feed. The RSS feed: id, userId (the member it posts as, whoever last saved it), name, url, siteUrl, status (ACTIVE or PAUSED), pauseReason, lastError, postMode, publishDelayMinutes, contentMode, template, aiInstructions, includeImage, twitterKeepLinks, includeKeywords, excludeKeywords, maxPostsPerCheck, checkIntervalMinutes, targets, nextCheckAt, lastCheckedAt, lastPostedAt, createdAt and updatedAt.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

The annotations already mark this as destructive and open-world, and the description adds substantial context: existing items are recorded so only later items post, postLatestItem changes first-check behavior, checks repeat on checkIntervalMinutes, and SCHEDULE/PUBLISH publish without further confirmation. It also discloses specific 400 and 503 failure conditions and required permissions.

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 purpose and key behavior are front-loaded in the first sentence, and nearly every sentence adds operationally important information about scheduling, confirmation, preview, errors, and permissions. It is dense but appropriate for a 16-parameter mutation tool, though bullets or shorter sentences could improve scanability.

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?

Given the 16 parameters, destructive/open-world annotations, and an output schema, the description is complete enough for an agent to call the tool correctly. It covers setup behavior, ongoing checks, confirmation requirements, alternatives, permissions, and failure modes.

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 the input schema already documents every parameter in detail, including enums, defaults, limits, and permission implications. The description reinforces the risk of postMode and the first-check behavior of postLatestItem, but it largely repeats rather than adding new parameter-specific semantics beyond the schema.

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 opens with a specific verb and resource: connect an RSS or Atom feed so new items become posts on target accounts. It clearly distinguishes this creation tool from preview_rss_feed and the update/delete/list siblings by describing the ongoing posting behavior.

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

Usage Guidelines5/5

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

It explicitly recommends preview_rss_feed first and warns to confirm the feed, accounts, mode, and text with the user before SCHEDULE or PUBLISH. It also states the required permission scope and explains when errors such as duplicate feeds or workspace limits occur.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources