Skip to main content
Glama
IvanBBaev

facebook-mcp

by IvanBBaev

Reel Insights

facebook_reel_insights
Read-onlyIdempotent

Retrieve Facebook Reel metrics (plays, watch time, likes, social actions) from the /video_insights edge using the numeric video ID, avoiding the post-ID endpoint that cannot reach Reel data.

Instructions

Read Graph insights for one Reel from /{video-id}/video_insights — the edge Reel metrics actually live on, which facebook_post_insights cannot reach. Takes the VIDEO id (digits only, as returned by facebook_create_reel), NOT a "{page-id}_{post-id}" post ID. Same compact shape as the other insights tools: flat rows plus one summary per metric, or totals only with aggregate:true. The default period is "lifetime", because plays and watch time are cumulative counters rather than a daily series. Metric names are their own vocabulary — page/post names do not transfer — and Meta's reference lists blue_reels_play_count, post_video_avg_time_watched, post_video_view_time, post_video_likes_by_reaction_type and post_video_social_actions among others; they are examples, not a whitelist, so a name Graph never mentions is reported as unavailable rather than silently dropped. Empty series usually mean the wrong ID, a Reel that is not PUBLISHED yet, or the usual insights lag — the result says which to check.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sinceNoStart of the window as a calendar date "YYYY-MM-DD" (inclusive, Page timezone). Omitted ⇒ Graph's own default window. The since..until span may not exceed 90 days per call (checked before the request); read longer histories in slices.
untilNoEnd of the window as a calendar date "YYYY-MM-DD". Each returned `date` is the END of the period the value covers, so a window reaching today ends in a partial, still-being-computed bucket. Omitted ⇒ today.
periodNoAggregation window Graph applies per data point. "day" is a daily series (the Page default); "lifetime" is one cumulative value per metric (the post default); "week"/"days_28" are rolling windows; "month" is calendar-monthly; "total_over_range" collapses since..until into a single value. Not every metric supports every period — a metric queried with an unsupported period comes back empty, which the notes call out.
metricsYesGraph insights metric names to read, e.g. ["page_media_view","page_follows"] (1-20 per call; trimmed and lower-cased). Names are Graph-version dependent and Meta renamed most of them in the 2024-09, 2025-11 and 2026-06 waves: pre-wave names such as "page_impressions" or "page_fans" are dropped before the request and answered with their replacement instead of an error. Graph fails the WHOLE call when one surviving name is invalid, so isolate a suspect name by requesting it alone.
profileNoPage profile key (e.g. "brand-a") or a raw Page ID. Omitted ⇒ the default Page (FB_PAGE_ID).
max_rowsNoLower the per-point row cap for this call (1-250; the default and the ceiling are both 250 — this argument can only shrink it). Rows past the cap are dropped and the result reports how many; prefer aggregate:true over a tiny cap when you only need totals.
video_idYesThe Reel to read, as its VIDEO id — the `videoId` returned by facebook_create_reel (also echoed by facebook_get_video_status). A "{page-id}_{post-id}" value is a post, not a video, and does not resolve on the /video_insights edge. The Reel must belong to the resolved Page, whose token authorizes the read.
aggregateNoTrue ⇒ return per-metric totals only (period, points, total, first/last boundary) and NO per-point rows. Use it for wide windows or many metrics: it is the cheapest way to stay inside the result budget when a daily series would otherwise be truncated.
Install Server

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare read-only, idempotent, non-destructive behavior, and the description is fully consistent with that profile. Beyond what annotations convey, it discloses the non-obvious 'lifetime' default and the cumulative-counter rationale, the metric vocabulary caveat (unknown names reported as unavailable rather than silently dropped; examples are not a whitelist), and what empty series mean. The openWorldHint is reinforced by the 'not a whitelist' statement.

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?

The description is front-loaded with purpose and edge, and every sentence carries substantive content: ID semantics, output shape, default period, metric vocabulary, and failure diagnosis. It is long (~200 words) and modestly redundant with the rich schema (the post-ID caveat appears in video_id's description too), but the density earns its keep for a tool with this many API traps.

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?

For an 8-parameter tool with no output schema, the description compensates well by summarizing the output shape ('flat rows plus one summary per metric, or totals only with aggregate:true') and leveraging cross-tool consistency ('Same compact shape as the other insights tools'). Combined with the 100%-covered schema and the safety annotations, an agent has what it needs to select, invoke, and validate this tool correctly.

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% with unusually detailed per-parameter docs, so the baseline is 3 and the schema does the heavy lifting for video_id, period, aggregate, and the rest. The description adds a little non-redundant context — the rationale for the lifetime default and how unknown metric names surface — but much of it (the post-ID warning, period behavior) restates what the schema already says.

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?

The first sentence states a specific verb and resource: 'Read Graph insights for one Reel from /{video-id}/video_insights' and immediately distinguishes the tool from facebook_post_insights, which 'cannot reach' that edge. It also flags the ID-type trap (VIDEO id, not a '{page-id}_{post-id}' post ID), so an agent cannot mistake this for a post-level insights tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description names the closest sibling (facebook_post_insights) and the exact condition that selects this tool: the /video_insights edge that post insights cannot reach. It also anchors ID resolution to facebook_create_reel and facebook_get_video_status, and gives an explicit troubleshooting checklist (wrong ID, unpublished Reel, insights lag) that helps an agent verify correct invocation after the fact.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/IvanBBaev/facebook-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server