Skip to main content
Glama

Get Social Top Posts

get_social_top_posts
Read-onlyIdempotent

[read] Top posts of social accounts (platform: fb, ig, tw, tt; facebook, instagram, twitter, tiktok also work) over days, ranked by metric (optional). With account_id or account_uuid: that account (the platform is found by itself). With platform only: every account of it. With neither: the merchant's accounts of all four platforms. The answer lists accounts (platform, account_id, account_uuid, name) to pick one from.

Input Schema

NameRequiredDescriptionDefault
daysNo
metricNo
platformNo
account_idNo
account_uuidNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavior beyond that: platform alias resolution, automatic platform lookup when an account is supplied, fallback to all four platforms, and the presence of an accounts list in the response. It does not explain ranking mechanics or pagination, but it adds meaningful context.

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 compact and front-loaded with the read-only marker and core purpose. Every clause adds either platform alias information, scoping logic, or return context without filler.

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 and 0% schema coverage, the description should ideally explain more about the returned top posts. It mentions that an accounts list is returned for selection, but it does not describe post fields, pagination/limits, ranking metric values, or the days default.

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?

With 0% schema description coverage, the description carries the burden and gives meaning to all five parameters: days as the time window, metric as optional ranking, platform aliases, account_id/account_uuid as selectors, and their combination behavior. It lacks defaults and accepted metric values, which keeps it from a 5.

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 resource and operation: top posts of social accounts over a time window, ranked by metric. It clearly explains the account/platform scoping model, though it does not explicitly distinguish this tool from siblings like list_social_posts or get_social_report.

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 explicit routing for the main usage cases: account_id/account_uuid for one account, platform only for all accounts on that platform, and neither for all four merchant platforms. It stops short of naming alternatives or when not to use this tool, so it is clear but not fully comparative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.