Skip to main content
Glama
thenavidm

Buffer MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get post templates

get_post_templates
Read-onlyIdempotent

Fetch post templates visible to the current actor: public, organization internal, and private, with optional visibility filtering and pagination.

Instructions

Fetch the templates visible to the current actor for the template library: public templates, plus internal templates from the supplied organizationId, plus private templates owned by the actor's account. The visibility scope is always pinned to the actor and the supplied organization — the input filter can only narrow within that scope, never widen it.. Current Buffer GraphQL postTemplates. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

Input Schema

NameRequiredDescriptionDefault
afterNoOpaque cursor from pageInfo.endCursor. One page per ordinary call.
firstNoLocal page-size cap 100, default 25; provider may impose additional query limits.
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.
filterNo
accountNoPrivate account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
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.
organizationIdNoOrganization to scope `internal`-visibility templates to. The caller must be a member of this organization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv3.0.1
    • addedInput schema / $defs
      Added value: +{
+  "filter": {
+    "additionalProperties": false,
+    "properties": {
+      "visibility": {
+        "description": "Narrow the result to a single visibility scope. Omit to receive the\nunion of: public templates, internal templates from the supplied\norganization, and private templates from the actor's account.",
+        "enum": [
+          "internal",
+          "private",
+          "public"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [],
+    "type": "object"
+  }
+}
    • addedInput schema / properties / filter / $ref
      Added value: +"#/$defs/filter"
    • removedInput schema / properties / filter / additionalProperties
      Removed value: -false
    • removedInput schema / properties / filter / properties
      Removed value: -{
-  "visibility": {
-    "description": "Narrow the result to a single visibility scope. Omit to receive the\nunion of: public templates, internal templates from the supplied\norganization, and private templates from the actor's account.",
-    "enum": [
-      "internal",
-      "private",
-      "public"
-    ],
-    "type": "string"
-  }
-}
    • removedInput schema / properties / filter / required
      Removed value: -[]
    • removedInput schema / properties / filter / type
      Removed value: -"object"
    • addedInput schema / properties / payload / properties / filter / $ref
      Added value: +"#/$defs/filter"
    • removedInput schema / properties / payload / properties / filter / additionalProperties
      Removed value: -false
    • removedInput schema / properties / payload / properties / filter / properties
      Removed value: -{
-  "visibility": {
-    "description": "Narrow the result to a single visibility scope. Omit to receive the\nunion of: public templates, internal templates from the supplied\norganization, and private templates from the actor's account.",
-    "enum": [
-      "internal",
-      "private",
-      "public"
-    ],
-    "type": "string"
-  }
-}
    • removedInput schema / properties / payload / properties / filter / required
      Removed value: -[]
    • removedInput schema / properties / payload / properties / filter / type
      Removed value: -"object"
  2. First observedv2.0.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real behavior on top: visibility is pinned and cannot be widened by input, there is no automatic pagination, and provider errors surface as failures even on HTTP 200. Those are exactly the traits an agent cannot read off the annotations.

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?

Front-loads the scope definition, then tacks on pagination and error behavior in short declarative sentences. Slightly dense and contains a doubled-period typo, but every sentence carries information.

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 an 8-parameter, nested-object, no-output-schema tool it covers the critical unknowns: scoping rules, the org-membership requirement, pagination behavior, and failure semantics. It says nothing about the shape of returned templates, which is the main remaining gap given there is no output schema.

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 already 88%, so the baseline is 3. The description adds genuine semantics beyond the schema by explaining that the visibility enum/filter narrows a pre-pinned union rather than defining it, plus guidance on using upstream field paths to bound the payload.

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?

States a specific verb (Fetch) and resource (post templates), and goes further by enumerating the three-union visibility scope (public, internal for the supplied org, private for the actor). It never names the singular sibling get_post_template or the write siblings create/update/delete_post_template, so the reader must infer the list-vs-single distinction.

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?

Gives usable invocation context: the scope is pinned to actor+organization, the filter can only narrow within it, it is one request with no automatic pagination, and upstream fields should be used to bound data. No explicit when-not or named alternative against get_post_template is provided, so it stops short of full routing guidance.

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