Skip to main content
Glama
Sign In
Buffer MCP Server

Buffer MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List idea groups (folders) for an organization

get_idea_groups
Read-onlyIdempotent

List idea groups (folders) for a Buffer organization to view and organize content ideas. Provide organization ID and optional fields; returns one page without automatic pagination.

Instructions

List idea groups (folders) for an organization. Current Buffer GraphQL ideaGroups. One request, no automatic pagination. 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": "get_idea_groups"
  }
}

Input Schema

NameRequiredDescriptionDefault
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.
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.
organizationIdNoUnique identifier for the organization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint, destructiveHint=false, idempotentHint) and open-world access. The description adds genuine traits beyond them: no automatic pagination, field-based bounding to limit data, and the important caveat that provider errors surface as failures even with HTTP 200. That error-semantics disclosure is real value.

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?

Three tight sentences with the purpose front-loaded, then operational constraints. 'Current Buffer GraphQL ideaGroups' is mild jargon but earns its place by grounding the operation in the upstream API.

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 read-only list tool with no output schema and a nested payload shape, the description covers the essentials an agent needs: no auto-pagination, field bounding, and HTTP-200 error behavior. Mutual exclusivity of payload vs payload_file vs individual fields is left to the schema, which handles it adequately.

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 each of the five parameters (fields, account, payload, payload_file, organizationId) is already documented, including the items.id / pageInfo.endCursor conventions. The description's 'use upstream fields to bound data' only echoes the fields parameter, adding no syntax or format detail beyond the schema. 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?

States a specific verb (List) and resource (idea groups / folders) scoped to an organization, and names the upstream GraphQL field (ideaGroups), which is enough to distinguish it from the similarly named get_ideas sibling. It stops short of explicitly contrasting itself with get_ideas, but the resource difference is clear.

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?

Provides operational guidance ('One request, no automatic pagination', 'Use upstream fields to bound data') but no when-to-use/when-not-to-use context or routing to alternatives such as get_ideas. Usage is implied rather than framed.

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