Skip to main content
Glama
IvanBBaev

facebook-mcp

by IvanBBaev

Page Insights

facebook_page_insights
Read-onlyIdempotent

Fetch Facebook Page engagement and reach metrics over a date range, returning totals or per-date rows while handling renamed metric names and flagging missing permissions or eligibility limits.

Instructions

Read Graph insights for one Page in a compact flat shape: one row per metric per data point ({metric, date, value}, plus breakdown for by-action-type metrics) and one summary per metric (period, points, total). Set aggregate:true for totals only. The window is since/until calendar dates, at most 90 days per call. Metric names renamed by the 2024-09 / 2025-11 / 2026-06 waves are answered with their replacement instead of a Graph error, and a metric Graph accepts but has no data for is reported separately from a name Graph does not know. Empty series usually mean the eligibility floor (a Page under 100 followers) or a token missing read_insights + the ANALYZE Page task — not zero engagement; the result says which. Reel metrics are NOT available here: they live on /{video-id}/video_insights — use facebook_reel_insights for those.

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.
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.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint true, and the description adds substantial behavior beyond that: renamed metrics are answered with replacements rather than Graph errors, 'no data' is reported separately from 'unknown name', and empty series are explained as eligibility floor (under 100 followers) or missing read_insights + ANALYZE task rather than zero engagement, with the result saying which. This is rich, non-obvious behavioral disclosure.

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 dense but every sentence carries distinct information: output shape, aggregation switch, window constraint, metric-rename behavior, empty-series diagnosis, and reel exclusion. It is front-loaded with the core purpose and reads efficiently despite its length; only minor trimming of the rename-wave detail would be possible.

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 carries the full burden of explaining the return shape, and it does: row structure, breakdown field, per-metric summary, and the aggregate variant. It also covers the two most confusing edge cases (renamed metrics, empty series meaning) and routes reel metrics away. For a read-only 7-parameter tool, nothing an agent needs to call it correctly is missing.

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 baseline is 3. The description echoes schema facts (calendar dates, 90-day cap, aggregate:true) rather than adding new parameter-level meaning, though it does add helpful context that aggregate output consists of period/points/total per metric. It doesn't materially exceed what the schema already documents.

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?

Opens with a specific verb+resource: "Read Graph insights for one Page in a compact flat shape", and goes on to state the exact row shape ({metric, date, value}) and summary shape. It actively distinguishes itself from a sibling by declaring "Reel metrics are NOT available here ... use facebook_reel_insights", so an agent can tell page, post, and reel insights apart.

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?

Gives clear context: 90-day window cap, aggregate:true for totals-only, and an explicit when-not with the named alternative ("/{video-id}/video_insights — use facebook_reel_insights for those"). It does not explicitly contrast against facebook_post_insights, but the reel routing covers the most confusable sibling and the usage constraints are otherwise concrete.

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