Skip to main content
Glama

list_analytics

Read-only

Get social media post performance analytics — views, likes, comments, and shares for posts published through Post Bridge (TikTok, YouTube, Instagram, Facebook). Can filter by platform, timeframe, or media type (video vs TikTok slideshow).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of results to return
offsetNoOffset for pagination
platformNoFilter by platform (e.g. instagram, tiktok, youtube)
timeframeNoOnly posts published in this window. Default all.
media_typeNoslideshow = TikTok photo posts, video = TikTok and YouTube videos. Instagram and Facebook posts are excluded when set (they don't report duration).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / media_type
      Added value: +{
      +  "description": "slideshow = TikTok photo posts, video = TikTok and YouTube videos. Instagram and Facebook posts are excluded when set (they don't report duration).",
      +  "enum": [
      +    "video",
      +    "slideshow"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / timeframe
      Added value: +{
      +  "description": "Only posts published in this window. Default all.",
      +  "enum": [
      +    "7d",
      +    "30d",
      +    "90d",
      +    "all"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description usefully adds that results are scoped to posts published through Post Bridge and that media_type has platform-specific exclusion behavior, but it does not cover pagination, default limits, or return shape. Modest added value over annotations.

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?

Two front-loaded sentences with no filler: the first names the resource and metrics, the second lists the filters. Every clause earns its place.

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?

Annotations cover the safety profile and the schema fully documents parameters, so the essential invocation info is present. However, for a list/analytics tool with no output schema, the description says nothing about return format, pagination behavior, or how results relate to get_analytics_daily or sync_analytics, leaving sibling disambiguation 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 every parameter already has a description. The description echoes the filterable dimensions (platform, timeframe, media type) but adds no syntax, defaults, or edge cases beyond what the schema provides. Baseline 3 is appropriate 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 ('Get') and resource ('social media post performance analytics'), and enumerates the metrics returned (views, likes, comments, shares) plus the platforms involved. An agent can distinguish this from get_analytics_daily and sync_analytics 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 Guidelines3/5

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

The description implies usage by naming supported platforms and filter dimensions, but never states when to use this over the sibling get_analytics_daily or exactly what its scope is relative to sync_analytics. No alternative is named and no when-not condition is given.

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.