Skip to main content
Glama
thenavidm

Buffer MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create a post template visible only to the caller (`private`) or to the caller's organization (`internal`).

create_post_template
Destructive

Create a Buffer post template visible privately or to your organization, with a title, body, and optional emoji for reuse.

Instructions

Create a post template visible only to the caller (private) or to the caller's organization (internal).. Current Buffer GraphQL createPostTemplate. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoThe main content body of the template, may contain {{placeholders}}.
emojiNoThe emoji associated with the template.
titleNoThe title of the template.
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.
accountNoPrivate account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
confirmNoMust be true for this exact user-requested Buffer mutation.
payloadNoComplete native input object instead of individual input fields.
visibilityNoDefaults to `private` if omitted. `public` is rejected — it is only available to official Buffer clients.
descriptionNoA short user-facing description of the template. Nullable for backwards-compat at the GraphQL boundary — the resolver rejects null/empty values with a clear input error so the underlying storage contract (non-empty string) is still honored.
payload_fileNoRegular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
organizationIdNoOrganization the template belongs to. The caller must be a member of this organization. For `internal` visibility this is the team scope; for `private` it's recorded on the template but does not affect visibility.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds the confirmation requirement and the useful warning that provider errors are failures even with HTTP 200, but it does not explain that `payload`/`payload_file`/individual fields are mutually exclusive or what the confirmation actually gates.

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 description opens with an exact restatement of the title, complete with a doubled period, before adding two boilerplate sentences. The valuable content (confirmation requirement, provider-error caveat) is buried after redundant text rather than front-loaded.

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

Completeness3/5

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

For an 11-parameter nested mutation with no output schema, the description covers the confirmation gate and error semantics but says nothing about how to choose among the three input modes (individual fields, `payload`, `payload_file`). The rich schema compensates for most of the gap, so this is merely adequate.

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 documents all 11 parameters thoroughly, including the visibility enum and the mutual-exclusion note on payload_file. The description adds only the private/internal framing already present in the title. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description state a specific verb and resource (create a post template) and name the two relevant visibility scopes (`private`, `internal`), which distinguishes it from read-only siblings like get_post_templates. However, the description mostly restates the title verbatim, including a duplicated trailing period, so it adds no differentiation beyond the title itself.

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

Usage Guidelines3/5

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

The description does state one concrete precondition: 'Requires explicit confirmation.' It does not, however, tell the agent when to prefer this over update_post_template, delete_post_template, or the generic graphql_mutation, nor does it say what happens when `confirm` is false.

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