Skip to main content
Glama
thenavidm

Buffer MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Fetch a single tag by id

get_tag
Read-onlyIdempotent

Fetch a single Buffer tag by its unique ID. Returns tag fields or reports NOT_FOUND and UNAUTHORIZED errors in the errors array.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
idNoThe unique identifier of the tag to fetch.
fieldsNoUpstream field paths relative to the result, as in official CLI --fields. Default fields are bounded. Use items.id for connection nodes; pageInfo.endCursor for cursors.
accountNoPrivate account profile name. Selects credentials only; an organization default does not restrict provider token permissions.
payloadNoComplete native input object instead of individual input fields.
payload_fileNoRegular local JSON input file, no symlink, at most 1 MiB; cannot mix with payload or individual input fields.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

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/openWorld, so the bar is lower, yet the description adds real value: NOT_FOUND and UNAUTHORIZED semantics reported in the errors array, a preview-stability warning, and the note that provider errors are failures even at HTTP 200. The phrasing "Resolves to null with a NOT_FOUND error" is internally muddled (null vs. error), which keeps it from a 5.

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 in the first sentence, which is good, but the body is garbled: "a deprecation period.. Current Buffer GraphQL tag" has a double period and an awkward splice, and the provider-errors clause is opaque. Sentences do not all cleanly earn their 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 carries the return-value burden and does explain null/error behavior and no-pagination. Combined with 100% schema coverage of five params, an agent has enough to call it correctly, though the error/null ambiguity slightly weakens it.

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. The description only loosely echoes the fields parameter ("Use upstream fields to bound data") without adding syntax or semantics beyond what the schema provides. Baseline 3 is correct.

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 tag by id"), and the singular scope implicitly distinguishes it from the plural sibling get_tags_v2. However, it never names or contrasts that sibling explicitly, so the differentiation is left 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?

The description implies usage (fetch one tag when you have its id) and adds a constraint ("One request, no automatic pagination"), but gives no explicit when-to-use versus get_tags_v2 or the graphql_query/query_pages alternatives. Guidance is implied rather than stated.

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