What can you do with this server?

Manage Buffer social media content and accounts via 41 MCP/CLI tools, with reads and confirmation-gated mutations. * Discover your account, organizations, channels, configuration, and daily posting limits. * Read, create, edit, delete, schedule, and queue posts; add or remove posts from content items. * Manage content items and channel-less drafts, including promoting drafts to posts. * Read and manage post templates with private/internal visibility. * Read ideas and idea groups; create new ideas. * Read aggregated post metrics and analytics for a date range. * Search, retrieve, and load trending Instagram audio. * Read tags and individual tag details. * Run generic GraphQL queries and confirmed GraphQL mutations. * Preview named operations locally, inspect operation schemas, and paginate bounded reads (1–5 pages). * Use multiple private account profiles, read-only mode, and explicit confirmation for mutations.

Which integrations are available for this server?

Provides tools for interacting with Buffer's GraphQL API, enabling account and channel discovery, post scheduling and publishing, content item/draft management, post templates, and analytics through reads and confirmation-gated mutations.

How do I use Buffer MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Buffer MCP Server list my scheduled posts for the next week with minimal fields" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Buffer MCP Server

by thenavidm

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Buffer MCP Server & CLI

npm License YouTube LinkedIn

Buffer MCP server and CLI for Codex and AI agents. 41 tools for current GraphQL account, channels, posts, content items, templates and analytics, with private accounts and explicit operation approval. One shared implementation supplies both binaries and a desktop bundle.

Built and maintained by Navid Moazzez. The complete guide is on navid.me.

The terminal illustrates real command names and approval flow. It is not a recording of a provider account run. Buffer already has official CLI and hosted MCP products; their current schemas, field selection and supported workflows are compared below.

Requires Node 22+ and eligible Buffer API access for account operations. Validation: fixture tests, schema validation and protocol/artifact discovery are separate from provider-account outcomes, desktop GUI outcomes and fresh measured task/token evidence. Pending evidence is recorded, without invented success rates or efficiency claims.

Two ways to use it

Command line

npm install -g @thenavidm/buffer-mcp-cli@latest
buffer-cli
buffer-cli get-account --fields id --agent
buffer-cli schema create-post
buffer-cli create-post --payload-file /absolute/private/approved-post.json --account work --confirm --agent

MCP server, for your AI app

codex mcp add buffer -- npx -y @thenavidm/buffer-mcp-cli@latest

Configure private credentials first. Ask: “Read scheduled posts for this exact organization with minimal fields; do not create or change any posts.” Full setup is in INSTALL.md.

Which one

Where you work	Surface
Codex or shell agent	Shared CLI, local MCP or both
Desktop chat	Compatible local MCP or desktop bundle
Scripts / CI	CLI or MCP client
Remote-only client	Official Buffer hosted MCP

Related MCP server: socialclaw

Features

Capability	CLI	MCP
Account / channel discovery	get-account / get-channel	get_account / get_channel
Deliberate publishing	create-post / edit-post	create_post / edit_post
Content item / draft work	create-content-item / create-content-item-draft	create_content_item / create_content_item_draft
Template workflows	get-post-templates / create-post-template	get_post_templates / create_post_template
Bounded cursor reads	query-pages	query_pages
Local validation / fields	preview-operation / get-operation-schema	preview_operation / get_operation_schema
Profiles and policy	list-accounts / --account / --confirm	list_accounts / account / confirm
Generic current GraphQL	graphql-query / graphql-mutation	graphql_query / graphql_mutation

Number	Section	What it covers
1	What you can ask it	What you can ask it
2	Quick install	Quick install
3	Set up Buffer access	Set up Buffer access
4	Connect your client	Connect your client
5	Check it works	Check it works
6	Output, flags and exit codes	Output, flags and exit codes
7	MCP or CLI and token cost	MCP or CLI and token cost
8	Every tool and argument	Every tool and argument
9	Publishing, content items and analytics	Publishing, content items and analytics
10	Pagination, retries and local input files	Pagination, retries and local input files
11	Several private accounts	Several private accounts
12	Writing safely	Writing safely
13	How the two surfaces work	How the two surfaces work
14	Privacy and data handling	Privacy and data handling
15	Environment variables	Environment variables
16	Updates and removal	Updates and removal
17	Troubleshooting	Troubleshooting
18	API coverage and comparisons	API coverage and comparisons
19	Versions	Versions
20	FAQ	FAQ

1. What you can ask it

Identify my account's accessible organizations and connected channels before choosing a target.
Read scheduled posts for one organization with minimal fields and a five-page maximum.
Preview a complete post input locally before approving shareNow, customScheduled or a queue change.
Create only the draft or approved post requested by the human, then inspect its returned ID/status.
Review content items and attached channel drafts before promoting them to posts.
Read and manage the selected post template with its documented visibility.
Read permitted aggregate metrics for the chosen date window.
Delete only the exact post/content item/template requested, after explicit confirmation.

Actual stdio discovery supplies 41 tools: 24 reads and 17 confirmation-gated mutations. Thirty-five named operations come from Buffer's published current CLI schemas, with generic query/mutation, account labels, operation schema inspection, local preview and bounded read pagination. Current experimental snippets/tag mutations remain generic requests with provider validation.

2. Quick install

npm install -g @thenavidm/buffer-mcp-cli@latest
buffer-cli --version
buffer-cli login
buffer-cli doctor
buffer-cli tools

Manual CLI/MCP requires Node 22+. The versioned buffer-2.0.0.mcpb bundles production dependencies for a compatible desktop host. Follow INSTALL.md for complete private setup.

codex mcp add buffer -- npx -y @thenavidm/buffer-mcp-cli@latest
codex mcp list

3. Set up Buffer access

Private API key and account access

Sign in to the intended account's API settings. Create the API key needed for this task and review that client's current quota.
Save it privately as BUFFER_API_KEY, or in a regular token-only file outside every repository and configure its absolute BUFFER_TOKEN_FILE path. BUFFER_API_TOKEN remains a compatibility alias; API_KEY takes precedence when both are supplied.
Run buffer-cli doctor. Then deliberately run doctor --network: it requests only account { id } and prints diagnostic success, never the account ID or provider content.
Read get-account with minimal fields, then inspect account.organizations and choose the exact organization/channel for the task. Use get_operation_schema to discover actual selectable paths.
Review the native input, platform metadata and publishing mode. Preview locally, then confirm only the precise operation the human requested. Successful creation is not proof that a social network published the post.

API keys authenticate through Authorization: Bearer at the fixed https://api.buffer.com endpoint. Personal API keys act across every organization accessible to that account; an organization input/default does not restrict the key. Provider roles, publishing policies and connected-channel grants still apply. Named local profiles route credentials and defaults; they cannot narrow provider authorization.

OAuth access tokens already granted to an app can use the same private credential path. The wrapper does not register apps, open consent, implement PKCE exchange, save refresh tokens or renew expiry. Follow OAuth for current PKCE and organization-specific app grants. PAT and OAuth permissions differ. Analytics uses PAT insightsRead access; current OAuth grants cannot request that analytics scope.

Current OAuth scopes in the provider's authentication guide:

Scope	Purpose
posts:read	Read posts and queues
posts:write	Create and manage posts
ideas:read	Read ideas
ideas:write	Create and manage ideas
account:read	Read account information
account:write	Manage permitted account settings
offline_access	Request a refresh token from the issuer; this wrapper does not refresh it

Request only the grant needed for the intended workflow. A refresh token is not a Bearer API credential. PAT insightsRead analytics is separate from the current OAuth scope list.

Use a private 0700 directory and 0600 regular token-only file on macOS/Linux. Windows users must restrict the file's ACL to their own user; POSIX checks do not establish Windows ACL protection. Files cannot be symlinks or exceed 64 KiB. File credentials override environment keys and are cached until restart. No automatic .env loader, browser credential harvesting or global official CLI configuration is used.

Plans, quotas and query limits

This AGPL wrapper is free. Buffer plans, posting limits, social-network permissions and API quotas are separate. Current API limits document these per-client rolling windows:

Plan	API keys / app clients	15 minutes	24 hours	30 days
Free	1 / 1	100	250	3000
Essentials	3 / 3	100	250	7500
Team	5 / 5	100	500	15000

Official MCP connections share a rate-limit bucket with personal keys; connecting another assistant does not create extra quota. RateLimit and Retry-After headers are returned with successful data; inspect your API settings' live usage. Quotas and query-complexity rules can change; the provider's returned policy takes precedence. The local 200 ms pacing is per profile/process, not a provider quota reservation. Labels sharing a key and several processes still share upstream limits.

Every ordinary command sends one request. query_pages is capped at five pages and 100 records requested per page locally; the provider can reject a smaller or differently constrained query. No request retries automatically, including reads, HTTP 200 GraphQL errors, HTTP 429 or timeouts. Wait for the provider's indicated reset, inspect account state, and make a deliberate retry. A transport timeout can leave a mutation completed remotely.

Local request JSON cap is 1 MiB, document cap 64 KiB/10000 parsed tokens, response cap 5 MiB and default timeout 30 seconds. These limits do not raise upstream query-depth, complexity, array, scheduling or social-network limits. Media URLs must be reachable by Buffer and meet platform constraints; local filesystem paths are not uploaded by this wrapper.

Revocation and rotation

Revoke/rotate the intended key in Buffer API settings or revoke the OAuth app grant through provider controls, update private local configuration and restart. Package uninstall does not revoke the key, disconnect a channel, delete hosted data or unschedule posts. Never send keys, private account exports, signed media links or raw error responses to public issues.

4. Connect your client

INSTALL.md gives Codex-first setup plus optional Claude Code, Claude Desktop bundle/manual routes, Cursor, VS Code/Copilot, Windsurf, Zed, Gemini CLI, Cline and Docker. The same package runs on Node 22+ in macOS/Linux/native Windows. GUI apps and remote development environments need their own accessible private configuration.

Local MCP launches command npx with arguments -y and @thenavidm/buffer-mcp-cli@latest over stdio. This package has no HTTP relay. A remote-only client uses the separately maintained official https://mcp.buffer.com/mcp service. npm ships SKILL.md but does not automatically register an agent skill. Install that shipped file through the client's supported mechanism.

Client-level approvals and local confirm=true are separate. A returned post or instruction in provider content never grants permission to publish. Read-only mode removes mutation discovery and also refuses a direct hidden-tool call.

5. Check it works

buffer-cli --version
buffer-cli doctor
buffer-cli doctor --network
buffer-cli list-accounts --agent
buffer-cli get-account --fields id --agent
buffer-cli get-operation-schema --operation posts --agent

Bare CLI, tools, schemas/help, local account labels and previews need no provider grant. doctor checks configuration presence; only doctor --network validates the minimal account request. A successful read establishes that request and token, not every post/platform or role. Full MCP discovery exposes 41 tools; read-only exposes 24. Invalid input/refused actions exit 2; missing credentials exit 10. Do not publish a real post just to test installation.

6. Output, flags and exit codes

Both surfaces return structured JSON, including native GraphQL data and available rate-limit headers. Connection data remains native edges/node/pageInfo; query_pages returns bounded page responses with continuation state.

buffer-cli create-post --help
buffer-cli schema create-post
buffer-cli get-post --id SELECTED_POST --fields id --fields status --agent --select data.post.id,data.post.status

Flag	Meaning
--agent	JSON, compact, no-input, no-color, yes; does not provide --confirm
--json / --compact	JSON output and compact spacing
--select a,b.c	Keep selected output paths after receipt
--fields id --fields status	Native upstream field selection for supported named operations
--payload / --payload-file	Complete native input JSON or regular private file; do not mix with input fields
--account NAME	Select one private profile
--confirm	Approve the exact requested mutation, subject to enabled policies
--help / schema COMMAND	Actual discovered flags and full input schema

Exit	Meaning
0	Successful local result or provider response
2	Usage, invalid input or refused mutation
3	Not found
4	Authentication or forbidden permission
5	Provider/GraphQL/typed mutation/network failure
7	Rate limit or quota failure
10	Nothing configured or invalid private profile/token configuration

GraphQL can fail inside HTTP 200. errors arrays fail even with partial data; typed mutation error unions fail rather than reporting success. Named mutations require a recognized successful result type. Acceptance/status from Buffer is not an assertion that a downstream social network completed publishing.

7. MCP or CLI and token cost

CLI and MCP share discovery, validation, handlers, accounts and WriteGuard. The house CLI calls the real server through SDK in-memory transport, so no second provider implementation can drift.

Fresh matched Codex task/usage measurements remain pending. Compare the same account/resource, input, upstream fields and completed outcome; include help/schema/discovery, results, retries and reasoning. Record date, model/client/package versions, loading settings, actual input/output tokens and latency.

Mode	Required evidence
Eager MCP	Schemas/instructions actually loaded
Deferred MCP	Selected schemas plus discovery overhead
Skill read once	Actual shipped skill and command help
Recurring skill description	Actual installed listing
Equivalent task	Same read or exact approved mutation and successful outcome

Upstream fields can reduce requested provider data; official CLI supplies this too. --select reduces model-visible result after receipt. Tool counts, schema bytes and character estimates are not task-token savings. CLI does not have zero context cost. Claude Code benchmarks are deferred while Codex is the active client.

8. Every tool and argument

The following sections come from actual stdio discovery. Native input schemas and field-selection trees are reused from the reviewed published official CLI, with strict nested property checks. Required native fields are validated after payload/profile-default routing; they need not appear as top-level required flags because payload is an alternative.

Tool	Native operation	Policy
`get_account`	`account`	Read
`add_post_to_content_item`	`addPostToContentItem`	Confirm exact mutation
`get_aggregated_post_metrics`	`aggregatedPostMetrics`	Read
`get_channel`	`channel`	Read
`get_channels`	`channels`	Read
`get_configuration`	`configuration`	Read
`get_content_item`	`contentItem`	Read
`get_content_items`	`contentItems`	Read
`create_content_item`	`createContentItem`	Confirm exact mutation
`create_content_item_draft`	`createContentItemDraft`	Confirm exact mutation
`create_idea`	`createIdea`	Confirm exact mutation
`create_post`	`createPost`	Confirm exact mutation
`create_post_template`	`createPostTemplate`	Confirm exact mutation
`get_daily_posting_limits`	`dailyPostingLimits`	Read
`delete_content_item`	`deleteContentItem`	Confirm exact mutation
`delete_post`	`deletePost`	Confirm exact mutation
`delete_post_template`	`deletePostTemplate`	Confirm exact mutation
`edit_post`	`editPost`	Confirm exact mutation
`get_idea_groups`	`ideaGroups`	Read
`get_ideas`	`ideas`	Read
`get_instagram_audio`	`instagramAudio`	Read
`move_post_in_queue`	`movePostInQueue`	Confirm exact mutation
`get_post`	`post`	Read
`get_posts`	`posts`	Read
`get_post_template`	`postTemplate`	Read
`get_post_templates`	`postTemplates`	Read
`promote_content_item_draft_to_posts`	`promoteContentItemDraftToPosts`	Confirm exact mutation
`remove_post_from_content_item`	`removePostFromContentItem`	Confirm exact mutation
`get_search_instagram_audio`	`searchInstagramAudio`	Read
`get_tag`	`tag`	Read
`get_tags_v2`	`tagsV2`	Read
`get_trending_instagram_audio`	`trendingInstagramAudio`	Read
`update_content_item`	`updateContentItem`	Confirm exact mutation
`update_content_item_draft`	`updateContentItemDraft`	Confirm exact mutation
`update_post_template`	`updatePostTemplate`	Confirm exact mutation
`list_accounts`	Local/helper or parsed GraphQL	Read
`graphql_query`	Local/helper or parsed GraphQL	Read
`graphql_mutation`	Local/helper or parsed GraphQL	Confirm exact mutation
`preview_operation`	Local/helper or parsed GraphQL	Read
`query_pages`	Local/helper or parsed GraphQL	Read
`get_operation_schema`	Local/helper or parsed GraphQL	Read

get_account

buffer-cli get-account

Argument	Required	Type	Details
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: No required native input fields. Use individual fields or complete payload/payload_file.

Default upstream fields: id, email, organizations.id, organizations.channelCount, timezone. Inspect get_operation_schema for every selectable path.

add_post_to_content_item

buffer-cli add-post-to-content-item

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The content item to add the post to.
`postId`	No; body and guard rules apply	string	The post to add. The post must already exist. The post and the content item must belong to the same organization.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id, postId. Use individual fields or complete payload/payload_file.

Default upstream fields: __typename, contentItem.id, contentItem.accountId, contentItem.allowedActions, contentItem.author.id, contentItem.author.avatar, contentItem.author.email, contentItem.author.isDeleted, contentItem.author.name, contentItem.author.urn, contentItem.body.__typename, contentItem.body.id, contentItem.body.aiAssisted, contentItem.body.assets.__typename, contentItem.body.assets.id, contentItem.body.assets.mimeType, contentItem.body.assets.source, contentItem.body.assets.thumbnail, contentItem.body.assets.type, contentItem.body.text, contentItem.organizationId, contentItem.tags.id, contentItem.tags.color, contentItem.tags.colorName, contentItem.tags.isLocked, contentItem.tags.name, contentItem.targetDate, contentItem.title, contentItem.createdAt, post.id, post.allowedActions, post.assets.__typename, post.assets.id, post.assets.mimeType, post.assets.source, post.assets.thumbnail, post.assets.type, post.author.id, post.author.avatar, post.author.email, post.author.isDeleted, post.author.name, post.author.urn, post.channel.id, post.channel.allowedActions, post.channel.avatar, post.channel.descriptor, post.channel.displayName, post.channel.externalLink, post.channel.hasActiveMemberDevice, post.channel.isDisconnected, post.channel.isLocked, post.channel.isNew, post.channel.isQueuePaused, post.channel.metadata.__typename, post.channel.metadata.defaultToReminders, post.channel.metadata.maxCharacters, post.channel.metadata.serverUrl, post.channel.metadata.subscriptionType, post.channel.metadata.shouldShowLinkedinAnalyticsRefreshBanner, post.channel.metadata.businessPortfolioId, post.channel.metadata.lastSubscribedAt, post.channel.metadata.phoneNumberId, post.channel.metadata.wabaId, post.channel.name, post.channel.organizationId, post.channel.products, post.channel.scopes, post.channel.service, post.channel.serviceId, post.channel.showTrendingTopicSuggestions, post.channel.timezone, post.channel.type, post.channel.createdAt, post.channel.updatedAt, post.channelId, post.channelService, post.contentItemId, post.dueAt, post.error.message, post.error.rawError, post.error.supportUrl, post.externalLink, post.ideaId, post.isCustomScheduled, post.metadata.__typename, post.metadata.firstComment, post.metadata.isAiGenerated, post.metadata.link, post.metadata.shouldShareToFeed, post.metadata.type, post.metadata.title, post.metadata.threadCount, post.metadata.url, post.metadata.details.__typename, post.metadata.details.button, post.metadata.details.link, post.metadata.details.code, post.metadata.details.endDate, post.metadata.details.startDate, post.metadata.details.terms, post.metadata.details.title, post.metadata.details.endTime, post.metadata.details.isFullDayEvent, post.metadata.details.startTime, post.metadata.embeddable, post.metadata.license, post.metadata.madeForKids, post.metadata.notifySubscribers, post.metadata.privacy, post.metadata.spoilerText, post.metadata.locationId, post.metadata.locationName, post.metadata.topic, post.metrics.description, post.metrics.name, post.metrics.type, post.metrics.unit, post.metrics.value, post.metricsUpdatedAt, post.notes.id, post.notes.allowedActions, post.notes.text, post.notes.type, post.notes.createdAt, post.notes.updatedAt, post.notificationStatus, post.schedulingType, post.sentAt, post.sharedNow, post.shareMode, post.status, post.tags.id, post.tags.color, post.tags.colorName, post.tags.isLocked, post.tags.name, post.text, post.via, post.createdAt, post.updatedAt, message. Inspect get_operation_schema for every selectable path.

get_aggregated_post_metrics

buffer-cli get-aggregated-post-metrics

Argument	Required	Type	Details
`channelIds`	No; body and guard rules apply	array	Optional list of channel IDs to filter by. When omitted (null), the aggregate spans every channel in the organization the actor has insights access to. When set to an empty array, no channels match and the result is empty. Items: string.
`endDateTime`	No; body and guard rules apply	string	End of the aggregation window. Consumers typically pass UTC midnight of the last calendar day in the window (the backend treats the range as inclusive of that day), for example `2026-01-31T00:00:00Z`. Date range is capped to 365 days.
`organizationId`	No; body and guard rules apply	string	The organization ID
`startDateTime`	No; body and guard rules apply	string	Start of the aggregation window. Consumers typically pass UTC midnight of the first calendar day in the window, for example `2026-01-01T00:00:00Z`.
`tags`	No; body and guard rules apply	object	See the full input schema.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: endDateTime, organizationId, startDateTime. Use individual fields or complete payload/payload_file.

Default upstream fields: metrics.type, metrics.name, metrics.value, metrics.unit, metricsUpdatedAt. Inspect get_operation_schema for every selectable path.

get_channel

buffer-cli get-channel

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The ID of the channel to be retrieved
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: id. Use individual fields or complete payload/payload_file.

Default upstream fields: id, displayName, service, timezone, serviceId. Inspect get_operation_schema for every selectable path.

get_channels

buffer-cli get-channels

Argument	Required	Type	Details
`filter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	No; body and guard rules apply	string	The Organization id to fetch channels for
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: organizationId. Use individual fields or complete payload/payload_file.

Default upstream fields: id, name, service. Inspect get_operation_schema for every selectable path.

get_configuration

buffer-cli get-configuration

Argument	Required	Type	Details
`organizationId`	No; body and guard rules apply	string	The organization to return configuration for.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: organizationId. Use individual fields or complete payload/payload_file.

Default upstream fields: channels.authorizationStatus.feature, channels.authorizationStatus.reason, channels.authorizationStatus.status, channels.channelId, channels.channelType, channels.content.configurationContentTypes, channels.content.rules.__typename, channels.content.rules.property, channels.content.rules.max, channels.content.rules.min, channels.content.rules.maxLength, channels.content.rules.conflictsWith, channels.content.rules.requires, channels.content.rules.maxMegabytes, channels.content.rules.maxDurationSeconds, channels.content.rules.allowedFormats, channels.content.supportedProperties, channels.engagement.engagementType, channels.engagement.metadata.__typename, channels.engagement.metadata.hasUserRating, channels.engagement.metadata.permanentNote, channels.engagement.supportedAiFeatures, channels.service, services.channelType, services.content.configurationContentTypes, services.content.rules.__typename, services.content.rules.property, services.content.rules.max, services.content.rules.min, services.content.rules.maxLength, services.content.rules.conflictsWith, services.content.rules.requires, services.content.rules.maxMegabytes, services.content.rules.maxDurationSeconds, services.content.rules.allowedFormats, services.content.supportedProperties, services.engagement.engagementType, services.engagement.metadata.__typename, services.engagement.metadata.hasUserRating, services.engagement.metadata.permanentNote, services.engagement.supportedAiFeatures, services.service. Inspect get_operation_schema for every selectable path.

get_content_item

buffer-cli get-content-item

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The unique identifier of the content item to fetch.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: id. Use individual fields or complete payload/payload_file.

Default upstream fields: id, accountId, allowedActions, author.id, author.avatar, author.email, author.isDeleted, author.name, author.urn, body.__typename, body.id, body.aiAssisted, body.assets.__typename, body.assets.id, body.assets.mimeType, body.assets.source, body.assets.thumbnail, body.assets.type, body.text, body.posts.id, body.posts.allowedActions, body.posts.assets.__typename, body.posts.assets.id, body.posts.assets.mimeType, body.posts.assets.source, body.posts.assets.thumbnail, body.posts.assets.type, body.posts.channelId, body.posts.channelService, body.posts.contentItemId, body.posts.dueAt, body.posts.externalLink, body.posts.ideaId, body.posts.isCustomScheduled, body.posts.metadata.__typename, body.posts.metadata.firstComment, body.posts.metadata.isAiGenerated, body.posts.metadata.link, body.posts.metadata.shouldShareToFeed, body.posts.metadata.type, body.posts.metadata.title, body.posts.metadata.threadCount, body.posts.metadata.url, body.posts.metadata.details.__typename, body.posts.metadata.details.button, body.posts.metadata.details.link, body.posts.metadata.details.code, body.posts.metadata.details.endDate, body.posts.metadata.details.startDate, body.posts.metadata.details.terms, body.posts.metadata.details.title, body.posts.metadata.details.endTime, body.posts.metadata.details.isFullDayEvent, body.posts.metadata.details.startTime, body.posts.metadata.embeddable, body.posts.metadata.license, body.posts.metadata.madeForKids, body.posts.metadata.notifySubscribers, body.posts.metadata.privacy, body.posts.metadata.spoilerText, body.posts.metadata.locationId, body.posts.metadata.locationName, body.posts.metadata.topic, body.posts.metricsUpdatedAt, body.posts.notificationStatus, body.posts.schedulingType, body.posts.sentAt, body.posts.sharedNow, body.posts.shareMode, body.posts.status, body.posts.text, body.posts.via, body.posts.createdAt, body.posts.updatedAt, organizationId, tags.id, tags.color, tags.colorName, tags.isLocked, tags.name, targetDate, title, createdAt. Inspect get_operation_schema for every selectable path.

get_content_items

buffer-cli get-content-items

Argument	Required	Type	Details
`filter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	No; body and guard rules apply	string	Organization to list content items for. The caller must be a member of this organization.
`sort`	No; body and guard rules apply	array	Sorting to apply, each entry breaking ties in the one before it. Defaults to newest first. A pagination cursor is only valid for the sort that produced it, so reset `after` to null whenever the sort changes. Items: object.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`first`	No; body and guard rules apply	integer	Local page-size cap 100, default 25; provider may impose additional query limits. minimum: `1`. maximum: `100`.
`after`	No; body and guard rules apply	string	Opaque cursor from pageInfo.endCursor. One page per ordinary call. maxLength: `8192`.

Native input requirements: organizationId. Use individual fields or complete payload/payload_file.

Default upstream fields: items.id, items.accountId, items.allowedActions, items.author.id, items.author.avatar, items.author.email, items.author.isDeleted, items.author.name, items.author.urn, items.body.__typename, items.body.id, items.body.aiAssisted, items.body.assets.__typename, items.body.assets.id, items.body.assets.mimeType, items.body.assets.source, items.body.assets.thumbnail, items.body.assets.type, items.body.text, items.organizationId, items.tags.id, items.tags.color, items.tags.colorName, items.tags.isLocked, items.tags.name, items.targetDate, items.title, items.createdAt, pageInfo.endCursor, pageInfo.hasNextPage, pageInfo.hasPreviousPage, pageInfo.startCursor. Inspect get_operation_schema for every selectable path.

create_content_item

buffer-cli create-content-item

Argument	Required	Type	Details
`organizationId`	No; body and guard rules apply	string	Organization that owns the content item and all variants created in it.
`posts`	No; body and guard rules apply	array	The channel-specific post variants to create, one per channel. Provide at least one variant, and at most one variant per channel. Items: object.
`tagIds`	No; body and guard rules apply	array	Tags to apply to this content item. Omit to create it with no tags. Items: string.
`targetDate`	No; body and guard rules apply	string	Optional date indicating when this piece of content should go out. This is a planning aid only and does not schedule any posts.
`title`	No; body and guard rules apply	string	Optional title describing what this piece of content is about.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: organizationId, posts. Use individual fields or complete payload/payload_file.

Default upstream fields: __typename, content.id, content.accountId, content.allowedActions, content.author.id, content.author.avatar, content.author.email, content.author.isDeleted, content.author.name, content.author.urn, content.body.__typename, content.body.id, content.body.aiAssisted, content.body.assets.__typename, content.body.assets.id, content.body.assets.mimeType, content.body.assets.source, content.body.assets.thumbnail, content.body.assets.type, content.body.text, content.organizationId, content.tags.id, content.tags.color, content.tags.colorName, content.tags.isLocked, content.tags.name, content.targetDate, content.title, content.createdAt, errors.__typename, errors.message, errors.channelId, message. Inspect get_operation_schema for every selectable path.

create_content_item_draft

buffer-cli create-content-item-draft

Argument	Required	Type	Details
`correlationId`	No; body and guard rules apply	string	Client-generated UUID that makes draft creation idempotent. A retry with the same UUID in the same organization returns the first content item in its current state.
`draft`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	No; body and guard rules apply	string	Organization that will own the content item.
`tagIds`	No; body and guard rules apply	array	Tags to apply to this content item. Omit to create it with no tags. Items: string.
`targetDate`	No; body and guard rules apply	string	Optional date indicating when this piece of content should go out. This is a planning aid only and does not schedule any posts.
`title`	No; body and guard rules apply	string	Optional title describing what this piece of content is about.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: draft, organizationId. Use individual fields or complete payload/payload_file.

create_idea

buffer-cli create-idea

Argument	Required	Type	Details
`content`	No; body and guard rules apply	object	See the full input schema.
`cta`	No; body and guard rules apply	string	Call-to-action identifier for analytics tracking
`group`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	No; body and guard rules apply	string	Organization ID that will own the idea
`templateId`	No; body and guard rules apply	string	Template ID used to create the idea
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: content, organizationId. Use individual fields or complete payload/payload_file.

Default upstream fields: __typename, id, content.aiAssisted, content.date, content.media.id, content.media.alt, content.media.size, content.media.thumbnailUrl, content.media.type, content.media.url, content.services, content.tags.id, content.tags.color, content.tags.colorName, content.tags.name, content.text, content.title, groupId, organizationId, position, createdAt, updatedAt, idea.id, idea.content.aiAssisted, idea.content.date, idea.content.services, idea.content.text, idea.content.title, idea.groupId, idea.organizationId, idea.position, idea.createdAt, idea.updatedAt, refreshIdeas, message. Inspect get_operation_schema for every selectable path.

create_post

buffer-cli create-post

Argument	Required	Type	Details
`aiAssisted`	No; body and guard rules apply	boolean	If this post was created with the help of AI
`assets`	No; body and guard rules apply	array	Ordered list of assets on this post. Items: object.
`channelId`	No; body and guard rules apply	string	Channel's Id for which we want to create the post
`draftId`	No; body and guard rules apply	string	Is set when the Post is generated from a Draft
`dueAt`	No; body and guard rules apply	string	Date when the post is scheduled to be published
`ideaId`	No; body and guard rules apply	string	Is set when the Post is generated from an Idea
`metadata`	No; body and guard rules apply	object	See the full input schema.
`mode`	No; body and guard rules apply	string	How the post is being scheduled. Values: `addToQueue`, `customScheduled`, `shareNext`, `shareNow`.
`needsApproval`	No; body and guard rules apply	boolean	Submit the post for approval instead of scheduling it. A post submitted for approval is always a draft, so this conflicts with turning `saveToDraft` off. Only valid when your posting policy on the target channel requires approval.
`saveToDraft`	No; body and guard rules apply	boolean	If true, saves the post as a draft instead of scheduling it. When saving as draft: - Post status will be 'draft' instead of 'buffer' - Posting limits are not checked - The post will not be published until explicitly scheduled
`schedulingType`	No; body and guard rules apply	string	Scheduling type to indicate notification publishing or automatic publishing Values: `automatic`, `notification`.
`source`	No; body and guard rules apply	string	source where the composer was initiated from, used for tracking.
`tagIds`	No; body and guard rules apply	array	List of tag IDs Items: string.
`text`	No; body and guard rules apply	string	Text content of the Post. Note: for threaded posts, this needs to match the first item in the `thread` array.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: channelId, mode, schedulingType. Use individual fields or complete payload/payload_file.

Default upstream fields: post.id, post.status. Inspect get_operation_schema for every selectable path.

create_post_template

buffer-cli create-post-template

Argument	Required	Type	Details
`body`	No; body and guard rules apply	string	The main content body of the template, may contain {{placeholders}}.
`description`	No; body and guard rules apply	string	A 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.
`emoji`	No; body and guard rules apply	string	The emoji associated with the template.
`organizationId`	No; body and guard rules apply	string	Organization 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.
`title`	No; body and guard rules apply	string	The title of the template.
`visibility`	No; body and guard rules apply	string	Defaults to `private` if omitted. `public` is rejected — it is only available to official Buffer clients. Values: `internal`, `private`, `public`.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: body, organizationId, title. Use individual fields or complete payload/payload_file.

Default upstream fields: __typename, postTemplate.id, postTemplate.body, postTemplate.description, postTemplate.emoji, postTemplate.organizationId, postTemplate.title, postTemplate.visibility, postTemplate.createdAt, postTemplate.updatedAt, message. Inspect get_operation_schema for every selectable path.

get_daily_posting_limits

buffer-cli get-daily-posting-limits

Argument	Required	Type	Details
`channelIds`	No; body and guard rules apply	array	List of channel IDs to check limits for. All channels must belong to the same organization. Items: string.
`date`	No; body and guard rules apply	string	The date to check limits for. Defaults to today if not provided.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: channelIds. Use individual fields or complete payload/payload_file.

Default upstream fields: channelId, isAtLimit, limit, scheduled, sent. Inspect get_operation_schema for every selectable path.

delete_content_item

buffer-cli delete-content-item

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The content item to delete.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id. Use individual fields or complete payload/payload_file.

Default upstream fields: __typename, _empty, errors.channelId, errors.message, message. Inspect get_operation_schema for every selectable path.

delete_post

buffer-cli delete-post

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	Post id to delete.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id. Use individual fields or complete payload/payload_file.

Default upstream fields: __typename, id, message. Inspect get_operation_schema for every selectable path.

delete_post_template

buffer-cli delete-post-template

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The ID of the template to delete.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id. Use individual fields or complete payload/payload_file.

Default upstream fields: __typename, _empty, message. Inspect get_operation_schema for every selectable path.

edit_post

buffer-cli edit-post

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	ID of the post to edit
`aiAssisted`	No; body and guard rules apply	boolean	If this post was edited with the help of AI
`approvalChange`	No; body and guard rules apply	string	Change the post's approval state alongside this edit. Leave unset to keep the post's current approval state. Only valid when your posting policy on the post's channel requires approval, and only on your own drafts. Asking for the state the post is already in does nothing. Values: `request`, `revert`.
`assets`	No; body and guard rules apply	array	Ordered list of assets on this post. Omit to preserve the existing list, pass an empty array to clear it Items: object.
`draftId`	No; body and guard rules apply	string	Is set when the Post is generated from a Draft
`dueAt`	No; body and guard rules apply	string	Date when the post is scheduled to be published
`ideaId`	No; body and guard rules apply	string	Is set when the Post is generated from an Idea
`metadata`	No; body and guard rules apply	object	See the full input schema.
`mode`	No; body and guard rules apply	string	How the post is being scheduled. Omit the field or pass null to make no scheduling change — null does not clear or reset the schedule: a scheduled post keeps its current share mode, queue slot, and any custom time, and the edit applies only the other provided fields. Pass a non-null ShareMode to apply that mode. Values: `addToQueue`, `customScheduled`, `shareNext`, `shareNow`.
`saveToDraft`	No; body and guard rules apply	boolean	If true, saves the post as a draft instead of keeping it scheduled. When saving as draft: - Post status will be 'draft' instead of 'buffer' - The post will not be published until explicitly scheduled
`schedulingType`	No; body and guard rules apply	string	Scheduling type to indicate notification publishing or automatic publishing. Omit it, or send null, to leave the post publishing the way it already does. Values: `automatic`, `notification`.
`source`	No; body and guard rules apply	string	source where the composer was initiated from, used for tracking.
`tagIds`	No; body and guard rules apply	array	tags Items: string.
`text`	No; body and guard rules apply	string	Text content of the Post. Omit the field to keep the current text; pass an empty string or null to clear it. Note: for threaded posts, this needs to match the first item in the `thread` array.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id. Use individual fields or complete payload/payload_file.

Default upstream fields: __typename, post.id, post.allowedActions, post.assets.__typename, post.assets.id, post.assets.mimeType, post.assets.source, post.assets.thumbnail, post.assets.type, post.author.id, post.author.avatar, post.author.email, post.author.isDeleted, post.author.name, post.author.urn, post.channel.id, post.channel.allowedActions, post.channel.avatar, post.channel.descriptor, post.channel.displayName, post.channel.externalLink, post.channel.hasActiveMemberDevice, post.channel.isDisconnected, post.channel.isLocked, post.channel.isNew, post.channel.isQueuePaused, post.channel.metadata.__typename, post.channel.metadata.defaultToReminders, post.channel.metadata.maxCharacters, post.channel.metadata.serverUrl, post.channel.metadata.subscriptionType, post.channel.metadata.shouldShowLinkedinAnalyticsRefreshBanner, post.channel.metadata.businessPortfolioId, post.channel.metadata.lastSubscribedAt, post.channel.metadata.phoneNumberId, post.channel.metadata.wabaId, post.channel.name, post.channel.organizationId, post.channel.products, post.channel.scopes, post.channel.service, post.channel.serviceId, post.channel.showTrendingTopicSuggestions, post.channel.timezone, post.channel.type, post.channel.createdAt, post.channel.updatedAt, post.channelId, post.channelService, post.contentItemId, post.dueAt, post.error.message, post.error.rawError, post.error.supportUrl, post.externalLink, post.ideaId, post.isCustomScheduled, post.metadata.__typename, post.metadata.firstComment, post.metadata.isAiGenerated, post.metadata.link, post.metadata.shouldShareToFeed, post.metadata.type, post.metadata.title, post.metadata.threadCount, post.metadata.url, post.metadata.details.__typename, post.metadata.details.button, post.metadata.details.link, post.metadata.details.code, post.metadata.details.endDate, post.metadata.details.startDate, post.metadata.details.terms, post.metadata.details.title, post.metadata.details.endTime, post.metadata.details.isFullDayEvent, post.metadata.details.startTime, post.metadata.embeddable, post.metadata.license, post.metadata.madeForKids, post.metadata.notifySubscribers, post.metadata.privacy, post.metadata.spoilerText, post.metadata.locationId, post.metadata.locationName, post.metadata.topic, post.metrics.description, post.metrics.name, post.metrics.type, post.metrics.unit, post.metrics.value, post.metricsUpdatedAt, post.notes.id, post.notes.allowedActions, post.notes.text, post.notes.type, post.notes.createdAt, post.notes.updatedAt, post.notificationStatus, post.schedulingType, post.sentAt, post.sharedNow, post.shareMode, post.status, post.tags.id, post.tags.color, post.tags.colorName, post.tags.isLocked, post.tags.name, post.text, post.via, post.createdAt, post.updatedAt, message, code, link. Inspect get_operation_schema for every selectable path.

get_idea_groups

buffer-cli get-idea-groups

Argument	Required	Type	Details
`organizationId`	No; body and guard rules apply	string	Unique identifier for the organization.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: organizationId. Use individual fields or complete payload/payload_file.

Default upstream fields: id, name, isLocked. Inspect get_operation_schema for every selectable path.

get_ideas

buffer-cli get-ideas

Argument	Required	Type	Details
`groupFilter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	No; body and guard rules apply	string	The organization to fetch ideas from.
`tagsFilter`	No; body and guard rules apply	object	See the full input schema.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`first`	No; body and guard rules apply	integer	Local page-size cap 100, default 25; provider may impose additional query limits. minimum: `1`. maximum: `100`.
`after`	No; body and guard rules apply	string	Opaque cursor from pageInfo.endCursor. One page per ordinary call. maxLength: `8192`.

Native input requirements: organizationId. Use individual fields or complete payload/payload_file.

Default upstream fields: items.id, items.content.aiAssisted, items.content.date, items.content.services, items.content.text, items.content.title, items.groupId, items.organizationId, items.position, items.createdAt, items.updatedAt, pageInfo.endCursor, pageInfo.hasNextPage, pageInfo.hasPreviousPage, pageInfo.startCursor. Inspect get_operation_schema for every selectable path.

get_instagram_audio

buffer-cli get-instagram-audio

Argument	Required	Type	Details
`audioId`	No; body and guard rules apply	string	Meta audio asset ID
`channelId`	No; body and guard rules apply	string	Instagram channel used to authorize the refresh
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: audioId, channelId. Use individual fields or complete payload/payload_file.

Default upstream fields: __typename, audio.id, audio.coverArtworkUrl, audio.creatorUsername, audio.displayArtist, audio.duration, audio.previewUrl, audio.title, audio.type, channelIds, message. Inspect get_operation_schema for every selectable path.

move_post_in_queue

buffer-cli move-post-in-queue

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	ID of the post to move.
`position`	No; body and guard rules apply	string	Target position within the channel's queue. Values: `bottom`, `top`.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id, position. Use individual fields or complete payload/payload_file.

Default upstream fields: __typename, post.id, post.allowedActions, post.assets.__typename, post.assets.id, post.assets.mimeType, post.assets.source, post.assets.thumbnail, post.assets.type, post.author.id, post.author.avatar, post.author.email, post.author.isDeleted, post.author.name, post.author.urn, post.channel.id, post.channel.allowedActions, post.channel.avatar, post.channel.descriptor, post.channel.displayName, post.channel.externalLink, post.channel.hasActiveMemberDevice, post.channel.isDisconnected, post.channel.isLocked, post.channel.isNew, post.channel.isQueuePaused, post.channel.metadata.__typename, post.channel.metadata.defaultToReminders, post.channel.metadata.maxCharacters, post.channel.metadata.serverUrl, post.channel.metadata.subscriptionType, post.channel.metadata.shouldShowLinkedinAnalyticsRefreshBanner, post.channel.metadata.businessPortfolioId, post.channel.metadata.lastSubscribedAt, post.channel.metadata.phoneNumberId, post.channel.metadata.wabaId, post.channel.name, post.channel.organizationId, post.channel.products, post.channel.scopes, post.channel.service, post.channel.serviceId, post.channel.showTrendingTopicSuggestions, post.channel.timezone, post.channel.type, post.channel.createdAt, post.channel.updatedAt, post.channelId, post.channelService, post.contentItemId, post.dueAt, post.error.message, post.error.rawError, post.error.supportUrl, post.externalLink, post.ideaId, post.isCustomScheduled, post.metadata.__typename, post.metadata.firstComment, post.metadata.isAiGenerated, post.metadata.link, post.metadata.shouldShareToFeed, post.metadata.type, post.metadata.title, post.metadata.threadCount, post.metadata.url, post.metadata.details.__typename, post.metadata.details.button, post.metadata.details.link, post.metadata.details.code, post.metadata.details.endDate, post.metadata.details.startDate, post.metadata.details.terms, post.metadata.details.title, post.metadata.details.endTime, post.metadata.details.isFullDayEvent, post.metadata.details.startTime, post.metadata.embeddable, post.metadata.license, post.metadata.madeForKids, post.metadata.notifySubscribers, post.metadata.privacy, post.metadata.spoilerText, post.metadata.locationId, post.metadata.locationName, post.metadata.topic, post.metrics.description, post.metrics.name, post.metrics.type, post.metrics.unit, post.metrics.value, post.metricsUpdatedAt, post.notes.id, post.notes.allowedActions, post.notes.text, post.notes.type, post.notes.createdAt, post.notes.updatedAt, post.notificationStatus, post.schedulingType, post.sentAt, post.sharedNow, post.shareMode, post.status, post.tags.id, post.tags.color, post.tags.colorName, post.tags.isLocked, post.tags.name, post.text, post.via, post.createdAt, post.updatedAt, message. Inspect get_operation_schema for every selectable path.

get_post

buffer-cli get-post

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The ID of the post to be retrieved
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: id. Use individual fields or complete payload/payload_file.

Default upstream fields: id, text, status, channel.name, channel.id, createdAt. Inspect get_operation_schema for every selectable path.

get_posts

buffer-cli get-posts

Argument	Required	Type	Details
`filter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	No; body and guard rules apply	string	The Organization id to fetch posts for
`sort`	No; body and guard rules apply	array	The sort to apply to the posts results Items: object.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`first`	No; body and guard rules apply	integer	Local page-size cap 100, default 25; provider may impose additional query limits. minimum: `1`. maximum: `100`.
`after`	No; body and guard rules apply	string	Opaque cursor from pageInfo.endCursor. One page per ordinary call. maxLength: `8192`.

Native input requirements: organizationId. Use individual fields or complete payload/payload_file.

Default upstream fields: items.id, items.text, items.status, pageInfo. Inspect get_operation_schema for every selectable path.

get_post_template

buffer-cli get-post-template

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The unique identifier of the template to fetch.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: id. Use individual fields or complete payload/payload_file.

Default upstream fields: id, body, description, emoji, organizationId, title, visibility, createdAt, updatedAt. Inspect get_operation_schema for every selectable path.

get_post_templates

buffer-cli get-post-templates

Argument	Required	Type	Details
`filter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	No; body and guard rules apply	string	Organization to scope `internal`-visibility templates to. The caller must be a member of this organization.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`first`	No; body and guard rules apply	integer	Local page-size cap 100, default 25; provider may impose additional query limits. minimum: `1`. maximum: `100`.
`after`	No; body and guard rules apply	string	Opaque cursor from pageInfo.endCursor. One page per ordinary call. maxLength: `8192`.

Native input requirements: organizationId. Use individual fields or complete payload/payload_file.

Default upstream fields: items.id, items.body, items.description, items.emoji, items.organizationId, items.title, items.visibility, items.createdAt, items.updatedAt, pageInfo.endCursor, pageInfo.hasNextPage, pageInfo.hasPreviousPage, pageInfo.startCursor. Inspect get_operation_schema for every selectable path.

promote_content_item_draft_to_posts

buffer-cli promote-content-item-draft-to-posts

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The content item to promote.
`posts`	No; body and guard rules apply	array	The channel-specific posts to create, one per channel. Provide at least one post, and at most one post per channel. Items: object.
`tagIds`	No; body and guard rules apply	array	Tags to apply to this content item. Omit to keep the current tags. An empty list or null removes them all. Items: string.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id, posts. Use individual fields or complete payload/payload_file.

remove_post_from_content_item

buffer-cli remove-post-from-content-item

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The content item to remove the post from.
`postId`	No; body and guard rules apply	string	The post to remove from a content item.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id, postId. Use individual fields or complete payload/payload_file.

get_search_instagram_audio

buffer-cli get-search-instagram-audio

Argument	Required	Type	Details
`audioType`	No; body and guard rules apply	string	Music or original sound catalog Values: `music`, `originalSound`.
`channelId`	No; body and guard rules apply	string	Instagram channel to search audio for
`query`	No; body and guard rules apply	string	Search text. Required. Use trendingInstagramAudio for trending results.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: audioType, channelId, query. Use individual fields or complete payload/payload_file.

get_tag

buffer-cli get-tag

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The unique identifier of the tag to fetch.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: id. Use individual fields or complete payload/payload_file.

Default upstream fields: id, color, colorName, isLocked, name. Inspect get_operation_schema for every selectable path.

get_tags_v2

buffer-cli get-tags-v2

Argument	Required	Type	Details
`filter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	No; body and guard rules apply	string	Organization to list tags for. The caller must be a member of this organization.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`first`	No; body and guard rules apply	integer	Local page-size cap 100, default 25; provider may impose additional query limits. minimum: `1`. maximum: `100`.
`after`	No; body and guard rules apply	string	Opaque cursor from pageInfo.endCursor. One page per ordinary call. maxLength: `8192`.

Native input requirements: organizationId. Use individual fields or complete payload/payload_file.

Default upstream fields: items.id, items.color, items.colorName, items.isLocked, items.name, pageInfo.endCursor, pageInfo.hasNextPage, pageInfo.hasPreviousPage, pageInfo.startCursor. Inspect get_operation_schema for every selectable path.

buffer-cli get-trending-instagram-audio

Argument	Required	Type	Details
`audioType`	No; body and guard rules apply	string	Music or original sound catalog Values: `music`, `originalSound`.
`channelId`	No; body and guard rules apply	string	Instagram channel to load trending audio for
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

Native input requirements: audioType, channelId. Use individual fields or complete payload/payload_file.

update_content_item

buffer-cli update-content-item

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The content item to update.
`targetDate`	No; body and guard rules apply	string	Omit to preserve the existing target date. Null clears it.
`title`	No; body and guard rules apply	string	Omit to preserve the existing title. Null clears it.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id. Use individual fields or complete payload/payload_file.

update_content_item_draft

buffer-cli update-content-item-draft

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The content item whose channel-less draft is replaced.
`draft`	No; body and guard rules apply	object	See the full input schema.
`tagIds`	No; body and guard rules apply	array	Tags to apply to this content item. Omit to keep the current tags. An empty list or null removes them all. Items: string.
`targetDate`	No; body and guard rules apply	string	Date indicating when this piece of content should go out. This is a planning aid only and does not schedule any posts. Omit to preserve the existing target date. Null clears it.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id, draft. Use individual fields or complete payload/payload_file.

update_post_template

buffer-cli update-post-template

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The ID of the template to update.
`body`	No; body and guard rules apply	string	The main content body of the template, may contain {{placeholders}}.
`description`	No; body and guard rules apply	string	A short user-facing description of the template.
`emoji`	No; body and guard rules apply	string	The emoji associated with the template.
`title`	No; body and guard rules apply	string	The title of the template.
`visibility`	No; body and guard rules apply	string	`public` is rejected — it is only available to official Buffer clients. Values: `internal`, `private`, `public`.
`payload`	No; body and guard rules apply	object	Complete native input object instead of individual input fields.
`payload_file`	No; body and guard rules apply	string	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields. minLength: `1`.
`fields`	No; body and guard rules apply	array	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. minItems: `1`. maxItems: `100`. Items: string.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

Native input requirements: id. Use individual fields or complete payload/payload_file.

list_accounts

buffer-cli list-accounts

Argument	Required	Type	Details
None	No	None	No arguments

graphql_query

buffer-cli graphql-query

Argument	Required	Type	Details
`document`	Yes	string	See the full input schema. minLength: `1`. maxLength: `65536`.
`variables`	No; body and guard rules apply	object	Native JSON variables; validated remotely by Buffer.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.

graphql_mutation

buffer-cli graphql-mutation

Argument	Required	Type	Details
`document`	Yes	string	See the full input schema. minLength: `1`. maxLength: `65536`.
`variables`	No; body and guard rules apply	object	Native JSON variables; validated remotely by Buffer.
`account`	No; body and guard rules apply	string	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions. minLength: `1`.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact user-requested Buffer mutation.

preview_operation

buffer-cli preview-operation

Argument	Required	Type	Details
`operation`	Yes	string	See the full input schema. Values: `account`, `addPostToContentItem`, `aggregatedPostMetrics`, `channel`, `channels`, `configuration`, `contentItem`, `contentItems`, `createContentItem`, `createContentItemDraft`, `createIdea`, `createPost`, `createPostTemplate`, `dailyPostingLimits`, `deleteContentItem`, `deletePost`, `deletePostTemplate`, `editPost`, `ideaGroups`, `ideas`, `instagramAudio`, `movePostInQueue`, `post`, `posts`, `postTemplate`, `postTemplates`, `promoteContentItemDraftToPosts`, `removePostFromContentItem`, `searchInstagramAudio`, `tag`, `tagsV2`, `trendingInstagramAudio`, `updateContentItem`, `updateContentItemDraft`, `updatePostTemplate`.
`arguments`	Yes	object	Arguments for that named tool. Provide all required native input, including organizationId; profile defaults are not read.

query_pages

buffer-cli query-pages

Argument	Required	Type	Details
`operation`	Yes	string	See the full input schema. Values: `contentItems`, `ideas`, `posts`, `postTemplates`, `tagsV2`.
`arguments`	Yes	object	Arguments for the native read tool, including filters, fields, first/after and account.
`max_pages`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `5`. default: `1`.

get_operation_schema

buffer-cli get-operation-schema

Argument	Required	Type	Details
`operation`	Yes	string	See the full input schema. Values: `account`, `addPostToContentItem`, `aggregatedPostMetrics`, `channel`, `channels`, `configuration`, `contentItem`, `contentItems`, `createContentItem`, `createContentItemDraft`, `createIdea`, `createPost`, `createPostTemplate`, `dailyPostingLimits`, `deleteContentItem`, `deletePost`, `deletePostTemplate`, `editPost`, `ideaGroups`, `ideas`, `instagramAudio`, `movePostInQueue`, `post`, `posts`, `postTemplate`, `postTemplates`, `promoteContentItemDraftToPosts`, `removePostFromContentItem`, `searchInstagramAudio`, `tag`, `tagsV2`, `trendingInstagramAudio`, `updateContentItem`, `updateContentItemDraft`, `updatePostTemplate`.

Nested native input definitions

These tables preserve the current nested object/array structures, required fields, enums and constraints. Repeated identical shapes are shown once; full inline schema remains available for each command.

addPostToContentItem.input

Argument	Required	Type	Details
`id`	Yes	string	The content item to add the post to.
`postId`	Yes	string	The post to add. The post must already exist. The post and the content item must belong to the same organization.

aggregatedPostMetrics.input

Argument	Required	Type	Details
`channelIds`	No; body and guard rules apply	array	Optional list of channel IDs to filter by. When omitted (null), the aggregate spans every channel in the organization the actor has insights access to. When set to an empty array, no channels match and the result is empty. Items: string.
`endDateTime`	Yes	string	End of the aggregation window. Consumers typically pass UTC midnight of the last calendar day in the window (the backend treats the range as inclusive of that day), for example `2026-01-31T00:00:00Z`. Date range is capped to 365 days.
`organizationId`	Yes	string	The organization ID
`startDateTime`	Yes	string	Start of the aggregation window. Consumers typically pass UTC midnight of the first calendar day in the window, for example `2026-01-01T00:00:00Z`.
`tags`	No; body and guard rules apply	object	See the full input schema.

aggregatedPostMetrics.input.tags

Argument	Required	Type	Details
`in`	Yes	array	Include results that have any of the specified tags (union/OR). Items: string.
`isEmpty`	No; body and guard rules apply	boolean	When true, include results that have no tags assigned. Can be combined with 'in' for union filtering. Defaults to false if not specified.

channel.input

Argument	Required	Type	Details
`id`	Yes	string	The ID of the channel to be retrieved

channels.input

Argument	Required	Type	Details
`filter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	Yes	string	The Organization id to fetch channels for

channels.input.filter

Argument	Required	Type	Details
`isLocked`	No; body and guard rules apply	boolean	If not defined, it returns all channels Else, if true, it only returns locked channels if false, it only returns not locked channels
`product`	No; body and guard rules apply	string	If not passed, it return all channels Else, it filters the channels based on what the product supports. Values: `analyze`, `buffer`, `comments`, `engage`, `publish`, `startPage`.

configuration.input

Argument	Required	Type	Details
`organizationId`	Yes	string	The organization to return configuration for.

contentItem.input

Argument	Required	Type	Details
`id`	Yes	string	The unique identifier of the content item to fetch.

contentItems.input

Argument	Required	Type	Details
`filter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	Yes	string	Organization to list content items for. The caller must be a member of this organization.
`sort`	No; body and guard rules apply	array	Sorting to apply, each entry breaking ties in the one before it. Defaults to newest first. A pagination cursor is only valid for the sort that produced it, so reset `after` to null whenever the sort changes. Items: object.

contentItems.input.filter

Argument	Required	Type	Details
`contentStatus`	No; body and guard rules apply	string	Only return content items with this content status. When omitted, content items in every status are returned. Values: `draftContent`, `postContent`.
`tags`	No; body and guard rules apply	object	See the full input schema.
`targetDate`	No; body and guard rules apply	object	See the full input schema.

contentItems.input.filter.targetDate

Argument	Required	Type	Details
`presence`	No; body and guard rules apply	string	Only return content items by whether a target date is set: `present` returns only dated items, `absent` only undated ones. Values: `absent`, `present`.
`range`	No; body and guard rules apply	object	See the full input schema.

contentItems.input.filter.targetDate.range

Argument	Required	Type	Details
`end`	No; body and guard rules apply	string	Include results with dates equal to or before the specified date
`start`	No; body and guard rules apply	string	Include results with dates equal to or after the specified date

contentItems.input.sort[]

Argument	Required	Type	Details
`direction`	Yes	string	The direction to sort by. Values: `asc`, `desc`.
`field`	Yes	string	The field to sort by. Values: `targetDate`, `createdAt`.

createContentItem.input

Argument	Required	Type	Details
`organizationId`	Yes	string	Organization that owns the content item and all variants created in it.
`posts`	Yes	array	The channel-specific post variants to create, one per channel. Provide at least one variant, and at most one variant per channel. Items: object.
`tagIds`	No; body and guard rules apply	array	Tags to apply to this content item. Omit to create it with no tags. Items: string.
`targetDate`	No; body and guard rules apply	string	Optional date indicating when this piece of content should go out. This is a planning aid only and does not schedule any posts.
`title`	No; body and guard rules apply	string	Optional title describing what this piece of content is about.

createContentItem.input.posts[]

Argument	Required	Type	Details
`aiAssisted`	No; body and guard rules apply	boolean	If this post was created with the help of AI
`assets`	No; body and guard rules apply	array	Ordered list of assets on this post. Items: object.
`channelId`	Yes	string	Channel's Id for which we want to create the post
`draftId`	No; body and guard rules apply	string	Is set when the Post is generated from a Draft
`dueAt`	No; body and guard rules apply	string	Date when the post is scheduled to be published
`ideaId`	No; body and guard rules apply	string	Is set when the Post is generated from an Idea
`metadata`	No; body and guard rules apply	object	See the full input schema.
`mode`	Yes	string	How the post is being scheduled. Values: `addToQueue`, `customScheduled`, `shareNext`, `shareNow`.
`needsApproval`	No; body and guard rules apply	boolean	Submit the post for approval instead of scheduling it. A post submitted for approval is always a draft, so this conflicts with turning `saveToDraft` off. Only valid when your posting policy on the target channel requires approval.
`saveToDraft`	No; body and guard rules apply	boolean	If true, saves the post as a draft instead of scheduling it. When saving as draft: - Post status will be 'draft' instead of 'buffer' - Posting limits are not checked - The post will not be published until explicitly scheduled
`schedulingType`	Yes	string	Scheduling type to indicate notification publishing or automatic publishing Values: `automatic`, `notification`.
`source`	No; body and guard rules apply	string	source where the composer was initiated from, used for tracking.
`tagIds`	No; body and guard rules apply	array	List of tag IDs Items: string.
`text`	No; body and guard rules apply	string	Text content of the Post. Note: for threaded posts, this needs to match the first item in the `thread` array.

createContentItem.input.posts[].assets[]

Argument	Required	Type	Details
`document`	No; body and guard rules apply	object	See the full input schema.
`image`	No; body and guard rules apply	object	See the full input schema.
`link`	No; body and guard rules apply	object	See the full input schema.
`video`	No; body and guard rules apply	object	See the full input schema.

createContentItem.input.posts[].assets[].document

Argument	Required	Type	Details
`thumbnailUrl`	Yes	string	Document thumbnail URL
`title`	Yes	string	Document title
`url`	Yes	string	Document URL

createContentItem.input.posts[].assets[].image

Argument	Required	Type	Details
`metadata`	No; body and guard rules apply	object	See the full input schema.
`thumbnailUrl`	No; body and guard rules apply	string	URL to the static thumbnail of the asset
`url`	Yes	string	URL to the file source

createContentItem.input.posts[].assets[].image.metadata

Argument	Required	Type	Details
`altText`	Yes	string	Alternative text for accessibility
`animatedThumbnail`	No; body and guard rules apply	string	Animated thumbnail URL
`dimensions`	No; body and guard rules apply	object	See the full input schema.
`userTags`	No; body and guard rules apply	array	Accounts to tag at specific points on the image. Each tag's x/y position uses normalized 0.0-1.0 coordinates - see UserTagInput. Items: object.

createContentItem.input.posts[].assets[].image.metadata.dimensions

Argument	Required	Type	Details
`height`	Yes	integer	Image height in pixels
`width`	Yes	integer	Image width in pixels

createContentItem.input.posts[].assets[].image.metadata.userTags[]

Argument	Required	Type	Details
`handle`	Yes	string	The handle (username) of the account to tag, without the leading @.
`x`	Yes	number	Horizontal position of the tag as a normalized decimal float between 0.0 and 1.0 - the fraction of the image width from the left edge (0.5 is the horizontal center). Pass a number, not a string, and do not use pixel coordinates; to convert, divide the pixel X by the image width.
`y`	Yes	number	Vertical position of the tag as a normalized decimal float between 0.0 and 1.0 - the fraction of the image height from the top edge (0.5 is the vertical center). Pass a number, not a string, and do not use pixel coordinates; to convert, divide the pixel Y by the image height.

createContentItem.input.posts[].assets[].link

Argument	Required	Type	Details
`description`	No; body and guard rules apply	string	Description of the link
`thumbnailUrl`	No; body and guard rules apply	string	Thumbnail URL of the link
`title`	No; body and guard rules apply	string	Title of the link
`url`	Yes	string	URL to the link

createContentItem.input.posts[].assets[].video

Argument	Required	Type	Details
`metadata`	No; body and guard rules apply	object	See the full input schema.
`thumbnailUrl`	No; body and guard rules apply	string	Do not use: social networks do not accept custom video thumbnail images, and the API rejects video assets that set this field. To choose the video thumbnail, set `metadata.thumbnailOffset` to select a frame from the video (supported for Instagram, TikTok, and Pinterest only).
`url`	Yes	string	URL to the file source

createContentItem.input.posts[].assets[].video.metadata

Argument	Required	Type	Details
`thumbnailOffset`	No; body and guard rules apply	integer	Offset of the thumbnail chosen for the video, in ms
`title`	No; body and guard rules apply	string	Video title

createContentItem.input.posts[].metadata

Argument	Required	Type	Details
`bluesky`	No; body and guard rules apply	object	See the full input schema.
`facebook`	No; body and guard rules apply	object	See the full input schema.
`google`	No; body and guard rules apply	object	See the full input schema.
`instagram`	No; body and guard rules apply	object	See the full input schema.
`linkedin`	No; body and guard rules apply	object	See the full input schema.
`mastodon`	No; body and guard rules apply	object	See the full input schema.
`pinterest`	No; body and guard rules apply	object	See the full input schema.
`substack`	No; body and guard rules apply	object	See the full input schema.
`threads`	No; body and guard rules apply	object	See the full input schema.
`tiktok`	No; body and guard rules apply	object	See the full input schema.
`twitter`	No; body and guard rules apply	object	See the full input schema.
`youtube`	No; body and guard rules apply	object	See the full input schema.

createContentItem.input.posts[].metadata.bluesky

Argument	Required	Type	Details
`linkAttachment`	No; body and guard rules apply	object	See the full input schema.
`thread`	No; body and guard rules apply	array	The ordered list of posts that make up the thread (not paginated). This array is the source of truth for what gets published: every post in the thread, including the root post, must be provided here. Posts are published in order, each replying to the previous one. The first item is the root post and should match the top-level `text` on the post input. Items: object.

createContentItem.input.posts[].metadata.bluesky.linkAttachment

Argument	Required	Type	Details
`description`	No; body and guard rules apply	string	Description shown on the link card
`thumbnail`	No; body and guard rules apply	object	See the full input schema.
`title`	No; body and guard rules apply	string	Title shown on the link card
`url`	Yes	string	URL that the link asset has been built from

createContentItem.input.posts[].metadata.bluesky.linkAttachment.thumbnail

Argument	Required	Type	Details
`url`	Yes	string	URL of the thumbnail image

createContentItem.input.posts[].metadata.bluesky.thread[]

Argument	Required	Type	Details
`assets`	No; body and guard rules apply	array	Ordered list of assets on this threaded post Items: object.
`metadata`	No; body and guard rules apply	object	See the full input schema.
`text`	No; body and guard rules apply	string	The text body content of the threaded post

createContentItem.input.posts[].metadata.facebook

Argument	Required	Type	Details
`annotations`	No; body and guard rules apply	array	Annotations representing entities in the text Items: object.
`firstComment`	No; body and guard rules apply	string	Facebook post's first comment
`linkAttachment`	No; body and guard rules apply	object	See the full input schema.
`type`	Yes	string	The channel-specific type of the post, eg, post, story, reel for Facebook Values: `post`, `reel`, `story`.

createContentItem.input.posts[].metadata.facebook.annotations[]

Argument	Required	Type	Details
`content`	Yes	string	The content of the annotation, e.g. '107509875938399'
`indices`	Yes	array	The indices of the annotation in the text, e.g. [6, 9] (from 6 to 9 characters in the text) Items: integer.
`text`	Yes	string	The text representation of the annotation, eg 'Buffer'
`url`	Yes	string	The URL the annotation points to, e.g. https://www.facebook.com/107509875938399

createContentItem.input.posts[].metadata.google

Argument	Required	Type	Details
`detailsEvent`	No; body and guard rules apply	object	See the full input schema.
`detailsOffer`	No; body and guard rules apply	object	See the full input schema.
`detailsWhatsNew`	No; body and guard rules apply	object	See the full input schema.
`title`	No; body and guard rules apply	string	Title if available in the given GBP post type: event and offer
`type`	Yes	string	The channel-specific type of the post, eg, post, offer, event for Google Business Profile Values: `event`, `offer`, `whats_new`.

createContentItem.input.posts[].metadata.google.detailsEvent

Argument	Required	Type	Details
`button`	No; body and guard rules apply	string	Action button. Optional: a post with no button, or `none`, publishes without a call-to-action. On edit, omitting it preserves the existing value. Values: `book`, `call`, `learn_more`, `none`, `order`, `shop`, `signup`.
`endDate`	No; body and guard rules apply	string	End date of the event. Required on create; optional on edit (omitted preserves existing value).
`isFullDayEvent`	Yes	boolean	Indicate whether the event has a start or end time.
`link`	No; body and guard rules apply	string	Link to the action
`startDate`	No; body and guard rules apply	string	Start date of the event. Required on create; optional on edit (omitted preserves existing value).
`title`	No; body and guard rules apply	string	Title of the event. Required on create; optional on edit (omitted preserves existing value).

createContentItem.input.posts[].metadata.google.detailsOffer

Argument	Required	Type	Details
`code`	No; body and guard rules apply	string	Coupon code for the offer
`endDate`	No; body and guard rules apply	string	End date of the offer. Required on create; optional on edit (omitted preserves existing value).
`link`	No; body and guard rules apply	string	Link to the offer
`startDate`	No; body and guard rules apply	string	Start date of the offer. Required on create; optional on edit (omitted preserves existing value).
`terms`	No; body and guard rules apply	string	Terms and Conditions
`title`	No; body and guard rules apply	string	Title of the offer. Required on create; optional on edit (omitted preserves existing value).

createContentItem.input.posts[].metadata.google.detailsWhatsNew

Argument	Required	Type	Details
`button`	No; body and guard rules apply	string	Action button. Optional: a post with no button, or `none`, publishes without a call-to-action. On edit, omitting it preserves the existing value. Values: `book`, `call`, `learn_more`, `none`, `order`, `shop`, `signup`.
`link`	No; body and guard rules apply	string	Link to the action

createContentItem.input.posts[].metadata.instagram

Argument	Required	Type	Details
`firstComment`	No; body and guard rules apply	string	Instagram post's first comment
`geolocation`	No; body and guard rules apply	object	See the full input schema.
`isAiGenerated`	No; body and guard rules apply	boolean	Whether the post discloses AI-generated content
`link`	No; body and guard rules apply	string	Shop Grid link for the post
`shouldShareToFeed`	Yes	boolean	Indicates whether post should be shared to feed
`stickerFields`	No; body and guard rules apply	object	See the full input schema.
`type`	Yes	string	The channel-specific type of the post, eg, post, story, reel for Instagram Values: `carousel`, `event`, `ghost_post`, `offer`, `post`, `reel`, `short`, `story`, `thread`, `whats_new`.

createContentItem.input.posts[].metadata.instagram.geolocation

Argument	Required	Type	Details
`id`	No; body and guard rules apply	string	The id of this location
`text`	No; body and guard rules apply	string	The name of this location

createContentItem.input.posts[].metadata.instagram.stickerFields

Argument	Required	Type	Details
`music`	No; body and guard rules apply	string	Placeholder text for the post's music
`other`	No; body and guard rules apply	string	Additional field for any other post content
`products`	No; body and guard rules apply	string	Placeholder text for the post's linked products
`text`	No; body and guard rules apply	string	Text for the Story or Reel
`topics`	No; body and guard rules apply	string	Placeholder text for the post's topics (Reels only)

createContentItem.input.posts[].metadata.linkedin

Argument	Required	Type	Details
`annotations`	No; body and guard rules apply	array	Annotations representing entities in the text Items: object.
`firstComment`	No; body and guard rules apply	string	LinkedIn post's first comment
`linkAttachment`	No; body and guard rules apply	object	See the full input schema.

createContentItem.input.posts[].metadata.linkedin.annotations[]

Argument	Required	Type	Details
`id`	Yes	string	The id of the annotation, e.g. 1521226
`entity`	Yes	string	The entity of the annotation, e.g. urn:li:organization:1521226
`length`	Yes	integer	The length of the annotation, e.g. 6
`link`	Yes	string	The link of the annotation, e.g. https://www.linkedin.com/company/bufferapp
`localizedName`	Yes	string	The localized name of the annotation, e.g. Buffer
`start`	Yes	integer	The start of the annotation, e.g. 5
`vanityName`	Yes	string	The vanity name of the annotation, e.g. bufferapp

createContentItem.input.posts[].metadata.mastodon

Argument	Required	Type	Details
`spoilerText`	No; body and guard rules apply	string	Spoiler text hiding the root text of this post
`thread`	No; body and guard rules apply	array	The ordered list of posts that make up the thread (not paginated). This array is the source of truth for what gets published: every post in the thread, including the root post, must be provided here. Posts are published in order, each replying to the previous one. The first item is the root post and should match the top-level `text` on the post input. Items: object.

createContentItem.input.posts[].metadata.pinterest

Argument	Required	Type	Details
`boardServiceId`	No; body and guard rules apply	string	The board ID of the Pin, can be obtained when fetching the channel details with the following query: `query GetChannelWithSubprofiles { channel(input: { id: "[CHANNEL_ID_HERE]" }) { metadata { ... on PinterestMetadata { boards { serviceId } } } } }` Required on create; optional on edit (omitted preserves existing board).
`title`	No; body and guard rules apply	string	The title of the Pin
`url`	No; body and guard rules apply	string	The Pin destination link

createContentItem.input.posts[].metadata.substack

Argument	Required	Type	Details
`linkAttachment`	No; body and guard rules apply	object	See the full input schema.

createContentItem.input.posts[].metadata.threads

Argument	Required	Type	Details
`linkAttachment`	No; body and guard rules apply	object	See the full input schema.
`locationId`	No; body and guard rules apply	string	LocationId associated with the post
`locationName`	No; body and guard rules apply	string	Location name associated with the post
`thread`	No; body and guard rules apply	array	The ordered list of posts that make up the thread (not paginated). This array is the source of truth for what gets published: every post in the thread, including the root post, must be provided here. Posts are published in order, each replying to the previous one. The first item is the root post and should match the top-level `text` on the post input. Items: object.
`topic`	No; body and guard rules apply	string	Topic associated with the post
`type`	No; body and guard rules apply	string	The type of the post Values: `carousel`, `event`, `ghost_post`, `offer`, `post`, `reel`, `short`, `story`, `thread`, `whats_new`.

createContentItem.input.posts[].metadata.tiktok

Argument	Required	Type	Details
`isAiGenerated`	No; body and guard rules apply	boolean	Whether the post discloses AI-generated content (TikTok video only)
`title`	No; body and guard rules apply	string	The title of the TikTok post (for photo posts)

createContentItem.input.posts[].metadata.twitter

Argument	Required	Type	Details
`isAiGenerated`	No; body and guard rules apply	boolean	Whether the post discloses AI-generated content (original tweets only, never retweets)
`retweet`	No; body and guard rules apply	object	See the full input schema.
`thread`	No; body and guard rules apply	array	The ordered list of posts that make up the thread (not paginated). This array is the source of truth for what gets published: every post in the thread, including the root post, must be provided here. Posts are published in order, each replying to the previous one. The first item is the root post and should match the top-level `text` on the post input. Items: object.

createContentItem.input.posts[].metadata.twitter.retweet

Argument	Required	Type	Details
`id`	Yes	string	Retweet ID
`comment`	No; body and guard rules apply	string	Optional user comment shown above the embedded retweet

createContentItem.input.posts[].metadata.youtube

Argument	Required	Type	Details
`categoryId`	No; body and guard rules apply	string	Youtube Category ID, one ID of this list: ID: 1 -> Film & Animation ID: 2 -> Autos & Vehicles ID: 10 -> Music ID: 15 -> Pets & Animals ID: 17 -> Sports ID: 19 -> Travel & Events ID: 20 -> Gaming ID: 22 -> People & Blogs ID: 23 -> Comedy ID: 24 -> Entertainment ID: 25 -> News & Politics ID: 26 -> Howto & Style ID: 27 -> Education ID: 28 -> Science & Technology ID: 29 -> Nonprofits & Activism Required on create; optional on edit (omitted preserves existing value).
`embeddable`	No; body and guard rules apply	boolean	Indicates whether the video allows embedding (default: true)
`isAiGenerated`	No; body and guard rules apply	boolean	Whether the post discloses AI-generated content
`license`	No; body and guard rules apply	string	Video license (default: youtube) Values: `creativeCommon`, `youtube`.
`madeForKids`	No; body and guard rules apply	boolean	Indicates whether the video is suitable for kids (default: false)
`notifySubscribers`	No; body and guard rules apply	boolean	Indicates whether to notify subscribers on publish video (default: true)
`privacy`	No; body and guard rules apply	string	Privacy setting for post (default: public) Values: `private`, `public`, `unlisted`.
`title`	No; body and guard rules apply	string	Title of the Youtube post. Required on create; optional on edit (omitted preserves existing value).

createContentItemDraft.input

Argument	Required	Type	Details
`correlationId`	No; body and guard rules apply	string	Client-generated UUID that makes draft creation idempotent. A retry with the same UUID in the same organization returns the first content item in its current state.
`draft`	Yes	object	See the full input schema.
`organizationId`	Yes	string	Organization that will own the content item.
`tagIds`	No; body and guard rules apply	array	Tags to apply to this content item. Omit to create it with no tags. Items: string.
`targetDate`	No; body and guard rules apply	string	Optional date indicating when this piece of content should go out. This is a planning aid only and does not schedule any posts.
`title`	No; body and guard rules apply	string	Optional title describing what this piece of content is about.

createContentItemDraft.input.draft

Argument	Required	Type	Details
`aiAssisted`	No; body and guard rules apply	boolean	Set to true when the draft content was written with the help of AI.
`assets`	No; body and guard rules apply	array	Images, videos, or documents to attach to the draft, in display order. Items: object.
`text`	Yes	string	The written content of the draft. Can be empty when the draft holds at least one asset.

createIdea.input

Argument	Required	Type	Details
`content`	Yes	object	See the full input schema.
`cta`	No; body and guard rules apply	string	Call-to-action identifier for analytics tracking
`group`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	Yes	string	Organization ID that will own the idea
`templateId`	No; body and guard rules apply	string	Template ID used to create the idea

createIdea.input.content

Argument	Required	Type	Details
`aiAssisted`	No; body and guard rules apply	boolean	Whether AI tools were used in creation
`date`	No; body and guard rules apply	string	Target date for the idea, often used for planning publish schedules
`media`	No; body and guard rules apply	array	List of media items to attach Items: object.
`services`	No; body and guard rules apply	array	Services associated with the idea for targeting specific platforms Items: string.
`tags`	No; body and guard rules apply	array	Tags to categorize the idea Items: object.
`text`	No; body and guard rules apply	string	Main body text or description
`title`	No; body and guard rules apply	string	Title or headline of the idea

createIdea.input.content.media[]

Argument	Required	Type	Details
`url`	Yes	string	The URL of the media
`alt`	No; body and guard rules apply	string	Alternative text for the media
`thumbnailUrl`	No; body and guard rules apply	string	Thumbnail URL for the media
`type`	Yes	string	The type of media (image, gif, video, link, document, unsupported). Note: 'video' is not supported via public API Values: `image`, `gif`, `video`, `link`, `document`, `unsupported`.
`size`	No; body and guard rules apply	integer	The size of the media in bytes
`source`	No; body and guard rules apply	object	See the full input schema.

createIdea.input.content.media[].source

Argument	Required	Type	Details
`name`	Yes	string	See the full input schema.
`id`	No; body and guard rules apply	string	See the full input schema.
`trigger`	No; body and guard rules apply	string	See the full input schema.
`author`	No; body and guard rules apply	string	for unsplash only
`authorUrl`	No; body and guard rules apply	string	See the full input schema.

createIdea.input.content.tags[]

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`name`	Yes	string	See the full input schema.
`color`	Yes	string	See the full input schema.

createIdea.input.group

Argument	Required	Type	Details
`groupId`	No; body and guard rules apply	string	Target group ID (null for unassigned group)
`placeAfterId`	No; body and guard rules apply	string	ID of idea to place after (null for top position)

createPost.input

Argument	Required	Type	Details
`aiAssisted`	No; body and guard rules apply	boolean	If this post was created with the help of AI
`assets`	No; body and guard rules apply	array	Ordered list of assets on this post. Items: object.
`channelId`	Yes	string	Channel's Id for which we want to create the post
`draftId`	No; body and guard rules apply	string	Is set when the Post is generated from a Draft
`dueAt`	No; body and guard rules apply	string	Date when the post is scheduled to be published
`ideaId`	No; body and guard rules apply	string	Is set when the Post is generated from an Idea
`metadata`	No; body and guard rules apply	object	See the full input schema.
`mode`	Yes	string	How the post is being scheduled. Values: `addToQueue`, `customScheduled`, `shareNext`, `shareNow`.
`needsApproval`	No; body and guard rules apply	boolean	Submit the post for approval instead of scheduling it. A post submitted for approval is always a draft, so this conflicts with turning `saveToDraft` off. Only valid when your posting policy on the target channel requires approval.
`saveToDraft`	No; body and guard rules apply	boolean	If true, saves the post as a draft instead of scheduling it. When saving as draft: - Post status will be 'draft' instead of 'buffer' - Posting limits are not checked - The post will not be published until explicitly scheduled
`schedulingType`	Yes	string	Scheduling type to indicate notification publishing or automatic publishing Values: `automatic`, `notification`.
`source`	No; body and guard rules apply	string	source where the composer was initiated from, used for tracking.
`tagIds`	No; body and guard rules apply	array	List of tag IDs Items: string.
`text`	No; body and guard rules apply	string	Text content of the Post. Note: for threaded posts, this needs to match the first item in the `thread` array.

createPost.input.metadata

Argument	Required	Type	Details
`bluesky`	No; body and guard rules apply	object	See the full input schema.
`facebook`	No; body and guard rules apply	object	See the full input schema.
`google`	No; body and guard rules apply	object	See the full input schema.
`instagram`	No; body and guard rules apply	object	See the full input schema.
`linkedin`	No; body and guard rules apply	object	See the full input schema.
`mastodon`	No; body and guard rules apply	object	See the full input schema.
`pinterest`	No; body and guard rules apply	object	See the full input schema.
`substack`	No; body and guard rules apply	object	See the full input schema.
`threads`	No; body and guard rules apply	object	See the full input schema.
`tiktok`	No; body and guard rules apply	object	See the full input schema.
`twitter`	No; body and guard rules apply	object	See the full input schema.
`youtube`	No; body and guard rules apply	object	See the full input schema.

createPost.input.metadata.bluesky

Argument	Required	Type	Details
`linkAttachment`	No; body and guard rules apply	object	See the full input schema.
`thread`	No; body and guard rules apply	array	The ordered list of posts that make up the thread (not paginated). This array is the source of truth for what gets published: every post in the thread, including the root post, must be provided here. Posts are published in order, each replying to the previous one. The first item is the root post and should match the top-level `text` on the post input. Items: object.

createPost.input.metadata.bluesky.thread[]

Argument	Required	Type	Details
`assets`	No; body and guard rules apply	array	Ordered list of assets on this threaded post Items: object.
`metadata`	No; body and guard rules apply	object	See the full input schema.
`text`	No; body and guard rules apply	string	The text body content of the threaded post

createPost.input.metadata.bluesky.thread[].assets[]

Argument	Required	Type	Details
`document`	No; body and guard rules apply	object	See the full input schema.
`image`	No; body and guard rules apply	object	See the full input schema.
`link`	No; body and guard rules apply	object	See the full input schema.
`video`	No; body and guard rules apply	object	See the full input schema.

createPost.input.metadata.bluesky.thread[].assets[].image

Argument	Required	Type	Details
`thumbnailUrl`	No; body and guard rules apply	string	URL to the static thumbnail of the asset
`url`	Yes	string	URL to the file source

createPost.input.metadata.bluesky.thread[].assets[].video

Argument	Required	Type	Details
`thumbnailUrl`	No; body and guard rules apply	string	Do not use: social networks do not accept custom video thumbnail images, and the API rejects video assets that set this field. To choose the video thumbnail, set `metadata.thumbnailOffset` to select a frame from the video (supported for Instagram, TikTok, and Pinterest only).
`url`	Yes	string	URL to the file source

createPost.input.metadata.bluesky.thread[].metadata

Argument	Required	Type	Details
`bluesky`	No; body and guard rules apply	object	See the full input schema.
`threads`	No; body and guard rules apply	object	See the full input schema.

createPost.input.metadata.mastodon

Argument	Required	Type	Details
`spoilerText`	No; body and guard rules apply	string	Spoiler text hiding the root text of this post
`thread`	No; body and guard rules apply	array	The ordered list of posts that make up the thread (not paginated). This array is the source of truth for what gets published: every post in the thread, including the root post, must be provided here. Posts are published in order, each replying to the previous one. The first item is the root post and should match the top-level `text` on the post input. Items: object.

createPost.input.metadata.threads

Argument	Required	Type	Details
`linkAttachment`	No; body and guard rules apply	object	See the full input schema.
`locationId`	No; body and guard rules apply	string	LocationId associated with the post
`locationName`	No; body and guard rules apply	string	Location name associated with the post
`thread`	No; body and guard rules apply	array	The ordered list of posts that make up the thread (not paginated). This array is the source of truth for what gets published: every post in the thread, including the root post, must be provided here. Posts are published in order, each replying to the previous one. The first item is the root post and should match the top-level `text` on the post input. Items: object.
`topic`	No; body and guard rules apply	string	Topic associated with the post
`type`	No; body and guard rules apply	string	The type of the post Values: `carousel`, `event`, `ghost_post`, `offer`, `post`, `reel`, `short`, `story`, `thread`, `whats_new`.

createPost.input.metadata.twitter

Argument	Required	Type	Details
`isAiGenerated`	No; body and guard rules apply	boolean	Whether the post discloses AI-generated content (original tweets only, never retweets)
`retweet`	No; body and guard rules apply	object	See the full input schema.
`thread`	No; body and guard rules apply	array	The ordered list of posts that make up the thread (not paginated). This array is the source of truth for what gets published: every post in the thread, including the root post, must be provided here. Posts are published in order, each replying to the previous one. The first item is the root post and should match the top-level `text` on the post input. Items: object.

createPostTemplate.input

Argument	Required	Type	Details
`body`	Yes	string	The main content body of the template, may contain {{placeholders}}.
`description`	No; body and guard rules apply	string	A 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.
`emoji`	No; body and guard rules apply	string	The emoji associated with the template.
`organizationId`	Yes	string	Organization 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.
`title`	Yes	string	The title of the template.
`visibility`	No; body and guard rules apply	string	Defaults to `private` if omitted. `public` is rejected — it is only available to official Buffer clients. Values: `internal`, `private`, `public`.

dailyPostingLimits.input

Argument	Required	Type	Details
`channelIds`	Yes	array	List of channel IDs to check limits for. All channels must belong to the same organization. Items: string.
`date`	No; body and guard rules apply	string	The date to check limits for. Defaults to today if not provided.

deleteContentItem.input

Argument	Required	Type	Details
`id`	Yes	string	The content item to delete.

deletePost.input

Argument	Required	Type	Details
`id`	Yes	string	Post id to delete.

deletePostTemplate.input

Argument	Required	Type	Details
`id`	Yes	string	The ID of the template to delete.

editPost.input

Argument	Required	Type	Details
`id`	Yes	string	ID of the post to edit
`aiAssisted`	No; body and guard rules apply	boolean	If this post was edited with the help of AI
`approvalChange`	No; body and guard rules apply	string	Change the post's approval state alongside this edit. Leave unset to keep the post's current approval state. Only valid when your posting policy on the post's channel requires approval, and only on your own drafts. Asking for the state the post is already in does nothing. Values: `request`, `revert`.
`assets`	No; body and guard rules apply	array	Ordered list of assets on this post. Omit to preserve the existing list, pass an empty array to clear it Items: object.
`draftId`	No; body and guard rules apply	string	Is set when the Post is generated from a Draft
`dueAt`	No; body and guard rules apply	string	Date when the post is scheduled to be published
`ideaId`	No; body and guard rules apply	string	Is set when the Post is generated from an Idea
`metadata`	No; body and guard rules apply	object	See the full input schema.
`mode`	No; body and guard rules apply	string	How the post is being scheduled. Omit the field or pass null to make no scheduling change — null does not clear or reset the schedule: a scheduled post keeps its current share mode, queue slot, and any custom time, and the edit applies only the other provided fields. Pass a non-null ShareMode to apply that mode. Values: `addToQueue`, `customScheduled`, `shareNext`, `shareNow`.
`saveToDraft`	No; body and guard rules apply	boolean	If true, saves the post as a draft instead of keeping it scheduled. When saving as draft: - Post status will be 'draft' instead of 'buffer' - The post will not be published until explicitly scheduled
`schedulingType`	No; body and guard rules apply	string	Scheduling type to indicate notification publishing or automatic publishing. Omit it, or send null, to leave the post publishing the way it already does. Values: `automatic`, `notification`.
`source`	No; body and guard rules apply	string	source where the composer was initiated from, used for tracking.
`tagIds`	No; body and guard rules apply	array	tags Items: string.
`text`	No; body and guard rules apply	string	Text content of the Post. Omit the field to keep the current text; pass an empty string or null to clear it. Note: for threaded posts, this needs to match the first item in the `thread` array.

ideaGroups.input

Argument	Required	Type	Details
`organizationId`	Yes	string	Unique identifier for the organization.

ideas.input

Argument	Required	Type	Details
`groupFilter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	Yes	string	The organization to fetch ideas from.
`tagsFilter`	No; body and guard rules apply	object	See the full input schema.

ideas.input.groupFilter

Argument	Required	Type	Details
`groups`	No; body and guard rules apply	array	Return only ideas that belong to these specific groups (union/OR). Items: string.
`membership`	No; body and guard rules apply	string	Return ideas by a group-membership bucket rather than by specific group IDs. Values: `grouped`, `ungrouped`.

instagramAudio.input

Argument	Required	Type	Details
`audioId`	Yes	string	Meta audio asset ID
`channelId`	Yes	string	Instagram channel used to authorize the refresh

movePostInQueue.input

Argument	Required	Type	Details
`id`	Yes	string	ID of the post to move.
`position`	Yes	string	Target position within the channel's queue. Values: `bottom`, `top`.

post.input

Argument	Required	Type	Details
`id`	Yes	string	The ID of the post to be retrieved

posts.input

Argument	Required	Type	Details
`filter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	Yes	string	The Organization id to fetch posts for
`sort`	No; body and guard rules apply	array	The sort to apply to the posts results Items: object.

posts.input.filter

Argument	Required	Type	Details
`channelIds`	No; body and guard rules apply	array	When set, it will filter posts by channel Items: string.
`dueAt`	No; body and guard rules apply	object	See the full input schema.
`dueAtPresence`	No; body and guard rules apply	string	When set, it will filter posts by whether their scheduled posting date exists. `absent` cannot be combined with `dueAt`, because absent dates cannot also match a date range. Values: `absent`, `present`.
`endDate`	No; body and guard rules apply	string	When set, it will return posts with createdAt or dueAt date before endDate
`postTypes`	No; body and guard rules apply	array	When set, it will filter posts by format. `post` is a fallback bucket rather than one stored format: it matches every post the other formats do not claim, which is what `Post.metadata.type` reports for the same post. `carousel` and `thread` are rejected, because no stored value resolves to them. Items: string.
`startDate`	No; body and guard rules apply	string	When set, it will return posts with createdAt or dueAt date after startDate
`status`	No; body and guard rules apply	array	When set, it will filter posts by status Items: string.
`tagIds`	No; body and guard rules apply	array	When set, it will filter posts by tag Items: string.
`tags`	No; body and guard rules apply	object	See the full input schema.
`createdAt`	No; body and guard rules apply	object	See the full input schema.

posts.input.sort[]

Argument	Required	Type	Details
`direction`	Yes	string	The direction to sort by. Values: `asc`, `desc`.
`field`	Yes	string	The field to sort by. Values: `dueAt`, `createdAt`.

postTemplate.input

Argument	Required	Type	Details
`id`	Yes	string	The unique identifier of the template to fetch.

postTemplates.input

Argument	Required	Type	Details
`filter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	Yes	string	Organization to scope `internal`-visibility templates to. The caller must be a member of this organization.

postTemplates.input.filter

Argument	Required	Type	Details
`visibility`	No; body and guard rules apply	string	Narrow the result to a single visibility scope. Omit to receive the union of: public templates, internal templates from the supplied organization, and private templates from the actor's account. Values: `internal`, `private`, `public`.

promoteContentItemDraftToPosts.input

Argument	Required	Type	Details
`id`	Yes	string	The content item to promote.
`posts`	Yes	array	The channel-specific posts to create, one per channel. Provide at least one post, and at most one post per channel. Items: object.
`tagIds`	No; body and guard rules apply	array	Tags to apply to this content item. Omit to keep the current tags. An empty list or null removes them all. Items: string.

removePostFromContentItem.input

Argument	Required	Type	Details
`id`	Yes	string	The content item to remove the post from.
`postId`	Yes	string	The post to remove from a content item.

searchInstagramAudio.input

Argument	Required	Type	Details
`audioType`	Yes	string	Music or original sound catalog Values: `music`, `originalSound`.
`channelId`	Yes	string	Instagram channel to search audio for
`query`	Yes	string	Search text. Required. Use trendingInstagramAudio for trending results.

tag.input

Argument	Required	Type	Details
`id`	Yes	string	The unique identifier of the tag to fetch.

tagsV2.input

Argument	Required	Type	Details
`filter`	No; body and guard rules apply	object	See the full input schema.
`organizationId`	Yes	string	Organization to list tags for. The caller must be a member of this organization.

tagsV2.input.filter

Argument	Required	Type	Details
`isLocked`	No; body and guard rules apply	boolean	Return only locked tags when true, only unlocked tags when false. Omit to return both. See `Tag.isLocked` for what locking means.

Argument	Required	Type	Details
`audioType`	Yes	string	Music or original sound catalog Values: `music`, `originalSound`.
`channelId`	Yes	string	Instagram channel to load trending audio for

updateContentItem.input

Argument	Required	Type	Details
`id`	Yes	string	The content item to update.
`targetDate`	No; body and guard rules apply	string	Omit to preserve the existing target date. Null clears it.
`title`	No; body and guard rules apply	string	Omit to preserve the existing title. Null clears it.

updateContentItemDraft.input

Argument	Required	Type	Details
`id`	Yes	string	The content item whose channel-less draft is replaced.
`draft`	Yes	object	See the full input schema.
`tagIds`	No; body and guard rules apply	array	Tags to apply to this content item. Omit to keep the current tags. An empty list or null removes them all. Items: string.
`targetDate`	No; body and guard rules apply	string	Date indicating when this piece of content should go out. This is a planning aid only and does not schedule any posts. Omit to preserve the existing target date. Null clears it.

updatePostTemplate.input

Argument	Required	Type	Details
`id`	Yes	string	The ID of the template to update.
`body`	No; body and guard rules apply	string	The main content body of the template, may contain {{placeholders}}.
`description`	No; body and guard rules apply	string	A short user-facing description of the template.
`emoji`	No; body and guard rules apply	string	The emoji associated with the template.
`title`	No; body and guard rules apply	string	The title of the template.
`visibility`	No; body and guard rules apply	string	`public` is rejected — it is only available to official Buffer clients. Values: `internal`, `private`, `public`.

9. Publishing, content items and analytics

Deliberate posting and scheduling

Read the account, exact organization and connected channel. Inspect createPost input and supported metadata for that service. Current modes are addToQueue, customScheduled, shareNext and shareNow; schedulingType is automatic or notification. shareNow can reach people immediately. A draft requires saveToDraft=true; needsApproval follows the channel's provider-side policy and conflicts with explicitly disabling saveToDraft. Due dates and publication restrictions remain provider validated.

buffer-cli get-channel --id SELECTED_CHANNEL --fields id --fields name --agent
buffer-cli preview-operation --operation createPost --arguments '{"channelId":"SELECTED_CHANNEL","mode":"addToQueue","schedulingType":"automatic","saveToDraft":true,"text":"Reviewed draft"}' --agent
buffer-cli create-post --payload-file /absolute/private/approved-post.json --account work --confirm --agent
buffer-cli get-post --id RETURNED_POST_ID --fields id --fields status --agent

Preview is schema/document validation only: it does not check account access, media reachability, platform text limits or Buffer scheduling policy. An approved file must contain the native input exactly reviewed. One approved draft does not authorize scheduling, promotion, retries or all posts in an organization. Keep the returned ID and inspect existing state before any deliberate repeat.

Platform metadata and media

The current native schema includes service-specific metadata, media assets and threaded inputs. Read the nested tables and provider's posting guide. Platform capabilities differ: automatic versus notification delivery, text/media formats, approvals, first comments and thread rules are not interchangeable. The wrapper does not rewrite platform metadata or guess limits. Named schemas catch structure/enums; provider semantic validation is authoritative.

Supply supported externally reachable asset URLs. A local path is not uploaded. URLs supplied to Buffer are processed by the provider; request confirmation includes only the selected assets and target. Private/signed URLs can expose credentials and expire before publication; output redaction is not a guarantee that a submitted URL is safe to share.

Content items, ideas and templates

Content items coordinate organization content and channel drafts. Inspect the selected item's existing drafts/posts before create/update/add/remove or promoteContentItemDraftToPosts. Promotion creates posts under the documented scheduling rules and requires its own confirmation. Ideas and post templates have distinct schemas and permissions; templates can be private/internal and inherit provider actor visibility. Never assume these commands grant team access or publish automatically.

Analytics

aggregatedPostMetrics uses an explicit organization and startDateTime/endDateTime, optionally channelIds. An empty channelIds list means no channels, unlike omitted/null. Current date windows are capped at 365 days; metrics refresh daily and require the provider's PAT insightsRead permission. Current OAuth app grants cannot request that scope. Zero/absent metrics are not proof that no posts performed. Inspect provider availability and dates; do not fabricate missing results.

10. Pagination, retries and local input files

Ordinary paginated tools request one page with native first/after/input arguments and return edges/node/pageInfo. The default page size is 25 where declared; local first cap is 100. Cursors are opaque and must be passed unchanged.

buffer-cli query-pages --operation posts --arguments '{"organizationId":"SELECTED_ORG","fields":["items.id","items.status"],"first":25}' --max-pages 3 --agent

query_pages accepts only current named paginated reads, one to five pages. It adds hasNextPage and endCursor fields, returns page responses and resumeCursor, and stops at the requested cap. Missing or repeated cursors abort remaining requests; this is an error, not a complete-library claim. Provider errors also abort remaining pages and no retries run. For very large results, each page still faces the response cap and provider complexity limits. A later continuation sees current account state, not a snapshot guarantee.

payload_file must be regular non-symlink JSON up to 1 MiB. Native input fields, payload and payload_file are mutually exclusive; account, fields, pagination and confirm are outside native payload. No media bytes, output-file downloads or unlimited polling are implemented. Store account responses privately through your own reviewed shell output process; the package does not hide private post/customer content automatically.

Transport failure does not establish that a mutation failed remotely. Preserve its inputs/returned IDs and inspect the provider before making a deliberate repeat. Rate limits can be GraphQL errors inside HTTP 200 as well as transport responses. Quota is shared by the actual upstream client, not reserved by a local label or preview.

11. Several private accounts

BUFFER_ACCOUNTS is a private JSON array of unique labels with api_key (or api_token), token_file and optional organization_id. The array replaces single-account settings completely; no entry inherits a global token or organization. BUFFER_DEFAULT_ACCOUNT selects the default, otherwise the first label is used. Unknown labels/defaults refuse.

[{"name":"work","token_file":"/absolute/private/buffer-work.txt","organization_id":"YOUR_WORK_ORG"},{"name":"personal","token_file":"/absolute/private/buffer-personal.txt","organization_id":"YOUR_PERSONAL_ORG"}]

A selected profile fills a missing organizationId only for named native inputs that declare it. An explicit request organizationId takes precedence; generic GraphQL variables are preserved exactly. Preview requires explicit input and reads no credential/profile defaults. list_accounts returns labels/default/authentication presence only, never tokens, file paths or organization IDs.

A profile label is credential routing, not a security boundary for an account-wide PAT. Use separately scoped provider grants/accounts where appropriate. Several labels using the same grant still share permissions and rate quota. Token files override inline profile keys and are cached until restart.

12. Writing safely

All 17 exposed mutation tools require --confirm/confirm=true for the exact human-requested action. Named create/edit/delete/queue/content/promotion/template operations and generic GraphQL mutation pass through one WriteGuard before file reading or network work.

BUFFER_READ_ONLY=1 hides mutations from discovery and refuses direct hidden calls. BUFFER_ALLOW_DESTRUCTIVE=0 separately refuses mutations even with confirmation. --agent/--yes are output/noninteractive controls, not permission to publish. Local preview is available in read-only mode because it validates and returns data without transmitting a mutation.

Generic query parses exactly one GraphQL query and refuses mutation/subscription/multiple-operation documents. Generic mutation parses exactly one mutation with one direct root field; multi-action/root-fragment mutation documents refuse. It inserts __typename and the MutationError message catch-all. Aliases are preserved. Buffer validates native generic variables and provider permissions; local schema validation of unknown experimental operations is not claimed.

Audit writes are opt-in metadata containing time, surface, tool, risk, static description and guard outcome, without keys, post text, native variables or provider content. Keep the log private. Guard acceptance is permission to attempt one operation, not proof it succeeded remotely. Provider permissions/client consent remain independent.

13. How the two surfaces work

src/tools/index.ts exports one ALL_TOOLS catalogue, current published native metadata and six helpers. The SDK server registers discovery and calls; the house CLI uses SDK in-memory transport to obtain the same schemas and execute the same handlers. There is one validation path, one private client and one WriteGuard.

Thirty-five native GraphQL shells, nested input schemas and selection trees are reused from @bufferapp/cli 1.2.2. The upstream field-selection renderer is credited under ISC. Ajv performs strict native input checks; GraphQL parsing verifies generic operation type before transmission. Only the fixed HTTPS Buffer endpoint is used; redirects, arbitrary API hosts and arbitrary caller headers are absent.

The 41 tools include 24 reads and 17 mutations. These are shared wrapper catalogue counts, not the count of provider endpoints or a superiority benchmark. The current reference contains 42 roots, including seven newer experimental roots accessible through generic GraphQL subject to availability. See THIRD_PARTY_NOTICES.md and api-source.json for source versions/checksums.

14. Privacy and data handling

Credentials stay in private environment/client settings or token-only files. The server caches file credentials until restart and sends Bearer only to https://api.buffer.com, with redirects refused. It neither reads official global/repository Buffer configuration nor collects browser cookies. No telemetry relay, browser sign-in, local content database or public HTTP server is added.

API responses can contain post text, media, customer/account identifiers, organization/channel metadata and performance data. Outputs remain sensitive even when credential-like fields, the configured token and recognized signed credential URLs are redacted. Redaction is not anonymization; arbitrary secrets in free-form content can still appear. Local preview includes the supplied post/input content and should also stay private.

Buffer receives the requested native GraphQL operation/variables; social delivery and asset processing follow provider terms. Model/client hosting sees whatever tool output you let it receive. --fields limits requested data; --select trims after receipt. Neither control changes provider consent or guarantees a safe URL.

Opt-in audit logs contain guard metadata only. Do not put credentials, signed links, raw headers, account dumps or .env files into commits, artifacts or public issues. Private legacy history stays outside the new public repository. Public npm and desktop bundles must be scanned before release.

15. Environment variables

Credentials

Variable	Meaning
`BUFFER_API_KEY`	Private account-wide PAT or authorized OAuth access token
`BUFFER_API_TOKEN`	Legacy alias; API_KEY wins if both exist
`BUFFER_TOKEN_FILE`	Regular owner-only token-only file, max 64 KiB; overrides environment key
`BUFFER_ACCOUNTS`	Private named profile array; no global credential/default inheritance
`BUFFER_DEFAULT_ACCOUNT`	Exact configured label; default first entry
`BUFFER_ORGANIZATION_ID`	Optional input default for single account; does not restrict permissions

Safety

Variable	Meaning
`BUFFER_READ_ONLY`	1/true hides and refuses mutations; default false
`BUFFER_ALLOW_DESTRUCTIVE`	0/false refuses even confirmed mutations; default true
`BUFFER_AUDIT_LOG`	Private append-only guard decisions, no input content

Tuning

Variable	Meaning
`BUFFER_REQUEST_TIMEOUT_MS`	Default 30000, range 100–300000
`BUFFER_MIN_REQUEST_INTERVAL_MS`	Default 200, range 0–10000; process/profile pacing only

16. Updates and removal

npx -y @thenavidm/buffer-mcp-cli@latest re-resolves the latest registry tag when the client launches; restart to run the updated process. Global installs require npm update -g @thenavidm/buffer-mcp-cli; pinned versions require an intentional change. Desktop archives are versioned and must be downloaded/reinstalled separately. Clones require reviewing the changelog, pulling, npm ci and rebuilding.

npm update -g @thenavidm/buffer-mcp-cli
buffer-cli --version
# Disconnect the server in each client before local removal.
npm uninstall -g @thenavidm/buffer-mcp-cli

Remove the matching client entry or desktop extension and separately remove any registered skill. Delete/revoke private grants using provider controls if requested. Local uninstall does not revoke credentials, disconnect social accounts or undo scheduled/published posts. Keep private input/audit files only for your actual needs.

17. Troubleshooting

Symptom	Check
Binary absent	Node 22+, npm prefix/PATH, reopen terminal; PowerShell can use npm.cmd
Configuration exit 10	Private token path/permissions, account label/default and GUI environment
Auth/forbidden exit 4	Actual Buffer key/grant, organization role and connected-channel authorization
Refused mutation exit 2	Exact human request, explicit confirm, read-only/disabled settings
Native input/schema error	Current required fields/enums/nested schema; do not mix payload and body flags
Unknown fields	get_operation_schema; use relative selection paths and items for connections
HTTP 200 but failure	GraphQL errors or typed MutationError; inspect safe error and provider state
Rate limit exit 7	Provider returned quota/reset, shared PAT/MCP bucket and per-plan windows
Post accepted but not published	Returned post status, notification delivery, approvals and platform processing
Missing analytics	PAT insightsRead, provider availability, daily refresh and date range
Missing/repeated pagination cursor	Stop and inspect state; never assume the library is complete
GUI discovers nothing	Server stdio launch/PATH, private settings, duplicate extension/manual entries, restart
Local preview works but API fails	Preview is structural only; account permissions/semantic limits still require provider validation

Do not log credentials or post/customer content in a public issue. Include package/Node/client versions, exact command name, safe error code, whether a request was sent and redacted reproduction. Never disable policies or replay a publication merely to hide an error.

18. API coverage and comparisons

Offering	Surface and current evidence	Tradeoff
Official MCP	https://mcp.buffer.com/mcp; 20 documented tools plus generic GraphQL query/mutation	Provider-maintained remote connection and client approval flow. Generic GraphQL already reaches the API; do not claim ours uniquely supports the full API. Live authenticated discovery was not performed in this review.
Official CLI	@bufferapp/cli 1.2.2; buffer; 35 published generated operations	Native inputs, schema exploration, upstream --fields, dry-run, JSON/stdin, doctor, contexts and Codex/Claude skills already exist. Setup and update flows remain useful.
This owned package	Shared buffer-cli / local MCP / versioned .mcpb; 35 named operations plus six useful helpers	Enforces mutation confirmation/read-only policies in both surfaces, isolated private profiles, credential redaction, local previews and bounded read pagination. Requires Node 22+. No automatic OAuth renewal or official interactive setup.
Buffer API	Current reference: 42 root operations	Seven newer snippet/tag roots are marked experimental; generic GraphQL can request them subject to provider availability. They are not presented as stable named-tool superiority.
Community GraphQL MCP	Python local MCP, 13 source-declared tools	Current GraphQL workflows include post batches, R2 media hosting and optional Twitter-side integration. No dedicated task CLI is established by this source review. update_post performs delete then create, which can partially fail; it is not a transactional update. Those integrations are useful capabilities absent from this wrapper.
Community REST MCP	Node MCP for legacy API	Source targets api.bufferapp.com/1 and old profiles/updates/schedules. It is not evidence of current GraphQL parity. Only source was reviewed; account compatibility was not exercised.

Checked October 3, 2026. The current reference, changelog and published official 1.2.2 archive were read directly. A clean anonymous npm 10.9.8 install of that archive fails EUNSUPPORTEDPROTOCOL because its published commander dependency is catalog:. No dependency rewrite or workaround was used. This is a dated installer observation, not a permanent provider limitation or evidence that every installer fails.

To compare local confirmation behavior despite that packaging issue, a network-free fixture exercises the actual published executePipeline and pure helpers with its real generated createPost input/document, a fake token resolver and a mocked GraphQL response. Valid shareNow input without a confirm flag reaches the injected request once; official dry-run reaches it zero times. This is an isolated published function fixture, not a complete official CLI installation or a claim that remote MCP clients lack approvals. The owned equivalent refuses before transmission without explicit confirmation; read-only/disabled policies refuse even confirmed calls.

Pinned community sources were read without executing them or using provider accounts: GraphQL d8516a6 and legacy REST 25eeb35. Their advertised capabilities are not treated as validated account outcomes.

Both official CLI and this package perform upstream field selection and detect typed API errors. Neither capability is claimed unique. Our local --select additionally trims already received output; it cannot reduce upstream work. The owned recurring workflow is deliberate reviewed publishing or administration across isolated profiles with shared enforced policy and bounded reads. No token, speed, success-rate or global superiority claim is inferred from schemas, SEO or tool counts. Provider-account outcomes, desktop GUI and matched Codex task usage remain separate.

19. Versions

Component	Current baseline
`Package / desktop`	2.0.0
`Named operations / current reference`	35 generated / 42 roots, seven experimental newer roots via generic
`Shared catalogue`	41 tools: 24 reads, 17 confirmed mutations
`Official CLI inspected`	@bufferapp/cli 1.2.2 (published package)
`Official MCP`	20 documented tools plus generic GraphQL; no authenticated discovery
`Node`	22+; CI targets 22/24 on macOS/Linux/Windows
`@modelcontextprotocol/sdk`	1.32.0
`ajv`	8.20.0
`ajv-formats`	3.0.1
`graphql`	16.14.2
`typescript`	7.0.2
`vitest`	5.0.3
`vite`	8.3.2
`acorn`	8.18.0
`@anthropic-ai/mcpb`	2.1.2

Checked October 3, 2026. CHANGELOG records dated changes. Package/manifest, annotated default-branch tag, npm latest and desktop filename must agree. Preserve AGPL and private legacy history. Refresh through reviewed, checksum-recorded official schemas; never copy a public schema example without scanning it.

The private 1.0.0 legacy MCP had no declared CLI binaries and used older query/input shapes. Current organizations are read through account.organizations, and channel uses channel(input:{id}), not channel(id). New named tools use get_ for queries and native snake_case for mutations; discover current commands instead of relying on old names. Every mutation now requires confirmation. BUFFER_API_TOKEN remains an alias, while native current input and exact role restrictions take precedence. No prior public npm release is assumed.

20. FAQ

No. Navid Media builds this owned wrapper. Buffer maintains separate official MCP and CLI products, which are compared here.

The useful added workflow is one shared enforced confirmation/read-only policy across local surfaces, isolated profiles and bounded native read pagination. Official field selection, dry-run and API coverage already exist; no blanket superiority is claimed.

Yes. buffer-mcp and buffer-cli share 41 tools, handlers, input schemas, private accounts and guard.

The AGPL wrapper is free. Buffer plans, API quota, account roles and social-platform policies remain separate.

Use the intended account's publish.buffer.com/settings/api controls. Store it privately in BUFFER_API_KEY or a regular token-only BUFFER_TOKEN_FILE; login only prints instructions.

Personal API keys can act across accessible organizations. A local organization default/profile is input routing and cannot narrow those provider permissions.

Yes. Unique named private profiles select their own keys/files/default organization. They never inherit a global credential or organization when the profile array is configured.

Use the documented local stdio registration or shared CLI. Codex is the priority; fresh matched task/token usage remains pending.

Use Node 22+ on the chosen OS. GUI environment/PATH and Windows private-file ACLs need separate setup. Cross-platform CI is required before release.

The versioned .mcpb bundles production dependencies and private configuration fields for a compatible desktop host. Actual GUI installation remains a separate acceptance check.

No. --agent/--yes set output/noninteractive behavior. The precise requested mutation still needs --confirm or confirm=true and enabled policies.

Yes. Mutations disappear from discovery and direct calls refuse. Generic query parses operation type and refuses mutation/subscription/multiple-operation documents.

No. It validates native structure and fields and returns document/variables without credentials or requests. Permissions, media, platform and scheduling rules remain remote checks.

Buffer reports GraphQL errors and typed mutation errors in the JSON body. The wrapper checks them, and named mutations require a recognized successful result type.

No local media upload is implemented. Supply the current native asset URLs that Buffer can reach and that the chosen platform supports; local file paths are not uploads.

Ordinary reads fetch one page. query_pages fetches one to five pages, reports continuation and stops on malformed/repeated cursors; it never claims an unbounded complete library.

Generic GraphQL can request the seven newer documented experimental roots, subject to provider availability and native variables. They are not stable dedicated named tools in this release.

No automatic OAuth exchange/refresh is implemented. Analytics requires the current PAT insightsRead permission, supported data and a date window up to 365 days; current OAuth grants cannot request that scope.

Only a matched successful Codex task with actual usage can establish that. Upstream fields and local output selection help bound data, but counts, character estimates and borrowed metrics do not prove token savings.

Restart @latest client launches, update global npm installs separately, and reinstall the versioned desktop bundle separately. Uninstall does not revoke keys or undo scheduled/published posts.

Questions

Open a sanitized issue. Read SECURITY.md for private reports.

About the author

Navid Moazzez is a leading AI business strategist, and the host of the AI Creator Summit, watched by 100,000+ creators. He helps creators and founders master AI and build their own AI Operating System (AI OS) to automate their business and life. This Buffer MCP server and CLI is one piece of that system.

Links

Personal website: navid.me
Link in bio: navid.bio
Navid Media: navid.media
YouTube: @thenavidm and @thenavidai
X: @thenavidm
Instagram: @thenavidm
LinkedIn: thenavidm

If this is useful, star the repo and come say hi on X.

Dependencies

Runtime: MCP TypeScript SDK, Ajv, ajv-formats and GraphQL. Development: TypeScript, Vitest, Vite, Acorn and MCPB. Exact component versions are above and in package-lock.json. ISC Buffer selection code and generated metadata are credited in THIRD_PARTY_NOTICES.md; development packaging tools are excluded from runtime bundles.

License

Preserves AGPL-3.0-or-later. Read LICENSE, the full text and THIRD_PARTY_NOTICES.md. Provider terms remain separate.

Available Tools

41 tools

add_post_to_content_itemAdd a post that already exists to a content item. The mutation creates no post. To add a new post, call createPost first.A

Destructive

Add a post that already exists to a content item. The mutation creates no post. To add a new post, call createPost first.. Current Buffer GraphQL addPostToContentItem. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The content item to add the post to.
`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.
`postId`	No	The post to add. The post must already exist. The post and the content item must belong to the same organization.
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`confirm`	No	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds useful non-structured context: explicit confirmation is required, upstream field bounding is advised, and provider errors surface as failures even on HTTP 200. It still never says what the mutation actually alters on the content item.

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 title is duplicated verbatim inside the description, producing the awkward 'first..' repetition, and the trailing sentence about upstream fields and provider errors is loosely attached. Core information is front-loaded, but roughly half the text is redundant with the title or schema.

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 7-parameter mutation with no output schema and no required top-level parameters, the description covers the key behavioral facts an agent needs: confirmation requirement, the distinction from post creation, and error semantics. It leaves unclear which identifier inputs are mandatory and how the three input modes (individual fields vs payload vs payload_file) should be chosen, though the schema covers those.

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 every parameter including the nested payload and payload_file is already documented in the schema. The description's only parameter-adjacent remark ('Use upstream fields to bound data') restates the fields schema description rather than adding format or constraint detail, so the baseline of 3 applies.

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

Purpose5/5

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

States a precise verb+resource ('add a post that already exists to a content item') and immediately disambiguates from the create path by noting the mutation creates no post. An agent can distinguish this from create_post and remove_post_from_content_item without opening any schema.

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 a clear when-not condition ('creates no post') and names the alternative workflow ('To add a new post, call createPost first'), which maps to the create_post sibling. It does not explain when to prefer remove_post_from_content_item or what preconditions the content item must satisfy, 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.

create_content_itemCreate a content item together with all of its channel-specific post variants in a single operation. Validation is all-or-nothing: if any variant fails validation, no content item and no variants are created. Variants that fail while being processed after creation are reported per channel in the failure payload; the content item and its variants are still created in that case. This API is an early preview and can change without a deprecation period.A

Destructive

Create a content item together with all of its channel-specific post variants in a single operation. Validation is all-or-nothing: if any variant fails validation, no content item and no variants are created. Variants that fail while being processed after creation are reported per channel in the failure payload; the content item and its variants are still created in that case.

This API is an early preview and can change without a deprecation period.. Current Buffer GraphQL createContentItem. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`posts`	No	The channel-specific post variants to create, one per channel. Provide at least one variant, and at most one variant per channel.
`title`	No	Optional title describing what this piece of content is about.
`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.
`tagIds`	No	Tags to apply to this content item. Omit to create it with no tags.
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`confirm`	No	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`targetDate`	No	Optional date indicating when this piece of content should go out. This is a planning aid only and does not schedule any posts.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No	Organization that owns the content item and all variants created in it.

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (destructive=true, idempotent=false), the description discloses genuinely non-obvious behavior: all-or-nothing validation that rolls back creation on pre-creation failures, per-channel failure reporting for post-creation failures where the item and variants persist, a mandatory confirmation gate, provider errors surfacing as failures even with HTTP 200, and the fragility of an early-preview API.

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?

Purpose is front-loaded and the extra sentences (confirmation, field bounding, provider errors) each carry weight. It loses a point because the entire title block is duplicated verbatim in the description, including a stray double period, adding length without new 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 a high-complexity, destructive, non-idempotent 10-parameter mutation with no output schema, the description covers the critical gaps: creation semantics, rollback vs partial-failure outcome, and preview instability. It does not describe the returned payload structure or how the caller learns which channels failed beyond the per-channel mention, but the core decision-relevant behavior is present.

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 100%, so the baseline is 3, but the description adds real meaning for two parameters: it ties the explicit-confirmation requirement to `confirm` and explains the purpose of `fields` (upstream field paths that bound data). The large nested post/metadata payloads are left entirely to the schema, which is reasonable given its richness.

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

Purpose5/5

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

The description states a specific verb and composite resource: creating a content item together with all of its channel-specific post variants in a single operation. This clearly separates it from siblings like create_post, create_content_item_draft, and add_post_to_content_item without the agent needing to open any schema.

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?

It conveys clear operating context: the call requires explicit confirmation and upstream `fields` should be used to bound the response. It does not, however, explicitly say when to prefer this over create_post or create_content_item_draft, so the agent must infer the alternative-routing decision.

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

create_content_item_draftCreate a content item holding a channel-less draft, before any channels are selected. No network-specific validation applies to the draft content. The draft needs text or at least one asset. This API is an early preview and can change without a deprecation period.A

Destructive

Create a content item holding a channel-less draft, before any channels are selected. No network-specific validation applies to the draft content. The draft needs text or at least one asset.

This API is an early preview and can change without a deprecation period.. Current Buffer GraphQL createContentItemDraft. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`draft`	No
`title`	No	Optional title describing what this piece of content is about.
`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.
`tagIds`	No	Tags to apply to this content item. Omit to create it with no tags.
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`confirm`	No	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`targetDate`	No	Optional date indicating when this piece of content should go out. This is a planning aid only and does not schedule any posts.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`correlationId`	No	Client-generated UUID that makes draft creation idempotent. A retry with the same UUID in the same organization returns the first content item in its current state.
`organizationId`	No	Organization that will own the content item.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true), but the description adds material context beyond them: an explicit-confirmation requirement, an early-preview warning that it may change without deprecation, that no network-specific validation applies, and that provider errors surface as failures even on HTTP 200. Missing only the effect on returned state, but this is notably richer than the annotations alone.

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 first two sentences are a verbatim copy of the tool title, so a meaningful chunk of the text repeats structured data the agent already has, and a stray double period appears where the title was concatenated. The appended sentences are each useful and front-loaded, but the duplication prevents a higher score.

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 11-parameter, deeply nested mutation with no output schema, the definition covers identity, stage in the workflow, content precondition, confirmation requirement, and preview instability. It stops short of describing the returned object or the correlationId idempotency behavior (schema-only), but nothing critical for correct invocation is missing.

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 91%, so the schema already carries nearly all parameter meaning (including normalized x/y coordinates, video thumbnailOffset, and correlationId idempotency). The description contributes only light hints ('Use upstream fields to bound data' for `fields`, confirmation for `confirm`), so the baseline 3 is appropriate.

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 names a specific verb (create) and resource (content item draft) and adds a genuine scope qualifier: it holds a 'channel-less draft, before any channels are selected', and states the content precondition (text or at least one asset). That scope clause implicitly separates it from create_content_item/create_post, but no sibling is actually named, so differentiation requires inference.

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?

There is usable guidance ('before any channels are selected', 'Requires explicit confirmation', 'Use upstream fields to bound data'), which tells the agent this is a pre-channel stage and needs a confirm flag. However, it never says when to prefer this over create_content_item, create_idea, or create_post, and gives no exclusions or prerequisites for those alternatives.

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

create_ideaCreate a new idea with the given content and metadataA

Destructive

Create a new idea with the given content and metadata. Current Buffer GraphQL createIdea. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`cta`	No	Call-to-action identifier for analytics tracking
`group`	No
`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	Must be true for this exact user-requested Buffer mutation.
`content`	No
`payload`	No	Complete native input object instead of individual input fields.
`templateId`	No	Template ID used to create the idea
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No	Organization ID that will own the idea

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, idempotentHint=false and openWorldHint=true, and the description adds behavior beyond them: the mandatory confirmation requirement, the fact that provider errors count as failures even with HTTP 200, and the instruction to bound returned data via upstream fields. It stops short of describing return shape or failure modes in detail, but the added context is substantive.

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?

Four short sentences, front-loaded with the core action and no obvious filler. It is slightly dense in the back half, but every clause carries operational meaning.

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 a 10-parameter tool with nested objects and no output schema, the description covers the confirmation gate and error semantics but omits the relationship between the three input modes and any notion of what a successful response contains. It is adequate but not fully complete for the tool's complexity.

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 80%, so most parameters are already self-documenting. The description touches two of them (fields for bounding data, confirm for the confirmation gate) but does not clarify the mutual exclusivity of payload vs individual fields vs payload_file or the nested content structure, so it adds only marginal value over the schema.

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+resource ("Create a new idea") and identifies the underlying operation (Buffer GraphQL createIdea), which cleanly separates it from read siblings like get_ideas and get_idea_groups. It does not, however, differentiate itself from write siblings such as create_content_item or create_post, leaving the agent to infer when an 'idea' is the right target.

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?

"Requires explicit confirmation" gives a real workflow precondition that maps to the confirm parameter, which is implied usage guidance. There is no explicit when-to-use vs alternative routing (e.g. idea vs content item vs post), so an agent still has to infer selection from the resource name alone.

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

create_postCreate a new postA

Destructive

Create a new post. Current Buffer GraphQL createPost. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`mode`	No	How the post is being scheduled.
`text`	No	Text content of the Post. Note: for threaded posts, this needs to match the first item in the `thread` array.
`dueAt`	No	Date when the post is scheduled to be published
`assets`	No	Ordered list of assets on this post.
`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.
`ideaId`	No	Is set when the Post is generated from an Idea
`source`	No	source where the composer was initiated from, used for tracking.
`tagIds`	No	List of tag IDs
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`confirm`	No	Must be true for this exact user-requested Buffer mutation.
`draftId`	No	Is set when the Post is generated from a Draft
`payload`	No	Complete native input object instead of individual input fields.
`metadata`	No
`channelId`	No	Channel's Id for which we want to create the post
`aiAssisted`	No	If this post was created with the help of AI
`saveToDraft`	No	If true, saves the post as a draft instead of scheduling it. When saving as draft: - Post status will be 'draft' instead of 'buffer' - Posting limits are not checked - The post will not be published until explicitly scheduled
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`needsApproval`	No	Submit the post for approval instead of scheduling it. A post submitted for approval is always a draft, so this conflicts with turning `saveToDraft` off. Only valid when your posting policy on the target channel requires approval.
`schedulingType`	No	Scheduling type to indicate notification publishing or automatic publishing

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, idempotentHint=false and openWorldHint=true, but the description adds two non-obvious traits: an explicit confirmation requirement and the important caveat that provider errors count as failures even on HTTP 200, which an agent cannot infer from the schema alone.

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 core purpose front-loaded and no filler. The 'Current Buffer GraphQL createPost' clause is slightly opaque but costs little.

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 a 19-parameter, deeply nested mutation with no output schema and no annotations covering the payload/payload_file mutual exclusion, the description is thin. It covers confirmation and error semantics well but says nothing about scheduling modes, draft/approval interaction, or channel targeting beyond what the schema states.

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 95% across 19 params, so the schema already documents nearly everything, including the confirm, fields, payload, and payload_file semantics. The description adds no parameter-level detail beyond the fields-bounding hint, so the 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+resource ('Create a new post') and identifies the underlying operation ('Current Buffer GraphQL createPost'). However, it does not distinguish itself from nearby siblings like create_post_template, create_content_item_draft, or promote_content_item_draft_to_posts, leaving sibling selection to inference.

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?

'Requires explicit confirmation' signals a prerequisite, and 'Use upstream fields to bound data' hints at usage, but there is no explicit when-to-use/when-not guidance and no routing against the sibling creation tools.

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

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

Destructive

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.

ParametersJSON 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	Must be true for this exact user-requested Buffer mutation.
`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	A 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_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No	Organization 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.

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.

delete_content_itemDelete a content item: the item itself and any posts created from it. Deletion is all-or-nothing. Every post must be deletable on its own, or nothing is deleted and every blocked post is reported at once. A post can only be deleted while it is a draft, awaiting approval, scheduled, or failed, so an item cannot be deleted while any of its posts is publishing or already published. An item still holding a channel-less draft has no posts, so nothing blocks it. An error can also be reported when a post could not be fully processed after the deletion already took effect; re-fetch before retrying. This API is an early preview and can change without a deprecation period.A

Destructive

Delete a content item: the item itself and any posts created from it. Deletion is all-or-nothing. Every post must be deletable on its own, or nothing is deleted and every blocked post is reported at once. A post can only be deleted while it is a draft, awaiting approval, scheduled, or failed, so an item cannot be deleted while any of its posts is publishing or already published. An item still holding a channel-less draft has no posts, so nothing blocks it. An error can also be reported when a post could not be fully processed after the deletion already took effect; re-fetch before retrying.

This API is an early preview and can change without a deprecation period.. Current Buffer GraphQL deleteContentItem. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The content item to delete.
`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	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A4.3/5.0

Behavior5/5

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

Substantially exceeds the annotations (destructiveHint=true, idempotentHint=false) by disclosing all-or-nothing deletion semantics, blocked states, the special channel-less draft case, the post-deletion error case with a re-fetch-before-retry instruction, and the preview/no-deprecation-period caveat. This is exactly the behavioral context an agent needs for an irreversible mutation.

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-loaded with the core action and scope, and each subsequent sentence carries real semantic weight about blocking conditions and retry behavior. It loses a point only because the title is reproduced verbatim as the description body, creating duplication.

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 destructive, non-idempotent mutation with no output schema, the description covers failure modes, blocking rules, and post-error recovery guidance. It stops short of stating what a successful response contains or how partial provider errors surface, though the 'provider errors are failures even with HTTP 200' note partially bridges that.

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 baseline is 3. The description only marginally adds meaning — 'Use upstream fields to bound data' loosely connects to the fields parameter and 'Requires explicit confirmation' echoes the confirm parameter's own schema text — while account, payload, and payload_file get no narrative elaboration.

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

Purpose5/5

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

States a specific verb+resource ('Delete a content item') and explicitly extends scope to 'any posts created from it', distinguishing it from the sibling delete_post. An agent can tell what is removed without opening the schema.

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 concrete preconditions: a post must be draft, awaiting approval, scheduled, or failed, so an item with a publishing/published post cannot be deleted, and items holding only a channel-less draft are unblocked. It does not name the alternative tool (delete_post) for the case where only one post should be removed, leaving the routing inference to the agent.

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

delete_postDelete a post by id.B

Destructive

Delete a post by id.. Current Buffer GraphQL deletePost. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	Post id to delete.
`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	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuine value beyond that: it requires explicit confirmation and warns that provider errors are failures even with HTTP 200 - a non-obvious server behavior an agent must handle.

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?

Appropriately short and front-loaded, but the prose is fragmented ("Current Buffer GraphQL deletePost.") and contains a stray double period after "id..". Efficient in size yet not cleanly structured.

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 destructive mutation with no output schema and rich annotation coverage, the description supplies the key operational facts: confirmation requirement, upstream field bounding, and provider error semantics. Only minor detail (e.g., irreversibility or permission prerequisites) is missing.

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 fully documents all six parameters; baseline is 3. The description adds minor meaning by tying confirmation to the `confirm` param and by hinting that `fields` is used to bound upstream data, but nothing substantive beyond the schema.

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 ("Delete a post by id") that is unambiguous and cleanly distinguishable from sibling mutations like delete_content_item and delete_post_template. It does not, however, explicitly name or rule out any sibling, so full differentiation is left to the reader.

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

Usage Guidelines2/5

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

The description notes that explicit confirmation is required but gives no when-to-use or when-not-to-use guidance relative to alternatives such as delete_content_item. There is no scoping of conditions that select this tool over its siblings.

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

delete_post_templateDelete a post template owned by the caller (or an internal template in the caller's organization, if the caller is an org admin/owner).A

Destructive

Delete a post template owned by the caller (or an internal template in the caller's organization, if the caller is an org admin/owner).. Current Buffer GraphQL deletePostTemplate. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The ID of the template to delete.
`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	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

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, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds beyond that: an explicit confirmation requirement and the important note that provider errors count as failures even when HTTP 200 is returned. It does not describe revertibility or the success response shape, but the added context is solid.

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?

Purpose is front-loaded, which is good, but the text contains a double-period typo ('...owner)..') and the 'Current Buffer GraphQL deletePostTemplate' fragment is an implementation aside that interrupts the flow. Sentence ordering is serviceable but not tight.

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 destructive mutation with no output schema and six fully documented parameters, the description covers confirmation, authorization scope, and provider error semantics. It omits what a successful return looks like and any undo/recovery note, but on the whole an agent has enough to call it correctly.

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 already documents all six parameters thoroughly, setting the baseline at 3. The description does map loosely onto two params (the confirm flag and the fields/upstream-field bounding), but it adds no syntax or semantics beyond what the schema already states.

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 and resource (delete a post template) and adds a meaningful ownership scope: caller-owned templates, or internal org templates for admins/owners. This clearly separates it from siblings like get_post_template, update_post_template, and create_post_template. It largely restates the title rather than adding new distinguishing detail, so it stops short of a 5.

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 gives a real usage prerequisite ('Requires explicit confirmation') and an authorization condition (org admin/owner scope), which are useful before an agent calls it. However, it never states when NOT to use it, nor names an alternative for retrieving or editing templates. Guidance is implied rather than exhaustive.

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

edit_postEdit post for channelB

Destructive

Edit post for channel. Current Buffer GraphQL editPost. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	ID of the post to edit
`mode`	No	How the post is being scheduled. Omit the field or pass null to make no scheduling change — null does not clear or reset the schedule: a scheduled post keeps its current share mode, queue slot, and any custom time, and the edit applies only the other provided fields. Pass a non-null ShareMode to apply that mode.
`text`	No	Text content of the Post. Omit the field to keep the current text; pass an empty string or null to clear it. Note: for threaded posts, this needs to match the first item in the `thread` array.
`dueAt`	No	Date when the post is scheduled to be published
`assets`	No	Ordered list of assets on this post. Omit to preserve the existing list, pass an empty array to clear it
`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.
`ideaId`	No	Is set when the Post is generated from an Idea
`source`	No	source where the composer was initiated from, used for tracking.
`tagIds`	No	tags
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`confirm`	No	Must be true for this exact user-requested Buffer mutation.
`draftId`	No	Is set when the Post is generated from a Draft
`payload`	No	Complete native input object instead of individual input fields.
`metadata`	No
`aiAssisted`	No	If this post was edited with the help of AI
`saveToDraft`	No	If true, saves the post as a draft instead of keeping it scheduled. When saving as draft: - Post status will be 'draft' instead of 'buffer' - The post will not be published until explicitly scheduled
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`approvalChange`	No	Change the post's approval state alongside this edit. Leave unset to keep the post's current approval state. Only valid when your posting policy on the post's channel requires approval, and only on your own drafts. Asking for the state the post is already in does nothing.
`schedulingType`	No	Scheduling type to indicate notification publishing or automatic publishing. Omit it, or send null, to leave the post publishing the way it already does.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare this a non-idempotent, destructive, open-world write, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it demands explicit confirmation and warns that 'provider errors are failures even with HTTP 200,' which tells the agent not to treat a 200 as success. It still omits reversibility and partial-failure recovery detail.

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?

Four short sentences, front-loaded with purpose and scoping, with the confirmation and error-handling caveats in the middle. No filler sentences, though the phrasing is telegraphic rather than polished.

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?

This is a large, deeply nested destructive mutation with 19 parameters, no output schema, and no required fields, so a bit more guidance would help. The description covers confirmation, error semantics, and field bounding, but says nothing about what edits are permissible, how omitted fields behave at a high level (only the schema does), or what a successful response contains.

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 95%, so the schema itself exhaustively documents the 19 parameters, including nested enums, asset structures, and omit-to-preserve semantics. The description adds no parameter-level detail (e.g., it never explains id, confirm, or fields), so the baseline 3 is appropriate.

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 ('Edit post for channel') and identifies the underlying operation ('Current Buffer GraphQL editPost'), so an agent knows this modifies an existing post. It does not distinguish itself from nearby siblings like update_content_item, update_post_template, or update_content_item_draft, which is the only gap.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance or named alternative; the agent is not told how edit_post differs from create_post or the update_content_item family. The line 'Use upstream fields to bound data' is more of a parameter hint than a usage rule, and 'Requires explicit confirmation' describes a precondition but not selection criteria.

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

get_accountGet your account informationA

Read-onlyIdempotent

Get your account information. Current Buffer GraphQL account. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`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.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent and non-destructive, so the bar is lower. The description adds genuinely new behavioral context: single request with no automatic pagination, and that provider errors surface as failures even under HTTP 200 — details the annotations cannot express.

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?

Four short sentences, front-loaded with the purpose, then operational caveats. No filler, though the phrasing is terse to the point of being slightly telegraphic.

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?

With 100% schema coverage the input side is well covered, and there is no output schema to explain. However, for a read tool with zero required params and a nested payload option, the description never hints at what the response contains beyond 'account information', leaving a modest gap.

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 already documents all four params in detail (fields paths, account credential selection, payload/payload_file exclusivity). The description's 'Use upstream fields to bound data' only lightly echoes the fields param, so baseline 3 is warranted.

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 ('Get your account information') and the qualifier 'Current Buffer GraphQL account' scopes it to a single account, which implicitly separates it from the sibling list_accounts. It stops short of naming the sibling explicitly, so sibling differentiation is inferred rather than stated.

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 word 'Current' implies when this applies versus list_accounts, but there is no explicit when-to-use/when-not guidance or named alternative. The 'Use upstream fields to bound data' note is usage-adjacent but framed as an instruction for the fields param, not a selection rule.

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

get_aggregated_post_metricsAggregate post performance for an organization across a date range, optionally filtered by channel or tagA

Read-onlyIdempotent

Aggregate post performance for an organization across a date range, optionally filtered by channel or tag. Current Buffer GraphQL aggregatedPostMetrics. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`tags`	No
`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.
`payload`	No	Complete native input object instead of individual input fields.
`channelIds`	No	Optional list of channel IDs to filter by. When omitted (null), the aggregate spans every channel in the organization the actor has insights access to. When set to an empty array, no channels match and the result is empty.
`endDateTime`	No	End of the aggregation window. Consumers typically pass UTC midnight of the last calendar day in the window (the backend treats the range as inclusive of that day), for example `2026-01-31T00:00:00Z`. Date range is capped to 365 days.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`startDateTime`	No	Start of the aggregation window. Consumers typically pass UTC midnight of the first calendar day in the window, for example `2026-01-01T00:00:00Z`.
`organizationId`	No	The organization ID

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the bar is lower; the description still adds real value by noting one request with no automatic pagination and that provider errors surface as failures even with HTTP 200. Missing detail on result grouping/shape, but the extra behavioral notes are genuinely useful.

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 compact sentences, front-loaded with the scope and followed by behavioral caveats. Slight redundancy between the title and first sentence, but nothing wasteful enough to penalize heavily.

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?

No output schema exists, but the description rightly focuses on input behavior and pagination expectations for a read aggregate. With 89% schema coverage and nested objects already explained in the schema, the remaining gaps (return grouping, tag union semantics) are minor.

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 89%, so parameters are well documented already (date formats, channelIds empty-array semantics, payload_file constraints). The description only adds a vague 'use upstream fields to bound data' note and does not elaborate field syntax or the dual payload/individual-fields input modes.

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

Purpose5/5

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

States a specific verb (aggregate), resource (post performance/metrics), and scope (organization, date range, optional channel/tag filters). An agent can distinguish this from sibling list tools like get_posts or get_channels without opening the schema.

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 some operating guidance ('Use upstream fields to bound data') but gives no explicit when-to-use vs. alternatives such as get_posts or graphql_query. The agent must infer that this is the aggregated-metrics entry point rather than a raw post listing.

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

get_channelGet a channel by IDB

Read-onlyIdempotent

Get a channel by ID. Current Buffer GraphQL channel. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The ID of the channel to be retrieved
`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.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

B3.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds genuinely non-obvious behavioral facts beyond that: 'One request, no automatic pagination' and 'provider errors are failures even with HTTP 200.' The one weak spot is 'Current Buffer GraphQL channel,' which is vague and adds little.

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?

Front-loaded with the core action and reasonably short. But the sentence 'Current Buffer GraphQL channel' is vague filler that doesn't clearly earn its place, while the pagination and error sentences do carry weight.

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 a read-only get-by-ID tool with full schema coverage and no output schema, the description covers the key behavioral caveats (no auto-pagination, error semantics). It falls short on situating the tool against its siblings (get_channels, get_content_item), which an agent needs to select correctly.

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 already documents id, fields, account, payload, and payload_file in detail. The description only gestures at the fields parameter ('Use upstream fields to bound data') without adding syntax or format detail, so baseline 3 is appropriate.

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 and resource ('Get a channel by ID'), so the action is unambiguous. However, it never distinguishes this from the sibling 'get_channels' (the plural/list variant), leaving the agent to infer the singular-vs-list split on its own.

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

Usage Guidelines2/5

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

The description offers tips ('Use upstream fields to bound data') but no guidance on when to use this tool versus alternatives like get_channels or graphql_query. There is no stated condition or exclusion that would route an agent between siblings.

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

get_channelsList channels for an organizationA

Read-onlyIdempotent

List channels for an organization. Current Buffer GraphQL channels. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`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.
`filter`	No
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No	The Organization id to fetch channels for

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the read-only annotations, the description adds real behavioral context: single-request with no automatic pagination, and 'provider errors are failures even with HTTP 200,' which is an important error-semantics disclosure. Annotations already cover the safety profile, so this added context lifts the score.

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?

Four short sentences with the purpose front-loaded and no filler. The phrasing is dense and slightly telegraphic ('Current Buffer GraphQL channels'), but nothing is wasted.

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, the description notes what is returned (channels), the pagination/request model, and error handling, which is fairly complete for a read-only list tool whose annotations and schema already carry most of the load.

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 83%, so the schema already documents parameters like filter, account, payload, and organizationId. The description only indirectly touches the fields parameter ('Use upstream fields to bound data'), which is the specified baseline of 3.

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: 'List channels for an organization,' and clarifies the data source ('Current Buffer GraphQL channels'). This pairs with the sibling get_channel (singular) reasonably, though the description never explicitly distinguishes itself from that or other list tools.

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 offers working guidance ('Use upstream fields to bound data') and notes pagination behavior ('One request, no automatic pagination'), which implies how to use it. However, it never states when to prefer this over get_channel or when not to use it.

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

get_configurationGlobal, per-organization configuration: the connected `channels` the actor can view (with per-feature authorization) plus the service-level capability catalog (`services`). One round trip for every capability domain; clients select only what they need.A

Read-onlyIdempotent

Global, per-organization configuration: the connected channels the actor can view (with per-feature authorization) plus the service-level capability catalog (services). One round trip for every capability domain; clients select only what they need.. Current Buffer GraphQL configuration. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`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.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No	The organization to return configuration for.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation behavior: no automatic pagination, one request per round trip, and 'provider errors are failures even with HTTP 200' — the latter is a non-obvious error-handling trait worth surfacing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description opens by repeating the tool title verbatim (the long `channels`/`services` blurb), which is pure duplication and pushes the actually informative sentences — pagination, error semantics — to the end. The front-loaded portion does not earn its place.

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, the description usefully sketches the return shape (`channels` with per-feature authorization, `services` catalog) and warns about error semantics. Given 100% schema coverage on the input side, the main gaps are minor — no explicit statement about the `payload`/`payload_file` mutual-exclusion interaction, which the schema already covers.

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 all five parameters are documented in the schema itself, establishing a baseline of 3. The description only touches `fields` indirectly ('Use upstream fields to bound data') and adds no syntax or format detail beyond what the schema already provides.

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 names a specific resource (per-organization configuration) and enumerates what it contains (`channels` the actor can view plus the `services` capability catalog). It is clear enough to distinguish from most siblings, though it never contrasts itself with near-neighbors like get_channel/get_channels or get_operation_schema.

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 implies usage via 'One round trip for every capability domain; clients select only what they need' and 'Use upstream fields to bound data,' which hints at when the tool is appropriate. There is no explicit when-not-to-use guidance or named alternative, so it stays at implied usage.

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

get_content_itemFetch a single content item by id. Errors if no content item with that id exists. This API is an early preview and can change without a deprecation period.B

Read-onlyIdempotent

Fetch a single content item by id. Errors if no content item with that id exists.

This API is an early preview and can change without a deprecation period.. Current Buffer GraphQL contentItem. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The unique identifier of the content item to fetch.
`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.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context: 'One request, no automatic pagination', 'provider errors are failures even with HTTP 200', and the preview stability warning. However, it doesn't describe authentication requirements or rate limits. With annotations doing heavy lifting, this is a moderate addition.

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 repeats the title verbatim and includes an awkward double period. While it front-loads the core action, the preview warning is duplicated from the title. The added GraphQL/pagination/provider-error sentences are valuable but the overall structure wastes space on repetition.

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 a read-only fetch tool with full parameter schema coverage and comprehensive annotations, the description adds a few useful behavioral notes (no pagination, provider error semantics, preview instability). However, it omits authentication context and doesn't explain how 'fields' relates to bounding data. Adequate but incomplete.

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 all five parameters are documented in the schema. The description's note about using upstream fields to bound data adds context beyond the schema, but doesn't explain the payload vs payload_file vs individual fields mutually exclusive pattern. Baseline 3 when schema carries the load.

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 clear verb+resource: 'Fetch a single content item by id.' It distinguishes single-item fetch from the sibling get_content_items, though the differentiation is implied rather than explicit. The error condition adds specificity.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. It doesn't mention get_content_items for listing or any other retrieval path. The agent is left to infer usage from the name alone.

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

get_content_itemsFetch an organization's content items in the requested order, newest first by default. Uses standard cursor pagination: pass the previous page's `pageInfo.endCursor` as `after` to fetch the next page. Requesting more than 100 items in a single page is rejected. This API is an early preview and can change without a deprecation period.A

Read-onlyIdempotent

Fetch an organization's content items in the requested order, newest first by default. Uses standard cursor pagination: pass the previous page's pageInfo.endCursor as after to fetch the next page. Requesting more than 100 items in a single page is rejected.

This API is an early preview and can change without a deprecation period.. Current Buffer GraphQL contentItems. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Sorting to apply, each entry breaking ties in the one before it. Defaults to newest first. A pagination cursor is only valid for the sort that produced it, so reset `after` to null whenever the sort changes.
`after`	No	Opaque cursor from pageInfo.endCursor. One page per ordinary call.
`first`	No	Local page-size cap 100, default 25; provider may impose additional query limits.
`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.
`filter`	No
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No	Organization to list content items for. The caller must be a member of this organization.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower; the description still adds real value by disclosing the early-preview instability, the 100-item rejection, no automatic pagination, and that provider errors surface as failures even on HTTP 200.

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?

Front-loaded and reasonably short, but it is largely a copy of the title text, contains a stray double period ('period.. Current Buffer...'), and repeats the pagination statement that also lives in the title. Some redundancy costs it.

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 a rich 89%-documented schema and no output schema, the description covers pagination, page-size limits, preview instability, and error semantics. What remains missing is explicit guidance on field selection versus the default bounded fields, which is minor.

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 89%, so the schema already documents sort, after, first, fields, filter, account and payload_file in detail. The description adds only the cursor-passing pattern and the 'use upstream fields to bound data' hint, which is marginal beyond the schema's own text.

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 and resource ('Fetch an organization's content items') with ordering defaults and pagination semantics, which cleanly separates it from the singular get_content_item sibling. It never explicitly names the alternative, but the plural/list framing is unambiguous.

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?

Gives operational usage for pagination (pass pageInfo.endCursor as `after`, 100-item cap, one request no automatic pagination) but never says when to choose this tool over get_content_item, get_posts, or graphql_query. Usage is implied by the resource name rather than explicitly routed.

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

get_daily_posting_limitsReturns daily posting limit status for the given channels on the specified date.A

Read-onlyIdempotent

Returns daily posting limit status for the given channels on the specified date.. Current Buffer GraphQL dailyPostingLimits. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`date`	No	The date to check limits for. Defaults to today if not provided.
`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.
`payload`	No	Complete native input object instead of individual input fields.
`channelIds`	No	List of channel IDs to check limits for. All channels must belong to the same organization.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: single request with no automatic pagination, and that provider errors surface as failures even with HTTP 200.

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?

Purpose is front-loaded in the first sentence and the operational notes follow efficiently. There is minor redundancy: the title duplicates the opening sentence and a doubled period ('date..') appears, but the text remains tight overall.

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

Completeness5/5

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

For a read-only, single-request tool with 100% schema coverage and annotations covering the safety profile, the description supplies the remaining essentials: pagination behavior, error semantics, and the upstream operation name. No output schema exists, so the return-value explanation is not required.

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 every parameter (date, fields, account, payload, channelIds, payload_file) is already documented in the schema. The description only echoes the 'fields' bounding idea without adding new syntax or format detail, so the 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 description states a specific verb and resource: 'Returns daily posting limit status for the given channels on the specified date,' and names the underlying operation (Buffer GraphQL dailyPostingLimits). This distinguishes it from siblings like get_channel or get_channels, though it does not explicitly contrast with any alternative.

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?

'Use upstream fields to bound data' implies how to control result size, and noting that errors may occur despite HTTP 200 is useful. However, there is no explicit when-to-use vs when-not guidance, nor any pointer to a sibling alternative.

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

get_idea_groupsList idea groups (folders) for an organizationA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`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.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No	Unique identifier for the organization.

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.

get_ideasFetch a paginated list of ideas with optional filteringA

Read-onlyIdempotent

Fetch a paginated list of ideas with optional filtering. Current Buffer GraphQL ideas. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`after`	No	Opaque cursor from pageInfo.endCursor. One page per ordinary call.
`first`	No	Local page-size cap 100, default 25; provider may impose additional query limits.
`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.
`payload`	No	Complete native input object instead of individual input fields.
`tagsFilter`	No
`groupFilter`	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	The organization to fetch ideas from.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior. The description adds valuable context: 'Current Buffer GraphQL ideas', 'One request, no automatic pagination', and 'provider errors are failures even with HTTP 200.' This goes beyond annotations. However, it does not detail rate limits, partial success, or pagination cursor handling beyond what the schema provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four short sentences, front-loaded with the core purpose, then caveats about pagination and error handling. Every sentence earns its place, no redundancy.

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?

Given 9 parameters with nested objects, no output schema, and rich annotations, the description covers the key behavioral traits (no auto-pagination, provider errors on HTTP 200) and points to upstream fields for bounding data. It misses explaining the interaction between payload, payload_file, and individual fields (mutual exclusivity is in schema but not emphasized), and doesn't clarify return shape beyond pagination. Still largely complete for an agent to invoke correctly.

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 78%, so the schema already documents most parameters. The description adds little parameter-specific guidance, only referencing 'upstream fields' generally. No additional meaning is provided for payload, payload_file, tagsFilter, or groupFilter beyond the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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 clearly states the verb and resource: 'Fetch a paginated list of ideas with optional filtering.' This distinguishes it from siblings like get_idea_groups and create_idea, and the pagination aspect differentiates it from a hypothetical non-paginated list. However, it does not explicitly name an alternative for filtering by other criteria, keeping it from a 5.

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 implies usage for listing ideas with optional filters, and adds 'Use upstream fields to bound data' and 'One request, no automatic pagination.' This gives some guidance on how to use it but lacks explicit when-to-use versus alternatives (e.g., when to use payload vs individual fields, or when to prefer get_idea_groups).

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

get_instagram_audioRefresh metadata and preview availability for one Instagram audio asset. Requires Facebook Login. Instagram Login channels return ChannelRefreshRequired.A

Read-onlyIdempotent

Refresh metadata and preview availability for one Instagram audio asset. Requires Facebook Login. Instagram Login channels return ChannelRefreshRequired.. Current Buffer GraphQL instagramAudio. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`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.
`audioId`	No	Meta audio asset ID
`payload`	No	Complete native input object instead of individual input fields.
`channelId`	No	Instagram channel used to authorize the refresh
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A3.6/5.0

Behavior4/5

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

With readOnlyHint/idempotentHint/destructiveHint already set, the description still adds real context: the Facebook Login auth requirement, the ChannelRefreshRequired failure mode for Instagram Login channels, single-request no-auto-pagination behavior, and that provider errors are failures even with HTTP 200. The 'refresh' wording sits in mild tension with readOnlyHint but is consistent with fetching fresh metadata.

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?

Short and front-loaded, but the opening sentence is a verbatim duplicate of the title (including the stray double period), so that portion earns little. The genuinely useful content — pagination, error semantics, login requirement — is compressed but somewhat scattered into fragments.

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, no-output-schema tool with 6 params, the description covers the key agent needs: auth path, failure mode, single-request semantics, error handling, and field-bounding. It stops short of describing the returned payload, but annotations and the fields parameter mitigate that.

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 already documents fields, account, audioId, channelId, payload and payload_file. The description only adds the generic 'Use upstream fields to bound data', which does not extend beyond the schema's own field-path guidance, so 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 description gives a specific verb+resource — refreshing metadata and preview availability for ONE Instagram audio asset — and identifies the underlying operation (Buffer GraphQL instagramAudio). It is clear what the tool does, though it never explicitly distinguishes itself from siblings get_search_instagram_audio or get_trending_instagram_audio, which an agent must infer.

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 offers procedural guidance ('Use upstream fields to bound data', 'One request, no automatic pagination') but gives no explicit when-to-use/when-not or alternative routing versus the search/trending audio siblings. The login caveat (Instagram Login channels return ChannelRefreshRequired) is behavioral rather than a usage rule.

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

get_operation_schemaInspect native input and selectable fieldsC

Read-onlyIdempotent

Local current operation input schema, every selectable upstream field path and bounded default selections. No credentials or request.

ParametersJSON Schema

Name	Required	Description	Default
`operation`	Yes

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — 'No credentials or request' — implying a purely local introspection with no upstream call, though the wording is ambiguous about whether it means no auth or no request body. It says nothing about cost, caching, or when the returned schema can go stale.

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?

It is very short and front-loads the resource ('input schema'), which is good, but the second sentence is a compressed fragment list ('every selectable upstream field path and bounded default selections') that reads as telegraphic rather than economical. Brevity here costs clarity rather than buying it.

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?

With one enum parameter, no output schema, and no nested objects, the tool is simple, but its entire value is the shape of what it returns (field paths and default selections) and the description only gestures at that. An agent can call it, but cannot predict the response structure or know how to use the returned paths, which is the core of the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single required 'operation' parameter, so the description must carry the burden and does not. It alludes to 'current operation' but never states that the argument must be one of the 36 enumerated operation names or how those enum values relate to the sibling tools (e.g. 'posts' vs get_posts).

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

Purpose3/5

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

The title verb 'Inspect' plus the phrase 'input schema' makes the general purpose recoverable, but 'Local current operation input schema' is awkward and never says plainly that the tool returns the request schema for a named operation. It also fails to distinguish itself from siblings such as preview_operation or graphql_query, which an agent would need in order to choose correctly.

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

Usage Guidelines2/5

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

There is no when-to-use statement, no precondition, and no named alternative. The description never explains that this is a discovery step to run before constructing an operation, nor why one would call it instead of reading a sibling tool's schema directly.

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

get_postGet a post by IDA

Read-onlyIdempotent

Get a post by ID. Current Buffer GraphQL post. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The ID of the post to be retrieved
`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.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, but the description adds genuinely new behavior: a single request with no automatic pagination, and that provider errors surface as failures even under HTTP 200. That error-semantics note is valuable and not derivable from the schema or 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?

Short and front-loaded, with the pagination and error semantics placed early. 'Current Buffer GraphQL post' is telegraphic and slightly cryptic, but no sentence is wasted.

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?

Covers the key call-shape facts an agent needs (single request, no auto-pagination, error surfacing) for a 5-parameter tool with no output schema. It is complete enough to call correctly, though it never clarifies the interaction between id/payload/payload_file beyond what the schema states.

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 already documents id, fields, account, payload and payload_file, including the payload/payload_file mutual exclusion. The description's 'Use upstream fields to bound data' adds a mild hint about fields usage but no syntax or format detail beyond the schema.

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 and resource ('Get a post by ID') and clarifies the underlying source ('Current Buffer GraphQL post'). It does not, however, distinguish itself from near-siblings like get_posts, get_post_template, or get_aggregated_post_metrics, nor explain what a 'Buffer GraphQL post' is relative to those.

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

Usage Guidelines2/5

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

There is no when-to-use / when-not-to-use guidance and no alternative tool is named, despite get_posts and get_post_template sitting right next to it. The sentence 'Use upstream fields to bound data' is parameter advice, not usage routing.

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

get_postsList posts for an organizationA

Read-onlyIdempotent

List posts for an organization. Current Buffer GraphQL posts. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`sort`	No	The sort to apply to the posts results
`after`	No	Opaque cursor from pageInfo.endCursor. One page per ordinary call.
`first`	No	Local page-size cap 100, default 25; provider may impose additional query limits.
`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.
`filter`	No
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No	The Organization id to fetch posts for

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: single-request semantics, no automatic pagination, and that provider errors are failures even with HTTP 200.

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?

Four short sentences, front-loaded with the core purpose, no wasted wording. The fragment 'Current Buffer GraphQL posts' is slightly cryptic but compact.

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 or annotations gap, the description supplies the critical operational facts an agent needs: no automatic pagination, one page per call, and provider errors surfacing as failures. It does not describe the returned shape, but that gap is modest for a list 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 description coverage is 89%, so the schema carries almost all parameter meaning. The description only gestures at the 'fields' parameter ('Use upstream fields to bound data'), adding little syntax or format detail beyond what the schema already documents.

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 with scope: 'List posts for an organization.' An agent can tell it fetches a collection. It does not explicitly differentiate from the singular get_post sibling, so it falls short of a 5.

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?

'One request, no automatic pagination' and 'Use upstream fields to bound data' imply how to use the tool but never state when to choose it over get_post, query_pages, or graphql_query. Usage is inferred rather than directed.

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

get_post_templateFetch a single post template by ID. Returns null if not found.A

Read-onlyIdempotent

Fetch a single post template by ID. Returns null if not found.. Current Buffer GraphQL postTemplate. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The unique identifier of the template to fetch.
`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.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: returns null instead of erroring on a miss, no pagination, and provider errors surface as failures even under HTTP 200. That error-semantics note is information an agent cannot get from the annotations or schema.

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?

Compact, but front-loaded content repeats the title verbatim (including a stray double period) and then trails into fragments like "Current Buffer GraphQL postTemplate." Some sentences earn their place, others are duplicate metadata.

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, the description carries the return burden and does state the null-on-miss result plus no-pagination behavior. It is adequate for a single-resource read, though it could say more about the returned payload shape.

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 id, fields, account, payload, and payload_file are already documented in the schema. The only description-level addition is the vague "Use upstream fields to bound data," which restates rather than extends the fields parameter's own docs.

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 and resource ("Fetch a single post template by ID") and the singular scope implicitly contrasts with the list sibling get_post_templates. It does not name that sibling explicitly, so the differentiation is implied rather than stated.

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?

Gives operational guidance ("One request, no automatic pagination", "Use upstream fields to bound data") but never says when to pick this over get_post_templates or update_post_template. Usage is implied by scope, not spelled out.

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

get_post_templatesFetch 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.A

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`after`	No	Opaque cursor from pageInfo.endCursor. One page per ordinary call.
`first`	No	Local page-size cap 100, default 25; provider may impose additional query limits.
`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.
`filter`	No
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No	Organization to scope `internal`-visibility templates to. The caller must be a member of this organization.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: single request with no automatic pagination, upstream `fields` used to bound data, and that provider errors must be treated as failures even on HTTP 200.

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 opening paragraph largely duplicates the title (also embedded in annotations), so it is somewhat redundant, though the trailing sentences about pagination and error handling are efficient and front-loaded with useful constraints.

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 read tool with no output schema, the description covers pagination behavior, error semantics, and scope constraints. It omits any mention of the `payload`/`payload_file` input alternatives and `account` credential selection, but the high schema coverage compensates.

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 88%, so the baseline is 3. The description restates the visibility-scope semantics that the schema's `filter.visibility` description already carries, adding little beyond the structured fields for parameters like `account`, `payload`, or `payload_file`.

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 carefully defines the visibility scope, which distinguishes it from the singular get_post_template sibling. It does not name siblings explicitly, but the scope definition makes the resource boundary 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?

Explains that the input filter can only narrow within the actor-pinned scope, which usefully frames when the `filter.visibility` parameter matters. However, it gives no guidance on when to use this list tool versus get_post_template or search-style alternatives, leaving selection to inference.

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

get_search_instagram_audioSearch Instagram audio for one channel. Requires Facebook Login. Instagram Login channels return ChannelRefreshRequired.A

Read-onlyIdempotent

Search Instagram audio for one channel. Requires Facebook Login. Instagram Login channels return ChannelRefreshRequired.. Current Buffer GraphQL searchInstagramAudio. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`query`	No	Search text. Required. Use trendingInstagramAudio for trending results.
`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.
`payload`	No	Complete native input object instead of individual input fields.
`audioType`	No	Music or original sound catalog
`channelId`	No	Instagram channel to search audio for
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the bar is low, and the description still adds real value: single-request semantics with no automatic pagination, and the important caveat that provider errors count as failures even on HTTP 200. That is meaningful operational context not present in 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The behavioral content is front-loaded and dense, but the description opens by repeating the title verbatim, including a stray double period ("ChannelRefreshRequired.."). That duplication and punctuation artifact cost it efficiency without adding information.

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?

Given no output schema, an agent would benefit from some indication of the return shape (audio result nodes, cursors), which the description omits. It does cover auth requirements, pagination behavior, and error semantics, so it is adequate but not complete for a 7-parameter, nested-payload 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 description coverage is 100%, so the schema already explains query, fields, account, payload, audioType, channelId, and payload_file. The description's only parameter-adjacent hint ("Use upstream fields to bound data") restates what the fields schema entry already says, so the baseline 3 is appropriate.

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 and resource ("Search Instagram audio for one channel") and names the underlying operation (searchInstagramAudio). Sibling differentiation is only partial: the distinction from get_instagram_audio and get_trending_instagram_audio lives in the parameter text rather than the description body.

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 auth precondition ("Requires Facebook Login. Instagram Login channels return ChannelRefreshRequired") is genuine usage guidance that tells an agent when the call will fail. However, there is no explicit when-to-use/when-not-to-use versus the sibling tools; the trending alternative is only implied via the query parameter's schema description.

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

get_tagFetch a single tag by id. Resolves to null with a NOT_FOUND error when no tag has that id, and with an UNAUTHORIZED error when the tag belongs to an organization the caller cannot read. Both are reported in the errors array. This API is an early preview and can change without a deprecation period.A

Read-onlyIdempotent

Fetch a single tag by id.

Resolves to null with a NOT_FOUND error when no tag has that id, and with an UNAUTHORIZED error when the tag belongs to an organization the caller cannot read. Both are reported in the errors array.

This API is an early preview and can change without a deprecation period.. Current Buffer GraphQL tag. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The unique identifier of the tag to fetch.
`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.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, establishing a safe read operation. The description adds valuable context beyond these: it specifies error behaviors (NOT_FOUND, UNAUTHORIZED with error codes), notes the API is an early preview subject to change, and clarifies that provider errors are failures even with HTTP 200. This is good transparency for a read tool with 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?

The description is reasonably concise and front-loads the core purpose and error behaviors. The appended sentence about pagination and provider errors is somewhat abrupt but relevant. The structure is logical: purpose, error handling, preview status, then operational notes. No major verbosity.

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?

Given the complexity (5 parameters, nested objects like payload), annotations covering safety, and 100% schema coverage, the description is complete enough. It covers error handling and preview status, which are critical for error-prone calls. The only gap is lack of guidance on tool selection relative to siblings, but for a single-resource fetch with comprehensive schema, this is acceptable.

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 100%, so the schema already fully documents all parameters including id, fields, account, payload, and payload_file. The description adds little parameter semantics beyond noting 'Use upstream fields to bound data,' which hints at the 'fields' parameter but doesn't provide additional syntax or constraints beyond the schema. Baseline 3 is appropriate when schema is comprehensive.

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 clearly states a specific verb+resource ('Fetch a single tag by id'), which is unambiguous. However, with the exception of the sibling 'get_tags_v2' which is plural, there's no explicit differentiation from other 'get_' tools, though the resource 'tag' is specific enough. The core purpose 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 Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like get_tags_v2 for listing tags or get_post for other resources. It mentions using upstream fields to bound data, but that's a parameter usage hint, not tool selection guidance. No conditions for use or exclusions are stated.

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

get_tags_v2Fetch a page of the organization's tags, sorted by name in ascending order. Uses standard cursor pagination: pass the previous page's `pageInfo.endCursor` as `after` to fetch the next page. Requesting more than 100 tags in a single page is rejected. This API is an early preview and can change without a deprecation period.A

Read-onlyIdempotent

Fetch a page of the organization's tags, sorted by name in ascending order. Uses standard cursor pagination: pass the previous page's pageInfo.endCursor as after to fetch the next page. Requesting more than 100 tags in a single page is rejected.

This API is an early preview and can change without a deprecation period.. Current Buffer GraphQL tagsV2. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`after`	No	Opaque cursor from pageInfo.endCursor. One page per ordinary call.
`first`	No	Local page-size cap 100, default 25; provider may impose additional query limits.
`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.
`filter`	No
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
`organizationId`	No	Organization to list tags for. The caller must be a member of this organization.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld/no-destructive, so the bar is lower, yet the description adds real context: the 100-item page cap, the absence of automatic pagination, early-preview instability without a deprecation period, and the note that provider errors surface as failures even with HTTP 200. That last point is useful operational disclosure beyond 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose and pagination contract, which is good. However the title text is repeated verbatim inside the description (including a stray double period '..' before the appended graphql tagsV2 sentences), producing redundant restatement that dilutes the useful appended content.

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 reasonably covers the pagination contract, page-size limits, and API stability. With nested payload objects and 8 parameters, a brief note on how filter/payload interact or what the bounded default fields return would round it out, but the essential call-correctly information is present.

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 88%, so the schema already documents after, first, fields, filter, account, payload and organizationId. The description only restates the cursor and page cap, adding nothing about the payload/payload_file/fields interplay that the schema doesn't already cover. Baseline 3 applies when the schema carries the semantic load.

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 and resource (fetch the organization's tags) plus sort order and scope. It is clear against most siblings, though it never explicitly distinguishes itself from the singular get_tag, relying on naming convention alone.

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?

Explains pagination usage well (pass pageInfo.endCursor as `after`, one request, no automatic pagination), which tells the agent how to iterate. It gives no guidance on when to prefer this over get_tag or the generic graphql_query/query_pages siblings, leaving the main alternative-selection question to inference.

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

get_trending_instagram_audioReturn Meta trending Instagram audio for one channel. Requires Facebook Login. Instagram Login channels return ChannelRefreshRequired.A

Read-onlyIdempotent

Return Meta trending Instagram audio for one channel. Requires Facebook Login. Instagram Login channels return ChannelRefreshRequired.. Current Buffer GraphQL trendingInstagramAudio. One request, no automatic pagination. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`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.
`payload`	No	Complete native input object instead of individual input fields.
`audioType`	No	Music or original sound catalog
`channelId`	No	Instagram channel to load trending audio for
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the Facebook Login auth requirement, the ChannelRefreshRequired failure mode, 'one request, no automatic pagination', and 'provider errors are failures even with HTTP 200'.

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?

Information is front-loaded and each sentence carries behavioral content, but the opening sentence duplicates the title verbatim (wasting space) and a doubled period ('ChannelRefreshRequired..') plus the internal 'Current Buffer GraphQL trendingInstagramAudio' token add noise rather than clarity.

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, non-paginated, output-schema-less query tool, the description covers auth requirements, error semantics, request behavior and field bounding adequately. The main omission is routing relative to the overlapping audio siblings.

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 already documents all six parameters and the audioType enum. The description only contributes the generic 'Use upstream fields to bound data' hint, so the baseline 3 applies when the schema does the heavy lifting.

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 and resource with scope ('Return Meta trending Instagram audio for one channel'), so an agent knows the operation. However, it never distinguishes itself from siblings get_instagram_audio and get_search_instagram_audio, which cover overlapping audio territory, so sibling differentiation is absent.

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 prerequisite context ('Requires Facebook Login', Instagram Login channels return ChannelRefreshRequired), which implies when this tool is usable. But it gives no explicit when-to-use vs when-not guidance and does not route the agent to the audio siblings, leaving usage inference to the reader.

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

graphql_mutationRun one GraphQL mutationA

Destructive

One parsed GraphQL mutation with one direct root field and explicit confirmation. Adds __typename and MutationError catch-all to detect HTTP 200 failures. No automatic retry.

ParametersJSON Schema

Name	Required	Description
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`confirm`	No	Must be true for this exact user-requested Buffer mutation.
`document`	Yes
`variables`	No	Native JSON variables; validated remotely by Buffer.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds real context beyond them: it injects __typename and a MutationError catch-all to surface HTTP 200 failures that would otherwise look successful, and it states there is no automatic retry, which materially affects agent retry strategy.

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 short, front-loaded sentences with no filler; the operational constraints (single root field, error catch-all, no retry) come first. Slightly telegraphic phrasing like 'explicit confirmation' is only fully resolved by reading the schema.

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 generic mutation executor with no output schema, the description covers the essentials: input shape constraints, failure detection via __typename/MutationError, and retry policy. It stops short of describing what a successful response looks like, which an agent might want given the absence of an output schema.

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 75%, near the high-coverage baseline, and account, confirm and variables are already documented in the schema. The description usefully constrains the required `document` param ('one parsed mutation, one direct root field'), which the schema leaves undescribed, but it adds no detail on the confirm/account relationship beyond what the schema says.

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 ('run one parsed GraphQL mutation') and adds structural constraints ('one direct root field and explicit confirmation'), so the agent knows exactly what this tool accepts. It does not explicitly name graphql_query or preview_operation as the counterparts, so sibling differentiation is implied rather than stated.

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?

Encodes one usage precondition ('explicit confirmation'), which implies the agent must confirm before calling. However, it never says when to choose this over graphql_query or preview_operation, nor when-not to use it, leaving routing between the three graphql-related siblings to inference.

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

graphql_queryRun one GraphQL queryA

Read-onlyIdempotent

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

ParametersJSON Schema

Name	Required	Description
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`document`	Yes
`variables`	No	Native JSON variables; validated remotely by Buffer.

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.

list_accountsList private account profile labelsB

Read-onlyIdempotent

Local names, default marker and whether authentication is configured. No token, token path or organization ID.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety behavior is covered. The description does add real value by disclosing what is deliberately omitted from the payload ('No token, token path or organization ID'), which is security-relevant context annotations cannot express. It stops short of any pagination, ordering or volume behavior, so it lands at adequate rather than strong.

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?

It is very short and front-loads the returned fields ahead of the exclusions, which is the right ordering. However, the two fragments are telegraphic – no subject or verb – so the first sentence reads as a bare noun list rather than a self-contained statement, costing it structure points.

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?

With no output schema and no input parameters, the description is the sole source of shape information for this read tool, and it only partially discharges that duty: it names three returned attributes and three excluded ones but says nothing about how many accounts come back, ordering, or whether the list is scoped to the caller. Adequate but with clear gaps.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the 100% schema coverage baseline applies trivially. No misleading param claims are made.

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

Purpose3/5

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

The description enumerates the profile attributes surfaced ('Local names, default marker and whether authentication is configured') but never states the action or resource in verb+object form – the agent infers 'list accounts' from the name and title rather than the description. It does distinguish itself from get_account only weakly, via the field-list framing, not by naming the sibling or the singular-vs-plural intent.

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

Usage Guidelines2/5

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

No when-to-use, when-not-to-use, or alternative is given. The sibling get_account sits right next to it and the description offers no guidance on choosing the collection form over the single-account form. Usage is only implied by the plural tool name.

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

move_post_in_queueMove a queued post to the top or bottom of its channel's queue. Unlike editPost, this is a scheduling-only operation that never re-validates the post's content.A

Destructive

Move a queued post to the top or bottom of its channel's queue. Unlike editPost, this is a scheduling-only operation that never re-validates the post's content.. Current Buffer GraphQL movePostInQueue. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	ID of the post to move.
`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	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`position`	No	Target position within the channel's queue.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructive, non-idempotent, open-world write behavior. The description adds meaningful context beyond them: explicit confirmation is required, content is never re-validated, and provider errors must be treated as failures even on HTTP 200.

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 first two sentences are well front-loaded, but the title text is duplicated verbatim (including a doubled period) and GraphQL/confirmation caveats are crammed into trailing clauses. Wasteful repetition of the title rather than efficient single-pass structure.

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 mutation tool with no output schema, the description covers the safety profile, confirmation gate, field-bounding behavior, and error semantics adequately; annotations already carry the destructive/idempotency signals. Return shape is unspecified but arguably unnecessary here.

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 all seven parameters, including the position enum and confirm flag, are already documented in the schema. The description adds nothing parameter-specific, so the baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('Move a queued post to the top or bottom of its channel's queue') and explicitly distinguishes itself from editPost by scope. An agent can immediately tell this is a scheduling-only reorder, not a content edit.

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?

It names editPost as the sibling it differs from and states the confirmation requirement, giving clear context for use. It stops short of stating when this operation is preferable or what happens on failure vs. retry, so no exclusion guidance.

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

preview_operationPreview a named operation locallyA

Read-onlyIdempotent

Validate a current named input and upstream field selection, then return document and variables without credentials or a request. Does not validate permissions, assets or platform rules remotely. Operation names use native GraphQL camelCase.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes	Arguments for that named tool. Provide all required native input, including organizationId; profile defaults are not read.
`operation`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description still adds real value by disclosing that it makes no request, needs no credentials, and does NOT validate permissions/assets/platform rules remotely — behavior an agent could not infer from 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?

Three tight sentences with the core purpose front-loaded first, followed by the limitation and the naming convention. No filler, though the closing sentence on camelCase could be integrated more smoothly.

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, the description compensates by naming the return values (document and variables) and enumerating the offloaded limitations. For a two-parameter, no-request validation tool this is nearly complete; only the format/shape of the returned document and variables is left underspecified.

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 50%, so the schema carries half the burden. The description adds meaningful guidance beyond it — 'Operation names use native GraphQL camelCase' clarifies the operation enum, and 'including organizationId; profile defaults are not read' is already inside the arguments schema description. Baseline 3 is appropriate; it does not add syntax beyond the enum hint.

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 gives a specific verb (validate) and resource (named operation input plus upstream field selection) and states the concrete output: document and variables without a request. It implicitly distinguishes itself from execution tools like graphql_query/graphql_mutation by emphasizing 'without credentials or a request', but never names a sibling explicitly, so it falls short of a 5.

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 phrase 'without credentials or a request' implies this is a pre-flight/dry-run check, and 'Does not validate permissions, assets or platform rules remotely' sets a boundary. However, it never states when to use this instead of graphql_query/graphql_mutation or get_operation_schema, so usage is only implied rather than spelled out.

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

promote_content_item_draft_to_postsPromote a channel-less draft into channel-specific posts. One-way: once promoted, the content item can no longer be edited as a draft. If any post fails validation, none are created. A failure can also be reported when a post could not be fully processed after the promotion already took effect; re-fetch the content item to check its state before retrying. This API is an early preview and can change without a deprecation period.A

Destructive

Promote a channel-less draft into channel-specific posts. One-way: once promoted, the content item can no longer be edited as a draft. If any post fails validation, none are created. A failure can also be reported when a post could not be fully processed after the promotion already took effect; re-fetch the content item to check its state before retrying.

This API is an early preview and can change without a deprecation period.. Current Buffer GraphQL promoteContentItemDraftToPosts. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The content item to promote.
`posts`	No	The channel-specific posts to create, one per channel. Provide at least one post, and at most one post per channel.
`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.
`tagIds`	No	Tags to apply to this content item. Omit to keep the current tags. An empty list or null removes them all.
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`confirm`	No	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the annotations (destructiveHint, idempotentHint=false, openWorldHint) by disclosing the all-or-nothing validation rule ('if any post fails validation, none are created'), the partial-failure case where a promotion already took effect, the recommended recovery step, and that the API is an unstable early preview. This is exactly the behavioral context an agent needs before a destructive mutation.

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 behavioral warnings are front-loaded and each earns its place, but the description repeats the title paragraph verbatim before adding the operational sentences, which is pure duplication. The remaining additions are compact and useful.

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 complex nested-input mutation with no output schema, the description covers the critical ground: atomicity, irreversible promotion, partial-failure recovery, confirmation requirement, and API stability. It does not describe what the response contains or how the created posts are returned, which is the remaining gap.

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 already documents all 8 parameters including the nested post objects. The description only adds a hint about the `fields` parameter ('use upstream fields to bound data'), which is marginal beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.

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

Purpose5/5

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

States a specific verb and resource: promote a channel-less draft into channel-specific posts. This is clearly distinguishable from siblings such as create_content_item_draft, create_post, and update_content_item_draft, so an agent can route without opening the schema.

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 real preconditions and constraints: it is one-way, the item can no longer be edited as a draft afterward, and explicit confirmation is required. It also tells the agent to re-fetch the content item to check state before retrying. It does not name an alternative tool or state when to prefer create_post over this, so it stops short of a 5.

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

query_pagesRead bounded native cursor pagesA

Read-onlyIdempotent

Read one to five pages of a schema-generated query. No mutations. Automatically includes hasNextPage/endCursor, stops on repeated or missing cursors and returns continuation state. API errors abort the remaining pages; no retries.

ParametersJSON Schema

Name	Required	Description
`arguments`	Yes	Arguments for the native read tool, including filters, fields, first/after and account.
`max_pages`	No
`operation`	Yes

TDQS

A3.7/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: automatic hasNextPage/endCursor inclusion, stopping on repeated or missing cursors, returning continuation state, aborting remaining pages on API errors, and no retries. These are exactly the runtime traits an agent cannot get from readOnlyHint/idempotentHint, so the description earns high marks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the read scope, then pagination guarantees, then error semantics. Every sentence carries distinct information with no filler.

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, the description properly describes what comes back (hasNextPage/endCursor, continuation state) and how failures are handled. It is nearly complete for a 3-param tool, though it never says where the operation enums come from or how to discover valid query shapes, which the get_operation_schema sibling implies is needed.

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 only 33%, so the description must compensate. It does partially: 'one to five pages' restates the max_pages bound and 'cursor'/'continuation state' gives meaning to the first/after fields buried in the nested arguments object. However, the operation enum values and the overall arguments structure remain unexplained in prose, leaving the compensation incomplete.

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 and resource: reading one to five pages of a schema-generated query, with the key distinguishing trait (bounded multi-page cursor reads) up front. It does not name which sibling it replaces (e.g. graphql_query or get_operation_schema) or clarify what a 'schema-generated query' means relative to those tools, so it is clear but not fully differentiated.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance: nothing says when to prefer this over graphql_query, get_operation_schema, or the typed single-item getters (get_posts, get_content_items, etc.). The reader must infer usage from the 'schema-generated query' phrase alone, and no exclusions or prerequisites are stated.

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

remove_post_from_content_itemRemove a post from a content item. The post survives on its own channel and keeps its schedule, text, status, and tags. Only the link to the content item goes away. To delete a post, call deletePost. A second call with a post that belongs to no content item changes nothing, and the mutation reports success.A

Destructive

Remove a post from a content item. The post survives on its own channel and keeps its schedule, text, status, and tags. Only the link to the content item goes away. To delete a post, call deletePost.

A second call with a post that belongs to no content item changes nothing, and the mutation reports success.. Current Buffer GraphQL removePostFromContentItem. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The content item to remove the post from.
`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.
`postId`	No	The post to remove from a content item.
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`confirm`	No	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the bar is lower; the description still adds real context: what survives vs. what is removed, that a redundant call is a silent no-op reporting success, that explicit confirmation is required, and that provider errors are failures even with HTTP 200. The only caveat is that the no-op success wording sits in mild tension with idempotentHint=false, though it describes a single case rather than a general claim.

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 core behavioral content is front-loaded and each sentence carries information, but roughly the entire first paragraph is duplicated from the title, and the trailing sentence ('Current Buffer GraphQL removePostFromContentItem ...') reads as generic template boilerplate. That redundancy costs the definition real conciseness.

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 destructive, 7-parameter mutation with nested payload and no output schema, the description covers the mutation's effect, the destructive scope, the alternative tool, the no-op edge case, confirmation, and error semantics. The main gap is that no return-value description is given, though the 'reports success' wording partially covers the no-op case.

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 already documents id, postId, fields, account, confirm, payload, and payload_file in detail. The description adds only two loose hints ('Requires explicit confirmation' and 'Use upstream fields to bound data'), which the schema already conveys more precisely, so the 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 and resource ('Remove a post from a content item') and spells out the exact effect ('the post survives ... only the link ... goes away'), which meaningfully distinguishes it from delete_post and add_post_to_content_item. However, the text is a verbatim duplicate of the title, so it adds less differentiation than its length suggests.

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 explicit routing to the alternative ('To delete a post, call deletePost') and clarifies the edge case where a post belongs to no content item. It stops short of stating prerequisites or when-not-to-use beyond that single alternative.

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

update_content_itemUpdate a content item's title or target date. Fields that are omitted keep their current value. This API is an early preview and can change without a deprecation period.A

Destructive

Update a content item's title or target date. Fields that are omitted keep their current value.

This API is an early preview and can change without a deprecation period.. Current Buffer GraphQL updateContentItem. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The content item to update.
`title`	No	Omit to preserve the existing title. Null clears it.
`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	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`targetDate`	No	Omit to preserve the existing target date. Null clears it.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description adds valuable context about preview instability, explicit confirmation requirements, and that provider errors can occur even with HTTP 200—details not in the annotations. The mention of 'upstream fields to bound data' also adds operational insight. However, it doesn't elaborate on what exactly gets destroyed or how confirmation works.

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 repeats the title verbatim (including the preview notice) before adding extra sentences. This duplication wastes space and buries the additional behavioral notes. The extra sentences are useful but could be more 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?

Given a mutation tool with destructiveHint=true, no output schema, and 8 parameters, the description covers key behavioral aspects: preview instability, confirmation requirement, and provider-error nuance. It misses explaining the title/targetDate update semantics beyond what's in the schema, but the additional context is substantial enough for a 4.

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 already documents all parameters in detail. The description adds only minor guidance about upstream fields and confirmation, which is largely redundant with schema descriptions. Baseline of 3 is appropriate when schema does the heavy lifting.

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 clearly states the verb and resource ('Update a content item's title or target date'), and notes omitted fields are preserved. It distinguishes from siblings like update_content_item_draft and edit_post by naming the specific fields and scope, but doesn't explicitly contrast with them.

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 mentions 'Requires explicit confirmation' and references bounding data with 'upstream fields,' but does not state when to use this tool versus update_content_item_draft, edit_post, or promote_content_item_draft. Usage context is implied rather than explicit.

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

update_content_item_draftReplace a channel-less draft's content in full, and optionally set the content item's target date in the same write. The draft needs text or at least one asset. Only valid while the content item is still a draft. This API is an early preview and can change without a deprecation period.A

Destructive

Replace a channel-less draft's content in full, and optionally set the content item's target date in the same write. The draft needs text or at least one asset. Only valid while the content item is still a draft.

This API is an early preview and can change without a deprecation period.. Current Buffer GraphQL updateContentItemDraft. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The content item whose channel-less draft is replaced.
`draft`	No
`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.
`tagIds`	No	Tags to apply to this content item. Omit to keep the current tags. An empty list or null removes them all.
`account`	No	Private account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
`confirm`	No	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`targetDate`	No	Date indicating when this piece of content should go out. This is a planning aid only and does not schedule any posts. Omit to preserve the existing target date. Null clears it.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint, non-idempotent, and open-world, so the safety profile is covered. The description adds value beyond them by requiring explicit confirmation, stating the draft-only precondition, warning that the API is an unstable preview, and noting that provider errors are failures even at HTTP 200.

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 first three sentences duplicate the title verbatim, which is wasted space in an already long definition. The genuinely new information ('Requires explicit confirmation', the fields hint, the HTTP 200 error note) is appended at the end 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?

For a destructive, multi-parameter mutation with no output schema, the definition covers preconditions, confirmation, and error semantics adequately. It stops short of describing what happens to pre-existing assets/content when the draft is replaced, which is the one behaviour an agent would still want confirmed.

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 89%, so the schema already documents nearly every parameter and nested field in detail. The description adds only a hint that 'upstream fields bound data' (touching the fields param) and nothing about tagIds, targetDate semantics, or payload_file, so it does not meaningfully exceed the schema baseline.

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

Purpose5/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 ('Replace a channel-less draft's content in full'), and the draft-only precondition plus optional target-date write distinguishes it from create_content_item_draft and update_content_item. An agent can route to it without opening a sibling schema.

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?

It gives clear preconditions for use: the item must still be a draft, the draft needs text or at least one asset, and explicit confirmation is required. It does not, however, name the alternative tool to use when the item is no longer a draft, leaving that inference to the agent.

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

update_post_templateUpdate a post template owned by the caller (or an internal template in the caller's organization, if the caller is an org admin/owner).B

Destructive

Update a post template owned by the caller (or an internal template in the caller's organization, if the caller is an org admin/owner).. Current Buffer GraphQL updatePostTemplate. Requires explicit confirmation. Use upstream fields to bound data; provider errors are failures even with HTTP 200.

ParametersJSON Schema

Name	Required	Description
`id`	No	The ID of the template to update.
`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	Must be true for this exact user-requested Buffer mutation.
`payload`	No	Complete native input object instead of individual input fields.
`visibility`	No	`public` is rejected — it is only available to official Buffer clients.
`description`	No	A short user-facing description of the template.
`payload_file`	No	Regular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

TDQS

B3.2/5.0

Behavior3/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 the auth scope (owner or org admin/owner for internal templates) and error semantics ('provider errors are failures even with HTTP 200'), but the 'Requires explicit confirmation' line largely duplicates the schema's confirm parameter documentation.

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?

Reasonably compact and front-loaded, but it restates the title verbatim (waste) and contains a doubled period ('owner)..'), which signals rough editing. The behavioral notes are tacked on rather than structured.

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 destructive 11-parameter mutation, the description covers the confirmation requirement, the ownership/authorization scope, and provider-error semantics. Remaining gaps — return shape and payload-vs-file selection — are handled by the 100%-covered schema and the destructive annotations.

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 already documents all 11 parameters including the payload/payload_file mutual exclusion and the visibility enum. The description adds only the generic 'use upstream fields to bound data' note, which the fields schema description already covers.

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 and resource ('Update a post template') and adds a scope/ownership qualifier (caller-owned or org-internal for admins). This lets an agent separate it from create_post_template, get_post_template, and delete_post_template. However, the sentence is a verbatim repeat of the title, so it earns no independent clarity beyond that.

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

Usage Guidelines2/5

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

The description offers no when-to-use guidance or named alternatives. 'Requires explicit confirmation' and 'Use upstream fields to bound data' are preconditions and formatting notes, not routing guidance between this and sibling mutations such as create_post_template or update_content_item.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

41 tool updatesv2.0.0Oct 3, 2026
- First observedadd_post_to_content_item
- First observedcreate_content_item
- First observedcreate_content_item_draft
- First observedcreate_idea
- First observedcreate_post
- First observedcreate_post_template
- First observeddelete_content_item
- First observeddelete_post
- First observeddelete_post_template
- First observededit_post
- First observedget_account
- First observedget_aggregated_post_metrics
- First observedget_channel
- First observedget_channels
- First observedget_configuration
- First observedget_content_item
- First observedget_content_items
- First observedget_daily_posting_limits
- First observedget_idea_groups
- First observedget_ideas
- First observedget_instagram_audio
- First observedget_operation_schema
- First observedget_post
- First observedget_post_template
- First observedget_post_templates
- First observedget_posts
- First observedget_search_instagram_audio
- First observedget_tag
- First observedget_tags_v2
- First observedget_trending_instagram_audio
- First observedgraphql_mutation
- First observedgraphql_query
- First observedlist_accounts
- First observedmove_post_in_queue
- First observedpreview_operation
- First observedpromote_content_item_draft_to_posts
- First observedquery_pages
- First observedremove_post_from_content_item
- First observedupdate_content_item
- First observedupdate_content_item_draft
- First observedupdate_post_template

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-10-03 00:50 across 41 tools

Disambiguation4/5

Most tools target a clearly distinct resource+action (channels, posts, content items, templates, ideas, tags, metrics, Instagram audio), so selection is usually unambiguous. The main overlap is among the generic GraphQL escape hatches (graphql_query, query_pages, preview_operation, get_operation_schema) which can blur together, plus singular/plural pairs like get_post_template/get_post_templates.

Naming Consistency4/5

Overwhelmingly consistent snake_case verb_noun (get_, create_, delete_, update_, add_, remove_, move_, promote_). A few deviations break the pattern: edit_post uses a different verb than update_post_template/update_content_item, get_tags_v2 carries a version suffix, get_search_instagram_audio is awkwardly phrased, and list_accounts mixes 'list' with the 'get' used for other collections.

Tool Count3/5

41 tools is on the heavy side, and the five generic GraphQL helper tools (graphql_query, graphql_mutation, query_pages, preview_operation, get_operation_schema) substantially overlap with the specific tools, suggesting consolidation is possible. The breadth is partly justified by the genuinely large surface area (posts, content items, drafts, templates, ideas, tags, channels, metrics, audio).

Completeness4/5

CRUD coverage is strong for posts, content items/drafts, and post templates, with read coverage for channels, ideas, tags, metrics, and Instagram audio, plus generic query/mutation escape hatches for gaps. Ideas and tags expose only read/create (no update/delete) for ideas and read-only tags, so a few lifecycle operations are missing.

Maintenance

ActivityNo data

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Chirpie A
io.github.Firefloco
Post, schedule, and track social posts on X, Bluesky, LinkedIn, Instagram and more from AI agents.
Social Media App Automation
331
SocialRobot MCP Server AOAuth
io.socialrobot
Schedule and publish social posts across 9 platforms (Instagram, LinkedIn, X, TikTok, Facebook, Threads, Pinterest, Bluesky, Mastodon) straight from Claude, ChatGPT, Cursor, or any MCP client. Create, edit, and reschedule posts, upload media, and pull account and post analytics, follower demographics, and best-time windows. 20 tools, free on every plan.
Social Media
1
Storylayer PublishingOAuth
io.github.mikeslone
Hosted MCP for Instagram, Facebook, X, LinkedIn, Pinterest, and Ghost. OAuth 2.1, 38 tools.
Social Media Content Management Systems
2
socialclaw B
io.github.ndesv21
Connect any AI agent to 11+ social platforms: schedule, publish & track posts via hosted MCP.
Social Media Marketing
33293

Related MCP Servers

Publora MVP MCP Server
Social Media App Automation
paisabrazilfl-cpu
F
license
Not graded
quality
D
maintenance
Enables AI agents to create, schedule, and manage social media posts across 10 platforms via a unified API.
Updated 3 months ago (2026-06-30 21:19 UTC)
-
socialclaw
Social Media Communication Marketing
ndesv21
A
license
Not graded
quality
B
maintenance
Social media scheduling and publishing for AI agents. 17 validation-first tools to post to X, LinkedIn, Instagram, TikTok, YouTube, Reddit, Discord, Telegram, and more through one connected workspace.
Updated a month ago (2026-08-24 10:56 UTC)
142 npm
93
MIT
socialcrawl-mcp
Social Media Search
RidioDevelopment
A
license
A
quality
D
maintenance
Provides AI agents with unified access to 21 social media platforms and 105 endpoints for retrieving profiles, posts, comments, search results, trending content, and analytics without per-platform authentication.
Updated 6 months ago (2026-04-10 13:53 UTC)
4
522 npm
MIT
seenpaid
Social Media Communication
justinasrolando-cpu
A
license
Not graded
quality
B
maintenance
Enables AI agents to schedule and manage social media posts across 25 platforms via a simple 3-tool MCP interface, including listing connected accounts and recent posts.
Updated 14 days ago (2026-09-21 12:28 UTC)
AGPL 3.0

Buffer MCP Server & CLI

Two ways to use it

Command line

MCP server, for your AI app

Which one

Features

Contents

1. What you can ask it

2. Quick install

3. Set up Buffer access

Private API key and account access

Plans, quotas and query limits

Revocation and rotation

4. Connect your client

5. Check it works

6. Output, flags and exit codes

7. MCP or CLI and token cost

8. Every tool and argument

get_account

add_post_to_content_item

get_aggregated_post_metrics

get_channel

get_channels

get_configuration

get_content_item

get_content_items

create_content_item

create_content_item_draft

create_idea

create_post

create_post_template

get_daily_posting_limits

delete_content_item

delete_post

delete_post_template

edit_post

get_idea_groups

get_ideas

get_instagram_audio

move_post_in_queue

get_post

get_posts

get_post_template

get_post_templates

promote_content_item_draft_to_posts

remove_post_from_content_item

get_search_instagram_audio

get_tag

get_tags_v2

get_trending_instagram_audio

update_content_item

update_content_item_draft

update_post_template

list_accounts

graphql_query

graphql_mutation

preview_operation

query_pages

get_operation_schema

Nested native input definitions

addPostToContentItem.input

aggregatedPostMetrics.input

aggregatedPostMetrics.input.tags

channel.input

channels.input

channels.input.filter

configuration.input

contentItem.input

contentItems.input

contentItems.input.filter

contentItems.input.filter.targetDate

contentItems.input.filter.targetDate.range

contentItems.input.sort[]

createContentItem.input

createContentItem.input.posts[]

createContentItem.input.posts[].assets[]

createContentItem.input.posts[].assets[].document

createContentItem.input.posts[].assets[].image

createContentItem.input.posts[].assets[].image.metadata

createContentItem.input.posts[].assets[].image.metadata.dimensions