Skip to main content
Glama
Sign In

Octopost

by ink.octopost
OverviewDiscussionsAdmin

Add an RSS feed

add_feed

Turn an RSS or Atom feed (a blog, a newsletter, a changelog) into posts. Octopost reads the feed right away (a site address works too if the page links its feed) and then checks it every 30 minutes by default. Each new item becomes a post from the template.

The first check posts only the feed's latest item, so adding a feed never floods the account. By default (mode "hold") every new item waits for a person to approve it: Octopost emails the owner Approve / Reject / Edit links, so tell the user to check their email. With mode "queue" new items join the posting queue and publish in queue slots. A feed makes at most 10 posts a day; the same text to the same network within 7 days is skipped; a blocked term holds the post. Posts are shortened to fit each network (the excerpt first, then the title; the link is kept whole).

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>",
      "platforms": "<platforms>"
    },
    "name": "add_feed"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe feed URL (or the site address, if its page links a feed).
modeNoOptional. "hold" (default): each new item waits for a person to approve it. "queue": new items join the posting queue.
nameNoOptional. A name for the feed. Default: the feed's own title.
templateNoOptional. Post text with {title}, {url} and {excerpt} (a plain-text summary of the item). Default "{title} {url}".
platformsYesNetworks each new item is posted to. Call list_accounts first.
check_every_minutesNoOptional. How often to check, 15 to 1440 minutes. Default 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only flag readOnly=false, openWorld=true, and idempotent=false; the description goes far beyond them by disclosing the polling cadence, the first-check-only-latest-item rule, the hold-vs-queue approval workflow with emailed Approve/Reject/Edit links, the 10-posts-per-day cap, 7-day duplicate suppression, blocked-term holding, and text shortening behavior. That is exactly the mutation side-effect context an agent needs before calling.

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?

Three paragraphs, front-loaded with what the tool does and then the side-effect rules; every sentence carries substantive information. It is on the longer side, but the length is justified by the number of behavioral rules being disclosed.

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

Completeness4/5

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

For a six-parameter mutation tool with no output schema and no destructive annotation, the description covers timing, rate limits, deduplication, approval flow, and platform constraints thoroughly. The only material gap is that it never indicates what the call returns (e.g., a feed identifier needed later by remove_feed or list_feeds).

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 the baseline would be 3, but the description adds real meaning to `mode` by explaining the downstream consequence of each value (approval emails versus queue slots) and reinforces the default behavior. It does not add much beyond the schema for `template`, `name`, or `check_every_minutes`.

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: 'Turn an RSS or Atom feed ... into posts', and names the accepted input variants (feed URL or site address). This clearly separates it from siblings like list_feeds, remove_feed, or the one-off create_post.

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?

It gives strong operational context: the feed is read immediately, rechecked every 30 minutes, and the schema directs the agent to call list_accounts first for platforms. What it lacks is an explicit contrast against create_post or set_evergreen for recurring content, so the when-to-use-vs-alternative routing 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.

All Octopost toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources