Skip to main content
Glama

Mark a post evergreen

set_evergreen
Idempotent

Mark a post evergreen (or not). When the posting queue runs empty, Octopost posts an evergreen post again in the empty queue slot, picking the one that has rested longest. The same post goes out at most once every 30 days, and never while the same text is on (or going to) the same network within those 30 days, so X's rule against repeating a recent post is respected. A draft or scheduled post can be marked now and becomes eligible once it has been published. Only works while the queue is on (update_queue_settings).

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": {
      "post_id": "<post_id>",
      "evergreen": "<evergreen>"
    },
    "name": "set_evergreen"
  }
}

Input Schema

NameRequiredDescriptionDefault
post_idYesThe post ID (UUID).
evergreenYestrue to mark it evergreen, false to stop re-posting it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (idempotent, non-destructive, non-readonly), the description discloses substantive behavior: the empty-queue trigger, longest-rested selection, the 30-day per-post floor, the same-text/same-network suppression rule including X's policy, and draft/scheduled eligibility timing. That is exactly the kind of consequence-level context annotations cannot express.

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 is front-loaded in the first clause, and every following sentence carries non-redundant information (trigger, cadence, suppression rule, eligibility, prerequisite). It is slightly dense, but no sentence is filler and the ordering is logical.

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?

For a two-parameter mutation with no output schema, the description covers everything needed to call it correctly and predict outcomes: when it takes effect, how often, what constraints apply, and the queue-on dependency. Nothing an agent needs is missing.

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% and both parameters are already documented in the schema (post_id UUID, evergreen boolean toggling re-posting). The description adds only marginal meaning beyond that, mainly the timing nuance that a marked draft becomes eligible only after publication. Baseline 3 is appropriate since the schema does the heavy lifting.

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+resource ("Mark a post evergreen") and immediately explains what evergreen actually means in this product (re-posted into an empty queue slot, longest-rested first). The parenthetical "(or not)" plus the queue reference distinguish it cleanly from scheduling/publishing siblings like schedule_post or queue_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 states the operational prerequisite explicitly: "Only works while the queue is on (update_queue_settings)," and clarifies that drafts/scheduled posts can be marked now but only become eligible after publishing. It does not name an alternative tool for the opposite intent, but the eligibility and prerequisite guidance covers the main when/when-not decisions.

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