Buffer MCP Server

Overview Schema Source Related Servers Discussions Admin

Create post template

create_post_template

Destructive

Create private or internal Buffer post templates with a title, body, and placeholders. Requires explicit confirmation before saving to your organization.

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_post_template"
  }
}

Input Schema

Name	Required	Description
`body`	No	The main content body of the template, may contain {{placeholders}}.
`emoji`	No	The emoji associated with the template.
`title`	No	The title of the template.
`fields`	No	Upstream 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.
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete native input object instead of individual input fields.
`visibility`	No	Defaults to `private` if omitted. `public` is rejected — it is only available to official Buffer clients.
`description`	No
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv3.0.1Oct 5, 2026

addedInput schema / $defs

Added value: +{
+  "description": {
+    "description": "A short user-facing description of the template. Nullable for\nbackwards-compat at the GraphQL boundary — the resolver rejects\nnull/empty values with a clear input error so the underlying\nstorage contract (non-empty string) is still honored.",
+    "type": "string"
+  },
+  "organizationId": {
+    "description": "Organization the template belongs to. The caller must be a member of\nthis organization. For `internal` visibility this is the team scope;\nfor `private` it's recorded on the template but does not affect\nvisibility.",
+    "type": "string"
+  }
+}

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."

addedInput schema / properties / description / $ref
```
Added value: +"#/$defs/description"
```

removedInput schema / properties / description / description

Removed value: -"A short user-facing description of the template. Nullable for\nbackwards-compat at the GraphQL boundary — the resolver rejects\nnull/empty values with a clear input error so the underlying\nstorage contract (non-empty string) is still honored."

removedInput schema / properties / description / type
```
Removed value: -"string"
```
addedInput schema / properties / organizationId / $ref
```
Added value: +"#/$defs/organizationId"
```

removedInput schema / properties / organizationId / description

Removed value: -"Organization the template belongs to. The caller must be a member of\nthis organization. For `internal` visibility this is the team scope;\nfor `private` it's recorded on the template but does not affect\nvisibility."

removedInput schema / properties / organizationId / type
```
Removed value: -"string"
```
addedInput schema / properties / payload / properties / description / $ref
```
Added value: +"#/$defs/description"
```

removedInput schema / properties / payload / properties / description / description

Removed value: -"A short user-facing description of the template. Nullable for\nbackwards-compat at the GraphQL boundary — the resolver rejects\nnull/empty values with a clear input error so the underlying\nstorage contract (non-empty string) is still honored."

removedInput schema / properties / payload / properties / description / type
```
Removed value: -"string"
```
addedInput schema / properties / payload / properties / organizationId / $ref
```
Added value: +"#/$defs/organizationId"
```

removedInput schema / properties / payload / properties / organizationId / description

Removed value: -"Organization the template belongs to. The caller must be a member of\nthis organization. For `internal` visibility this is the team scope;\nfor `private` it's recorded on the template but does not affect\nvisibility."

removedInput schema / properties / payload / properties / organizationId / type
```
Removed value: -"string"
```

First observedv2.0.0Oct 3, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description adds real value beyond those: it discloses the mandatory confirmation requirement, the visibility scoping rules, and that provider errors surface as failures even under HTTP 200. That last point is useful behavioral context not present in annotations.

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 content is compact but poorly structured: a stray double period mid-sentence and three unrelated points (visibility, GraphQL origin, confirmation/error handling) jammed together. The GraphQL sentence adds some provenance context but the flow is run-on rather than front-loaded.

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?

There is no output schema, so the description needn't explain returns. With 11 parameters and nested payload/payload_file options, it covers confirmation, visibility semantics, and error behavior adequately, though it omits guidance on the mutually exclusive payload vs payload_file vs individual-field input paths an agent must pick between.

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 82%, so the schema already documents most parameters, establishing a baseline of 3. The description adds meaning for the visibility parameter by mapping private/internal to visible-to-caller vs organization scope, but it says nothing about payload vs individual fields vs payload_file or the confirm flag beyond the general confirmation remark.

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 description states a specific verb and resource ('Create a post template') and clarifies the visibility scopes (private vs internal), which helps distinguish it from siblings like update_post_template or create_post. It does not explicitly name a sibling to contrast against, but the purpose is unmistakable.

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?

It notes 'Requires explicit confirmation' and 'Use upstream fields to bound data; provider errors are failures even with HTTP 200', which gives some operational context. However, it never says when to choose this tool over alternatives (e.g., create_post vs create_post_template) or states prerequisites beyond confirmation, leaving usage mostly implied.

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