Skip to main content
Glama

get_audience

Read-only

follower counts + growth for every connected instagram / youtube / tiktok / twitter account and facebook page. one entry per ACCOUNT, not per platform: "entity_id" is null for your primary account on a platform and set for each additional one, so a user with two instagram accounts returns two instagram entries. counts come from each platform's official API and are cached for 15 minutes. youtube works differently: each youtube read spends a shared daily quota, so while you keep reading a creator's audience, their youtube count is refreshed in the background about once an hour, and an on-demand read re-fetches at most every 6 hours if that refresh is delayed; if the daily quota is exhausted, a youtube read returns the most recent successful count instead of null. "current.captured_at" is always when that count was actually read from the platform, never when it was served: use it to judge freshness. "series" is the stored history; youtube history is kept for 30 days (youtube's API storage limit), so youtube growth reaches back about 30 days whatever window_days says, while other platforms keep full history. growth is measured from the OLDEST stored point inside the window, which — because history points are recorded when you read, at most one per account per day — can be much younger than window_days: read "effective_window_days" (the span the delta actually covers) and "baseline_captured_at" before comparing growth across accounts. linkedin is not covered (its API exposes no personal-profile follower count). set include_instagram_insights to add instagram growth analytics to each instagram entry: follows, unfollows, net, and reach split into followers and non-followers per pacific-time day (the last 7 days are settled: false because instagram still revises them), followers_over_time (an estimate rebuilt back from the current count), weekly velocity with a trend, non_follower_reach_share, and contact-button taps. it reads up to 31 days per call, newest first, so a longer window fills over a few calls (days_pending says how many are left); instagram reports none of it for accounts under 100 followers (available: false).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_audience"
  }
}

Input Schema

NameRequiredDescriptionDefault
window_daysNogrowth window in days (default: 30, max: 365)
include_instagram_insightsNoadd instagram growth analytics to each instagram entry (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnlyHint/destructiveHint annotations, the description discloses caching (15 minutes), YouTube's shared daily quota and hourly background refresh with a 6-hour on-demand floor and stale-count-on-exhaustion fallback, that all data comes from official platform APIs, and that LinkedIn's absence is deliberate. These are operational traits an agent cannot get 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?

Nearly every sentence carries an operational caveat that would otherwise cause misuse, so the length is justified by the tool's complexity. It is, however, a single dense run-on paragraph with no structural breaks, which hurts scannability even though little is genuinely wasted.

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?

With no output schema, the description takes on the burden of explaining return values and does so thoroughly: current.captured_at semantics, series history depth, effective_window_days, baseline_captured_at, days_pending, settled, and available. Platform quirks (YouTube quota/retention, Instagram insights limits, LinkedIn exclusion) are all covered for a fairly complex tool.

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

Parameters5/5

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

Although schema coverage is already 100%, the description adds real meaning: window_days is qualified by YouTube's 30-day storage limit and by growth being measured from the oldest stored point (with effective_window_days and baseline_captured_at to check), and include_instagram_insights is expanded with the 31-day-per-call chunking, days_pending, and the under-100-follower unavailability.

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 precisely what is returned: follower counts plus growth for every connected Instagram/YouTube/TikTok/Twitter account and Facebook page, with the key clarification that it is one entry per ACCOUNT, not per platform (entity_id null for primary). The resource and scope are unmistakable, but no sibling tool is named for contrast, keeping it at 4 rather than 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?

Usage is implied rather than prescribed: the reader infers this is the tool for audience metrics, and it is told LinkedIn is not covered and that include_instagram_insights adds analytics. There is no explicit 'use this when' statement or named alternative, so the guidance is adequate but has clear gaps in routing.

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.

Resources