Skip to main content
Glama
Sign In
Buffer MCP Server

Buffer MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Run one GraphQL query

graphql_query
Read-onlyIdempotent

Execute a parsed GraphQL query against Buffer's API to retrieve data like posts, schedules, and analytics. Mutations and subscriptions are rejected.

Instructions

One parsed GraphQL query; mutations and subscriptions are refused. Use explicit minimal selections. Current experimental APIs are accessible subject to provider availability.

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": {
      "document": "<document>"
    },
    "name": "graphql_query"
  }
}

Input Schema

NameRequiredDescriptionDefault
accountNoPrivate account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
documentYes
variablesNoNative JSON variables; validated remotely by Buffer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds two genuine behavioral facts beyond that: mutations/subscriptions are rejected, and experimental APIs depend on provider availability. The latter is vague and no error/failure behavior is described.

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?

Two short sentences, front-loaded with the core constraint (one parsed query, no mutations). Efficient, though the trailing 'subject to provider availability' clause is hedged and low-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?

With no output schema and annotations carrying the safety profile, the description covers the essential decision points for a generic GraphQL escape hatch: what it accepts, what it rejects. Remaining gaps (error shape, auth/rate limits, relationship to preview helpers) are minor for a read-only query tool.

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 67%: account and variables are documented in-schema, but the required 'document' parameter has no schema description. The phrase 'parsed GraphQL query' partially compensates by clarifying its expected content, and 'explicit minimal selections' constrains authoring, but nothing explains the relationship between document and variables beyond the schema's own note.

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+resource ('One parsed GraphQL query') and immediately bounds it by refusing mutations and subscriptions, which cleanly separates it from graphql_mutation. It does not explicitly name the sibling, but the boundary is unambiguous to an agent.

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 refusal of mutations/subscriptions implicitly routes write operations to graphql_mutation, and 'Use explicit minimal selections' is a query-authoring directive. However, it never states when to reach for this raw tool versus the many typed helpers (get_post, get_channels) or preview_operation, leaving usage mostly inferred.

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