Skip to main content
Glama
thenavidm

Buffer MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Remove a post from a content item

remove_post_from_content_item
Destructive

Remove a post from a content item while keeping the post on its own channel, including schedule, text, status, and tags; only the content item link is removed.

Instructions

Remove a post from a content item. The post survives on its own channel and keeps its schedule, text, status, and tags. Only the link to the content item goes away. To delete a post, call deletePost.

A second call with a post that belongs to no content item changes nothing, and the mutation reports success.. Current Buffer GraphQL removePostFromContentItem. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

Input Schema

NameRequiredDescriptionDefault
idNoThe content item to remove the post from.
fieldsNoUpstream field paths relative to the result, as in official CLI --fields. Default fields are bounded. Use items.id for connection nodes; pageInfo.endCursor for cursors.
postIdNoThe post to remove from a content item.
accountNoPrivate account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
confirmNoSet true only when the user asked for exactly this action.
payloadNoComplete native input object instead of individual input fields.
payload_fileNoRegular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.1
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true for this exact user-requested Buffer mutation."New value: +"Set true only when the user asked for exactly this action."
  2. First observedv2.0.0

TDQS

A4/5.0
Behavior4/5

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

Goes well beyond the annotations by spelling out exactly what is destroyed (only the link) and what survives (channel, schedule, text, status, tags), plus the no-op-on-repeat behavior and that provider errors surface even at HTTP 200. Note a soft tension: destructiveHint=true while the text emphasizes the post survives and only the link is removed, and the described repeat-call no-op reads as idempotent despite idempotentHint=false.

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 core is front-loaded and the lifecycle/alternative sentences earn their place, but the trailing block ('Current Buffer GraphQL removePostFromContentItem… provider errors are failures even with HTTP 200') reads as leaked context crammed on, and the double period after 'success..' is sloppy. Mixed structure.

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 7-param mutation wrapper with no output schema, the description covers purpose, the delete alternative, preservation semantics, confirmation, and error behavior, which is enough to call it correctly. Remaining gaps (batching/idempotency edge cases) are minor.

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 description coverage is 100%, so the schema already documents all seven parameters (including the payload_file/payload mutual exclusivity). The description only lightly reinforces this with 'Requires explicit confirmation' and 'Use upstream fields to bound data', which don't add syntax beyond what the schema states. Baseline 3 applies.

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?

Opens with a specific verb+resource ('Remove a post from a content item') and immediately disambiguates from the obvious sibling by routing deletions to deletePost. An agent can distinguish this unlink operation from delete_post without opening either schema.

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?

Explicitly names the alternative for the delete case ('To delete a post, call deletePost') and states the confirmation requirement, giving clear selection context. It stops short of covering other siblings (e.g. move_post_in_queue, delete_content_item), so it isn't a full when/when-not map.

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