Skip to main content
Glama
facebook-mcp

facebook-mcp

by IvanBBaev

List Reels

facebook_list_reels
Read-onlyIdempotent

Lists a Page’s Reels from the /video_reels edge so you can retrieve video content missing from post listings, with cursor pagination for paging through results.

Instructions

List a Page's Reels via the /video_reels edge — the ONLY place Reels are readable. They never appear in facebook_list_posts, so use this tool whenever Reels matter, and never conclude from an empty post listing that a Page has no video content. Same cursor pagination as the post listings: pass the returned nextCursor back as after. Reel items are video nodes (title, description, length, permalink, publish state), not post nodes; the field set is best-effort, so use fields if Graph rejects one of them. The id on each item is a VIDEO id — that is what facebook_reel_insights takes; facebook_post_insights cannot read a Reel at all. Whether a DRAFT or SCHEDULED Reel is listed here is unverified, so its absence is not proof it does not exist — check a known video id with facebook_get_video_status.

Input Schema

NameRequiredDescriptionDefault
afterNoOpaque forward cursor from a previous call's `nextCursor`. Omitted ⇒ start from the first page. Cursors expire; on an expiry note, restart the listing without this argument.
limitNoMaximum items to return in this page (1–100). Defaults to 25. Large values risk truncation by the result budget.
fieldsNoComma-separated Graph field list that REPLACES this tool's documented default set (e.g. "id,message,created_time"). Omitted ⇒ the default set. Use it to request extra fields, or to work around a field Graph rejected.
profileNoPage profile key (e.g. "brand-a") or a raw Page ID. Omitted ⇒ the default Page (FB_PAGE_ID).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say read-only/idempotent/open-world; the description adds real behavior beyond that: cursor round-trip via `nextCursor`, item type being video nodes rather than post nodes, a best-effort field set that may be rejected by Graph, and the unverified status of DRAFT/SCHEDULED Reels. The absence-is-not-proof warning is exactly the kind of caveat annotations cannot carry.

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?

Front-loaded with the scope and the sibling distinction, and essentially every clause carries decision-relevant information. It is dense and runs long for a list tool, with several ideas compressed into single run-on sentences, which costs it a point on readability rather than on waste.

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?

Covers what an agent needs to call this correctly and interpret results: pagination protocol, return-item shape, id type, downstream tool mapping, and the DRAFT/SCHEDULED gap. No output schema exists, yet the description describes the item fields well enough to reason about results.

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?

Schema coverage is 100%, so the baseline is 3 and the schema already documents cursor expiry, limits, and the `fields` replacement semantics. The description still adds value by tying `nextCursor` back to `after` and by framing `fields` as a workaround for a rejected field, but `profile` and `limit` get no treatment in prose.

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 and resource ("List a Page's Reels") and pins the exact Graph edge (/video_reels), then explicitly contrasts with the sibling facebook_list_posts: "They never appear in facebook_list_posts." An agent can pick between the two list tools without opening either schema.

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?

Gives an explicit trigger ("use this tool whenever Reels matter") plus a negative rule ("never conclude from an empty post listing that a Page has no video content"). It also routes downstream work: Reel ids go to facebook_reel_insights, not facebook_post_insights, and DRAFT/SCHEDULED uncertainty is handled via facebook_get_video_status.

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