Skip to main content
Glama
thenavidm

Buffer MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Aggregate post performance for an organization across a date range, optionally filtered by channel or tag

get_aggregated_post_metrics
Read-onlyIdempotent

Aggregate post performance metrics across a date range for an organization, with optional channel or tag filters, to analyze trends in one request.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNo
fieldsNoUpstream field paths relative to the result, as in official CLI --fields. Default fields are bounded. Use items.id for connection nodes; pageInfo.endCursor for cursors.
accountNoPrivate account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
payloadNoComplete native input object instead of individual input fields.
channelIdsNoOptional 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.
endDateTimeNoEnd 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_fileNoRegular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.
startDateTimeNoStart of the aggregation window. Consumers typically pass UTC midnight of the first calendar day in the window, for example `2026-01-01T00:00:00Z`.
organizationIdNoThe organization ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

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.

Deploy Server

Other Tools